On 03/02/2011 06:16 AM, Eric Blake wrote:
On 01/03/2011 06:39 AM, Paolo Bonzini wrote:
On 12/23/2010 05:51 PM, Eric Blake wrote:
In the outgoing direction, we still have to use a unix socket (outgoing
migration is started via a monitor command, and I don't know how to pass
a new fd into qemu for using with an fd:n outgoing migration via the
monitor - it seems like fd is only useful on the command line).
See qemuMonitorCommandWithFd and qemuMonitorJSONCommandWithFd.
I'm looking at this problem again, now that we know that qemu exec:
migration is inherently racy (see
https://bugzilla.redhat.com/show_bug.cgi?id=678524). I've managed to
work out the code to send an fd over to qemu, but how do I formulate the
fd:n migration command to use that fd? That is, if I call
qemuMonitorCommandWithFd(,20), that copies fd 20 from libvirt's point of
view into qemu, but using the command 'migrate fd:20' is wrong because
qemu's copy is not necessarily fd 20.
This doesn't matter. Libvirt passes its own fd 20 to QEMU "by name" via
SCM_RIGHTS and the getfd command (which associates a name to the file
descriptor being sent at the same time). What is then passed to
"migrate fd:", is the symbolic name.
Actually, you do not need to call qemuMonitorCommandWithFd. What you
need to do with it is already wrapped by qemuMonitorSendFileHandle. So
you will do something like qemuMonitorSendFileHandle(mon, "migr-1", 20)
and then use "fd:migr-1" on the migrate command.
Is there a monitor command that lets libvirt pass in an fd and get a
return value of what qemu sees for that newly copied fd, with no other
operation? If so, then I can use that to do a two-step process - first
pass the fd, then pass the migrate fd:n command. And what if the first
step succeeds but the second fails?
I believe the fd will be closed even if it fails, but there is also
qemuMonitorCloseFileHandle that you can use.
Paolo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list