Re: [libvirt] libxl: Issues with virt-manager when used to manager Xen domains

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