On 03/27/2015 03:07 AM, Michael Tokarev wrote:
> Hello.
> 
> 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.
> 
> 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.
> 
> 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.

> 
> 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org