[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Testing status of fully virtualized guests (Intel VT) on 64bit XEN unstable

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.


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:
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.


Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.