On Tue, Mar 25, 2014 at 04:22:54PM +0100, Stefan Bader wrote:
This started off with some regression testing after going forward to
Xen-4.4. We
currently would pair that with a libvirt version 1.2.2 and right now operations
through virsh seem to be working (mostly) well. But when using virt-manager (not
the most up-to-date versions but some combinations that quite likely will occur
(0.9.1 and 0.9.5)) there are some issues.
Two symptoms seem to be caused by the same underlying problem which is caused by
the way virt-manager interacts with libvirt. That seems to be that virt-manager
acquires a reference to virDomainPtr only once and then uses that for subsequent
call. This is a problem because both virDomainPtr object and virDomainObjPtr
objects contains a domid but only the latter gets updated.
So both, creating a new guest (which must be a define step and then use the
handle to start the guest) as well as rebooting a guest cause problems for
virt-manager. Mainly because of libxlDomainGetInfo() which retrieves the
virDomainObjPtr for a given virDommainPtr. Then checks the domain object to be
active or not but uses the domid from the domain to call into libxl:
if (!(vm = libxlDomObjFromDomain(dom)))
goto cleanup;
...
if (!virDomainObjIsActive(vm)) {
info->cpuTime = 0;
info->memory = vm->def->mem.cur_balloon;
info->maxMem = vm->def->mem.max_balloon;
} else {
if (libxl_domain_info(priv->ctx, &d_info, dom->id) != 0) {
This fails either with dom->id being -1 (still) or using the old id from before
the reboot. A dirty hack seems to avoid this:
Yep, this is a pretty commonly hit problem. The solution is to *never*
access dom->id in the driver code at all. eg In this code snippet above
you could use vm->def->id instead which should be up to date.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|