From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Testing status of fully virtualized guests (Intel VT) on 64bit XEN unstable Date: Wed, 21 Jun 2006 16:16:03 -0500 Message-ID: <4499B713.8070509@us.ibm.com> References: <449940C7.1060704@virtualiron.com> <4499AE9C.6060605@virtualiron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4499AE9C.6060605@virtualiron.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ed Smith Cc: Xen Devel List-Id: xen-devel@lists.xenproject.org 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