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

Re: [Xen-devel] [RFC v2 8/9] HACK libxl_exec: Check QEMU status via QMP instead of xenstore

Anthony PERARD writes ("[RFC v2 8/9] HACK libxl_exec: Check QEMU status via QMP 
instead of xenstore"):
> When QEMU is restricted, the qemu on the receiving side cann't write
> anything to xenstore once the migration is started. So it cann't tell
> libxl that it is ready to continue running the guest.
> This patch creates a pipe, give the write-end to qemu, and wait for
> something to be written to it. (We could check if it is actually the QMP
> greeting message.)

This is indeed the kind of thing I had in mind in our IRL

> QEMU is asked to setup a QMP server on this pipe, but even if it is a
> one-way only, qemu will write the QMP greeting message to the pipe.
> This is done with:
> -add-fd, to create a fdset which is use later.
> -chardev 'file,path=/dev/fdset/1,append=true', this open a char device
> on the write-end of the pipe, tell qemu that the FD is write-only, and
> not to run truncate on it.
> -mon, just start the QMP server on this new chardev.

Have you considered socketpair() ?  That avoids the oddnes of passing
qemu a write-only fd.

Anyway, I'm not sure why this approach justifies HACK.  Are all the
things you are asking qemu to do not fully supported ?

> This patch copies most of "xswait" and call it "qmpwait". This is
> probably not the best way forward due to duplication.

Ah.  Indeed :-).

I haven't reviewed the code yet, only your description.


Xen-devel mailing list



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