27.03.2015 17:49, Eric Blake wrote: > 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.
How does fdSET work? How to use it? Will the BDS reopen work with an fdset in an empty chroot? Sorry I haven't seen this so far, and documentation is a bit vague. I think I see how this should work, monitor_fdset_get_fd() will search an FD with matching access mode flags... Ok, so two fds in an fdset, one ro and one rw. And with that in mind, since qemu_open() checks if the filename starts with /dev/fdset/, it should work inside a chroot. Wonder how to specify cache mode, or should I open these with proper O_DIRECT/O_SYNC/whatever? It looks like it's possible to change O_DIRECT at runtime but not O_SYNC. And the more interesting question is how to do that from shell. Oh well. Thanks, /mjt >> 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. >
