On 04/08/2012 03:19 PM, Cole Robinson wrote:
On 04/02/2012 10:38 AM, Stefan Bader wrote:
xen-hypervisor: GetVcpus may not find a certain domain
Observed on connections that have been running and then shut down. The hypervisor subdriver fills the log with internal errors while the xend driver actually can handle the query.
This only handles the case which I observed after shutting down an instance via virt-manager and leaving its console window open. The same reasoning would probably be true for other internal errors as long as they potentially get recovered by other sub-drivers.
BugLink: http://bugs.launchpad.net/bugs/963006
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Index: libvirt-0.9.8/src/xen/xen_driver.c =================================================================== --- libvirt-0.9.8.orig/src/xen/xen_driver.c 2011-12-02 04:59:50.000000000 +0100 +++ libvirt-0.9.8/src/xen/xen_driver.c 2012-03-23 11:31:53.982620050 +0100 @@ -1190,6 +1190,8 @@ if (ret > 0) return ret; } + + xenUnifiedError(VIR_ERR_NO_SUPPORT, __FUNCTION__); return -1; }
I don't think this piece is correct, since this will overwrite any error raised by sub drivers. It should just be dropped.
Index: libvirt-0.9.8/src/xen/xen_hypervisor.c =================================================================== --- libvirt-0.9.8.orig/src/xen/xen_hypervisor.c 2012-03-23 10:58:29.000000000 +0100 +++ libvirt-0.9.8/src/xen/xen_hypervisor.c 2012-03-23 11:26:50.741137585 +0100 @@ -3612,8 +3612,11 @@ &dominfo);
if ((ret < 0) || (XEN_GETDOMAININFO_DOMAIN(dominfo) != domain->id)) { - virXenErrorFunc(VIR_ERR_INTERNAL_ERROR, __FUNCTION__, - _("cannot get domain details"), 0); + /* This can happen if an instance is just shut down. It is probably + * better to leave the shouting to the unified caller. + * virXenErrorFunc(VIR_ERR_INTERNAL_ERROR, __FUNCTION__, + * _("cannot get domain details"), 0); + */ return (-1); }
This is kind of a hack. The whole xen driver arch is pretty weird though so error handling is just strange as it is.
But isn't this all a side effect of the bug that your previous patch fixes? virt-manager won't call GetVCPUs on an inactive VM, it's only doing so in this case because libvirt and xen get out of sync. So I think fixing the previous bug should stop the error log spew.
I know it is definitely a hack. But it really happened _after_ the other fix was applied. But only when the terminal/vnc viewer window is open. Something in vit-manager must be using GetVCPUs even after shutdown. But I agree that the architecture is weird the first place. Having multiple subdrivers called in sequence it seems a general problem to have any errors reported in one. The next one can succeed and then its not an error. At least in my understanding. -Stefan
Thanks, Cole