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. 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? Is there a way to request that qemu close an arbitrary fd that was passed to it earlier on? Otherwise, libvirt has just leaked an fd to qemu, and we have a repeat of the earlier bug report where if the fd is a lvm partition, then the leaked reference prevents one from closing out the logical volume. I don't want to have to resort to brute-force searching through /proc/<qemu-pid>/fd to find which fd in qemu matches the one that libvirt sent over. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list