[Pkg-libvirt-maintainers] Bug#783901: Bug#783901: libvirt-daemon: libvirtd does not recognize Xen guests

[Gerald Turner]

On Sat, May 16 2015, Gerald Turner wrote:
> On Sun, May 10 2015, Guido Günther wrote:
>> On Fri, May 08, 2015 at 11:55:28AM -0700, Gerald Turner wrote:
>>> On Fri, May 08 2015, Guido Günther wrote:
>>> > On Fri, May 01, 2015 at 12:51:37PM -0700, Gerald Turner wrote:
>>> >> After correcting the domain XML, and restarting libvirtd once
>>> >> more, things start progressing:
>>> >>
>>> >>   # virsh -c xen:/// list --all
>>> >>    Id    Name                           State
>>> >>   ----------------------------------------------------
>>> >>    -     host1                          shut off
>>> >>
>>> >> … however “shut off” is incorrect.
>>> >
>>> > Stupid question but did you start the domain via virsh beforehand?
>>> > If so, is there anything interesting in the daemon log? AFAIK
>>> > configurations are now managed entierly via /etc/libvirt/libxl/ .
>>>
>>> Not stupid because that's part of the point I've subtly been trying
>>> to make - I'm sticking with domU's started by /etc/init.d/xendomains
>>> and /usr/sbin/xl, the "Xen way".  For four years during squeeze and
>>> wheezy,
>>
>> I just wanted to make sure we have this documented straight: libxl
>> managed xen domains aren't picked up by /usr/sbin/xl and vice versa.
>
> Not quite.
>
> xl managed xen domains aren't picked up by libvirt.
>
> As for vice-versa, sorry but I haven't tried whether libvirt managed
> xen domains are picked up by xl.

FYI, just now I finally stopped beating around the bush and investigated
libvirt/libxl with libvirt managed domU a bit further:

  * shutdown a particular domU (xl shutdown host)
  * removed it's /etc/xen/host.cfg file (no way it's xl managed anymore)
  * created /etc/libvirt/libxl/host.xml file
  * restarted libvirtd
  * started the domU with libvirt (virsh start host)

This worked fine.  The ‘virsh list’ output properly reports ‘running’.
This also answers your earlier vice-versus question: the xl tool *does*
recognize the libvirt managed domU just fine.  In other words, the
best-of-both-worlds setup.

However after doing this I discovered that there are many features in
the libvirt/libxl driver that are unimplemented¹, in particular, missing
functions that the originally sought after munin-libvirt-plugins
requires, for example:

  virsh # domblkstat host
  error: Failed to get block stats host
  error: this function is not supported by the connection driver: virDomainBlockStats

Scanning through git logs², I see no indication that these missing
features are being worked on.

Given that nothing has been gained, and that I'm not using any libvirt
software that doesn't depend on unimplemented features of the
libvirt/libxl driver, I'll be reverting back to xl managed.

>>> I had dropped in munin-libvirt-plugins and libvirt-bin (0.8.3 and
>>> 0.9.12) for the sole purpose of monitoring the domU's memory/cpu/io.
>>> This worked without any configuration other than specifying "uri
>>> xen:///" in the munin-node plugin configuration.  During the
>>> "heartbleed" panic, after hastily reacting to the output of
>>> checkrestart, I accidently discovered that "service libvirt-guests
>>> restart" actually handles restarts of these "unmanaged" domU's.
>>> Fantastic!  Consequently I've been telling sysadmin colleagues that
>>> libvirt is great because it integrates non-intrusively and can
>>> handle heterogeneous VM environments.
>>
>> It's bad that this isn't true for Jessie anymore but looking at the
>> uptream list it seems most distros are switching over to libvirt
>> managed xen domains.
>
> Interesting.  I wonder if systemd-machined has been integrated with
> libvirt - yet another compelling reason to change management stacks.

BTW, to answer my off-topic question about whether the libvirt stack
integrates with systemd-machined, apparently not - nothing changed with
machinectl output: systemd is unaware of the libvirt managed domU.

¹ https://libvirt.org/hvsupport.html
² http://libvirt.org/git/?p=libvirt.git;a=history;f=src/libxl/libxl_driver.c

-- 
Gerald Turner <gturner at unzane.com>        Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-libvirt-maintainers/attachments/20150516/4b9fdd56/attachment.sig>