On Thu, May 17, 2012 at 08:14:15AM -0600, Eric Blake wrote: > On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote: > > >>> > >>> The -open-hook-fd approach allows QEMU to support file descriptor passing > >>> without changing -drive. It also supports snapshot_blkdev and other commands > >> By the way, How will it support them? > > > > The problem with snapshot_blkdev is that closing a file and opening a > > new file cannot be done by the QEMU process when an SELinux policy is in > > place to prevent opening files. > > snapshot_blkdev can take an fd:name instead of a /path/to/file for the > file to open, in which case libvirt can pass in the named fd _prior_ to > the snapshot_blkdev using the 'getfd' monitor command. > > > > > The -open-hook-fd approach works even when the QEMU process is not > > allowed to open files since file descriptor passing over a UNIX domain > > socket is used to open files on behalf of QEMU. > > The -open-hook-fd approach would indeed allow snapshot_blokdev to ask > for the fd after the fact, but it's much more painful. Consider a case > with a two-disk snapshot: > > with the fd:name approach, the sequence is: > > libvirt calls getfd:name1 over normal monitor > qemu responds > libvirt calls getfd:name2 over normal monitor > qemu responds > libvirt calls transaction around blockdev-snapshot-sync over normal > monitor, using fd:name1 and fd:name2 > qemu responds > > but with -open-hook-fd, the approach would be: > > libvirt calls transaction > qemu calls open(file1) over hook > libvirt responds > qemu calls open(file2) over hook > libvirt responds > qemu responds to the original transaction > > The 'transaction' operation is thus blocked by the time it takes to do > two intermediate opens over a second channel, which kind of defeats the > purpose of making the transaction take effect with minimal guest > downtime. And libvirt code becomes a lot trickier to deal with the fact > that two channels are in use, and that the channel that issued the > 'transaction' command must block while the other channel for handling > hooks must be responsive. > > I'm really disliking the hook-fd approach, when a better solution is to > make use of 'getfd' in advance of any operation that will need to open > new fds. This is a good technical argument for using getfd. I agree with you. Stefan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list