[Top][All Lists]

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

Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing usin

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd
Date: Fri, 18 May 2012 11:38:06 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]