[libvirt-users] Running virConnectGetCapabilities / virsh capabilities without a daemon or KVM
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. 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 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. 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). Any ideas? Rich. [1] https://github.com/libguestfs/libguestfs/commit/963d6c3be7cd91c0373f67cfdd95... -- 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
lstopo, lstopo --output-format xml These commands might be helpful
On Mar 21, 2017, at 10:35 AM, Richard W.M. Jones <rjones@redhat.com> 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.
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
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.
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).
Any ideas?
Rich.
[1] https://github.com/libguestfs/libguestfs/commit/963d6c3be7cd91c0373f67cfdd95...
-- 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
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
On Tue, Mar 21, 2017 at 11:25:20AM -0400, Ram Krishna wrote:
lstopo, lstopo --output-format xml
Yes that's interesting, although it's unfortunate that it doesn't include the CPU model (eg. "Broadwell" etc) in a form which libvirt can understand. Also the topology is rather difficult to parse. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
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/963d6c3be7cd91c0373f67cfdd95...
-- 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@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
participants (3)
-
Martin Kletzander -
Ram Krishna -
Richard W.M. Jones