From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV1Tp-0001nD-Jc for qemu-devel@nongnu.org; Thu, 17 May 2012 10:15:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SV1Tn-0001lA-96 for qemu-devel@nongnu.org; Thu, 17 May 2012 10:15:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV1Tn-0001k5-16 for qemu-devel@nongnu.org; Thu, 17 May 2012 10:14:59 -0400 Message-ID: <4FB507B7.7020706@redhat.com> Date: Thu, 17 May 2012 08:14:15 -0600 From: Eric Blake MIME-Version: 1.0 References: <1335886307-27586-1-git-send-email-stefanha@linux.vnet.ibm.com> <20120517134228.GA5079@stefanha-thinkpad.localdomain> In-Reply-To: <20120517134228.GA5079@stefanha-thinkpad.localdomain> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig34C04404272185194B634871" Subject: Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Zhi Yong Wu , Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, libvir-list@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34C04404272185194B634871 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote: >>> >>> The -open-hook-fd approach allows QEMU to support file descriptor pas= sing >>> without changing -drive. It also supports snapshot_blkdev and other = commands >> By the way, How will it support them? >=20 > 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 i= n > 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. >=20 > 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig34C04404272185194B634871 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPtQe4AAoJEKeha0olJ0NqDdYH/iDlkq7DjOHd54uiAr1avnrm jYM+9L0Guto6MivKuZMgWBTJGAiTG6b4x3gbYO4cm6IATzhX/53dRDaPRs7TYC9b QYh88tGSKkJPiUHc3dGXtE3TKBv9NJuMdL8XLsDr2ZWtHaVd9tK+fSkRZxJ6uTZR 8JW6zG6ZFTkAc9vpcTGzWd6PmRD5rs+1AovEcoymvSpGO7EipM2ALEkE/qTh8pzG kJlf7nD3bR1xe+uZS+8gcIHhn2qcj0RZmCTgxdTdYTjARja6xi4aJsdtB7RJPbaQ ZNAb1bssw5JbfGGRqNtrAuN+BOtAbdqznQjIWcuWI7aQ4zy2ekObcVLj+fFvjdw= =MmuL -----END PGP SIGNATURE----- --------------enig34C04404272185194B634871--