Re: Testing status of fully virtualized guests (Intel VT) on 64bit XEN unstable

[Anthony Liguori <aliguori@us.ibm.com>]

I'll have a fix by the end of the night.

I suspect that the problem is that the threads used for each XML-RPC 
request are not exiting because of the child process spawned during HVM 
creation.

Since we switched to HTTP/1.1, this is confusing the client as it thinks 
the server is doing Keep-Alive (when it's not).

Technically speaking, we've had a broken HTTP/1.0 implementation for 
quite some time (as we didn't close the connection).  However, the 
Python HTTP/1.0 client seemed to cope with this which is why we haven't 
seen it as a bug.

I'm experimenting with something that fixes the HVM creation to do the 
Right Thing.  If I don't have something useful by the end of the 
evening, I'll just submit a patch to default back to HTTP/1.0.

It would be nice to fix it the right way though as HVM creation causes a 
pretty ugly bug in libvirt which is making HVM domains non-controllable 
with the CIM providers.

Regards,

Anthony Liguori

Ed Smith wrote:
> Nakajima, Jun wrote:
> > Yes, we are observing the same problem. Our team is saying it would 
> work
> > if the changeset 10454 "Add support to Xend XML-RPC server for HTTP/1.1
> > Keep-Alive" is backed out.
> >
> > Looks like the newly created HVM guest is placed into the pause state.
> > If we do xm unpause, it starts running.
>
>
> Ed Smith wrote:
>> Summary:
>> Changeset 10470
>> - NEW: 32bit and 64bit guests will not start, VCPU get no runtime.  On
>>   the domain destroy we crash in vmx_clear_vmcs. (see failure.13)
>> - Guest networks fail to come up, netdev=eth1 (see failure.12)
>
> I tried an xm unpause and my guest did indeed boot.  Thanks Jun!  
> However once
> booted the guest network will not come up, the problem I started 
> seeing when I
> moved up to changeset 10449.
>
> Ed
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel