[libvirt-users] Running virConnectGetCapabilities / virsh capabilities without a daemon or KVM

[Martin Kletzander]

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 at redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170322/8198b224/attachment.sig>