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

Re: [Xen-devel] Re: [RFC] "xs_read(): uuid get error" of qemu-dm



On Wed, Nov 08, 2006 at 03:13:43PM +0900, Masami Watanabe wrote:

> Hi Keir,
> 
> My explanation was insufficient.
> 
> "xs_read(): uuid get error" happens when uuid can't read from xenstore
> in xenstore_read_vncpasswd@tools/ioemu/xenstore.c.
> 
> c/s 12187 evaded this problem when the guest rebooted in a lot of
> environments. As for my environment, the problem was corrected by this
> correction.
> 
> However, Afterwards, following problem keeps happening.
> I think that it is a problem.
> 
> [Xen-devel] VMX status report 12254:f8ffeb540ec1
>   http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00288.html
> [Xen-devel] VMX status report 12217:20204db0891b
>   http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00183.html
> >  IA32/PAE/IA32E: Windows and Linux VMX domains may fail to be
> > created, the qemu-dm process is <defunct>, and the qemu log says
> > "xs_read(): uuid get error."
> 
> 
> I examined it.
> As a result, In the environment that allocated two or more CPU in
> Dom0, this problem was able to be caused.
> The result of the confirmation is as follows.
> - uuid cannot be read with xenstore_read_vncpasswd() in qemu-dm.
> - uuid can often be read by changing the order of vm.initDomain()
>   and vm.storeVmDetails() in create()@XendDomainInfo.py.
> - And, when the read timing is delayed in qemu-dm, It was possible
>   to always read.
> 
> >From the above, I thought that this problem was a problem of the timing
> of writing and reading to xenstore from another process.
> 
> 
> > Is the passwd getting written after qemu
> > is started and hence racing the xs_read() in xenstored?
> 
> Yes, maybe. I understand the order of processing xend as follows.
> Is it my misunderstanding ?
> 
>   create()@XendDomainInfo.py+135
>       start()
>           _initDomain()
>               _createDevices()
>                   createDeviceModel(self)@image.py
>                       os.spawnve()  ==============>  start qemu-dm process
>           _storeVmDetails()
>               _writeVm()            ==============>  write to xenstore
>               _setVmPermissions()

I've just put a patch in that ought to help.  We can't reproduce this race
here, but perhaps you could give it a try for me.

diff -r 9a43cc89ae0a tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py   Wed Nov 08 18:27:31 2006 +0000
+++ b/tools/python/xen/xend/XendDomainInfo.py   Wed Nov 08 18:08:28 2006 +0000
@@ -678,6 +678,7 @@ class XendDomainInfo:
         t.remove()
         t.mkdir()
         t.set_permissions({ 'dom' : self.domid })
+        t.write('vm', self.vmpath)

     def _storeDomDetails(self):
         to_store = {


The /vm/<uuid>/vncpasswd node is written before the call to createDeviceModel,
in configVNC, but you need the /local/domain/<domid>/vm node to be present
too, and it's this one that isn't written until after qemu-dm is started.

HTH,

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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