xen-devel
Re: [Xen-devel] Testing status of fully virtualized guests (Intel VT) on
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|