On Tue, Mar 21, 2017 at 02:35:24PM +0000, Richard W.M. Jones wrote:
For virt-p2v we want to get the host CPU model, topology etc, and the best way we found to do that was to pull it from libvirt capabilities[1]. Since libvirt is already parsing the host CPU information, and because /proc/cpuinfo is such a stupid format to parse, this is very convenient.
Yeah, but we don't really parse more than the cpu frequency from that file.
Unfortunately it doesn't work unless libvirtd _and_ KVM are both installed. Without libvirtd installed: # virsh capabilities error: failed to connect to the hypervisor error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
We could theoretically add some "local hypervisor" driver that could expose only host-related APIs and would have no hypervisor capabilities, but that seems hacky.
With libvirt-daemon installed, but not QEMU: # virsh capabilities error: failed to connect to the hypervisor error: no connection driver available for <null> I feel I should be able to fiddle with the connection URI in some way to make this possible, at least in the second case. However there's not a concept of "no hypervisor", and I couldn't find any other way to make it work. Using "test:///default" seems tempting, but it substitutes some imaginary host (i686) so that's no good.
test:///default is purposefully not touching the host, it would have to be something like local:// or none:///local
Installing KVM isn't really an option for us since we are trying to build a minimal bootable ISO. Just installing qemu-system-x86_64 pulls in half the world. (Even installing libvirtd is difficult, and we'd prefer to avoid it).
So when you install virsh, it uses libvirt-libs and all the stuff that's
used for parsing and providing that information is already there
(almost, though), so it seems possible to provide the information.
However, that doesn't really fit into how virsh is trying to work/look.
You could use the internals directly, or parse the cpu_map.xml yourself,
but that's not supported and so on. We could provide a helper in
/usr/libexec that would tell you the capabilities, but there's still one
caveat.
You want to describe the CPU model for QEMU to emulate it as closely as
possible. Long story short, for that we were trying to mimic QEMU's
behaviour and due to various inconsistencies the best thing to do was
ask the QEMU binary itself directly about this stuff. So if you
currently want to use libvirt for this, I can't think of a reliable way
to do it without QEMU. We can get "close enough" without QEMU, but so
can you:
- uname() to have the architecture,
- check the flags from /proc/cpuinfo:
- ARM => Features:
- x86 => flags:
- do a mapping between cpuinfo flags and QEMU features (my guess is
there's around 10 features that might have different spelling)
- get all the topology from /sys/devices/system/{node,cpu}, there's
lot more info nowadays in newer kernels exposed in there, so you
don't need to go searching anywhere else much
Of course this will only work on linux, but I'm guessing that's not a
problem in this case, right?
Any ideas? Rich. [1] https://github.com/libguestfs/libguestfs/commit/963d6c3be7cd91c0373f67cfdd95c4f1dad1452f -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
