From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbVZP-00050K-OX for qemu-devel@nongnu.org; Fri, 27 Mar 2015 10:49:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbVZL-00058X-HG for qemu-devel@nongnu.org; Fri, 27 Mar 2015 10:49:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbVZL-00058M-9Z for qemu-devel@nongnu.org; Fri, 27 Mar 2015 10:49:07 -0400 Message-ID: <55156DE0.4050209@redhat.com> Date: Fri, 27 Mar 2015 08:49:04 -0600 From: Eric Blake MIME-Version: 1.0 References: <55151DB7.3090200@msgid.tls.msk.ru> In-Reply-To: <55151DB7.3090200@msgid.tls.msk.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fIXa6UpIv9xSw7KJg4EUEgm8WMM26C0Tm" Subject: Re: [Qemu-devel] block-commit & dropping privs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev , qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fIXa6UpIv9xSw7KJg4EUEgm8WMM26C0Tm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/27/2015 03:07 AM, Michael Tokarev wrote: > Hello. >=20 > I tried to experiment with block-commit command, which propagates > changes accumulated in an overlay (qcow2) block image file back to > the base image file. >=20 > And immediately faced a problem. All my VMs are run chrooted into > an empty dir and with low-priv user (using -runsa and -chroot options, > initially started as root). Ofcourse this low-priv qemu process > can't open the base image anymore, because it doesn't have the > necessary permissions and because the base file is inaccessible > within the chroot. >=20 > So I wonder if we can avoid reopening the base img by always opening > it read-write (using a command-line option), does it make sense? It is already possible to open a file read-write on the command line, by using -add-fd twice to put both a read-only and a read-write fd handle to the same file in a single set N, then using -drive options to specify /dev/fdset/N rather than the file name. By that argument, I'm not sure if adding any other command line options is necessary. >=20 > Or maybe there's some other possible solution to this, for example, > passing in a filedescriptor for the new base img over a unix socket? Hmm, we do allow QMP to pass in fds over Unix sockets already, but what we don't have yet is the ability to associate one of those just-passed fds to an existing open BDS (right now, you can only create a new fdset as tied to a new BDS, but block-commit can only target an open BDS; there is no way to pivot which BDS base is associated with another BDS). So maybe there is still room for improvement, especially since having a QMP solution is nicer than requiring foresight to pass in an fdset from the command line. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fIXa6UpIv9xSw7KJg4EUEgm8WMM26C0Tm 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVFW3gAAoJEKeha0olJ0NqZbcH/1/8mrSIP1Rs9jWQ7ug3svtE XeJ60zbFZZh4VgyNMaYIzXIPNVBRId85CZERI/VUz/DihyUDV7jIU9W14HmkjIRo 79b9Bhubzdo7ijxtWsLnKvVf/Wwy+RzsCavB6y6sOLA5N+o4eqit+rzyaOypwU7f tU4m78K64rEJ361TPuzFHDvA0oT03l9X+XkuthVNyD7dpg06vpuF7sGGr4Io3fod Vdpif+8WXcE1y/SC33YxEPSnEE89v3MoiCvOIyTDDQHN+I2vMTfuvZJW9pRzWm3U wsEFZXciv0Un6Qs2g6ClHDRaog8l1diyXZC65l1ONuN/IOPDs6Z5mp5cBZEhv/0= =FmGV -----END PGP SIGNATURE----- --fIXa6UpIv9xSw7KJg4EUEgm8WMM26C0Tm--