[Libvir] virsh start problem + patch

[Tóth István]

Actually, there are two different problems here.

----------------------------------------------------------------------------------------------------------------------------

One is that a freshly installed xen hvm windows domain is stuck in the
----- state, until I reboot Dom0.

The way to reproduce the problematic ------ state in xen is to do a
fresh install of windows xp by virt-install.

# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  - windows-xen          shut off
  - windows-xen2         no state

# xm list
Name                                        ID   Mem VCPUs      State
Time(s)
Domain-0                                     0  3489     4     r-----
853.6
windows-xen                                  1   512     0
-b-s-d     39.4
windows-xen2                                 4   512     0
------     22.5

The windows-xen, and windows-xen2 domains  were installed the very same
way, except I've had a Dom0 reboot since I've installed windows-xen, so
xen has had the opportunity to sort it's state out, whil the
windows-xen2 domain is a fresh install. Starting and stopping (by xm) a
freshly installed windows hvm domain does not sort out the state, only a
Dom0 reboot (or  a xend restart) does.

I have attached the output of xm list --long command.

This problem indeed does look like a Xend bug, but it turns out that it
does not actually affect virsh. (It does affect virt-manager, as I've
written to the other list)

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The other problem is I am pretty sure, a virsh logic bug, and is
independent of the first one.

Virsh cannot start ANY managed xen domain, wheter it's stuck in ------,
or in a completely legal state.

I've added a debug statement to (unpatched virsh) cmdStart here:

    if (!(dom = vshCommandOptDomainBy(ctl, cmd, "name", NULL, VSH_BYNAME)))
        return FALSE;

 >>>    printf("virDomainGetID(dom) returns %d", virDomainGetID(dom));

    if (virDomainGetID(dom) != (unsigned int)-1) {
        vshError(ctl, FALSE, "%s", _("Domain is already active"));
        virDomainFree(dom);
        return FALSE;
    }


and I get this:

./virsh start windows-xen
<warnings>
error: Domain is already active
virDomainGetID(dom) returns 1

./virsh start windows-xen2
<warnings>
error: Domain is already active
virDomainGetID(dom) returns 3

so virDomainGetID() does not return -1, but returns the actual xen
domain id of the managed, but inactive xen domain, and I believe this is
what it should do,
as it's job is not to tell us about the state of the domain, but to tell
the id of the domain, regardles of its state.

Xend knows about the domain, so libvirt knows about the domain, it does
have an id despite being inactive, and virDominGetID tells it to us.
That's the way a managed xen domain should work in my opinion.

Back in the day of unmanaged xen domains, this code did the right thing,
as Xend knew only about running domains, but managed domains changed the
semantics,and now defined but inactive domains have domain ids.

So I still think that we do need to check the domain state in cmdStart,
as my patch does.

Actually virsh start should work without any state check, as the lower
layers would throw an error if we tried to start a running domain
anyway, but it would be sloppy.

regards

István Tóth


Daniel P. Berrange wrote:
> On Mon, Mar 10, 2008 at 11:37:19AM +0000, Richard W.M. Jones wrote:
>   
>> On Sat, Mar 08, 2008 at 09:47:43AM +0100, Toth Istvan wrote:
>>     
>>> I've looked into the virsh code, and it seems that it was written with
>>> only only old-style xen in mind, and xen 3.1's managed domains break the
>>> logic.
>>>       
>> I don't understand this statement.  The current 'cmdStart' code checks
>> if the domain ID is -1 (ie. a managed domain, but inactive), and that
>> seems correct.
>>     
>
> This sounds very much like a bug in XenD to be be honest. If libvirt has got
> an ID of -1 then the domain is definitely dead - libvirt talks directly to
> the hypervisor. So if XenD meanwhile things its not dead, then its a XenD
> bug.
>
> Dan.
>   


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xmlist-long-2
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20080311/e4078a91/attachment-0001.ksh>