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(a)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