Libguestfs - Mar 2017 - 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/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

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/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
> 
> _______________________________________________
> 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/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@redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users