Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode

[Jamie Lokier <jamie@shareable.org>]

Anthony Liguori wrote:
> Which is fine, but you're missing my fundamental argument.  Having a 
> read-only flag exposed to the user should not translate to "open the 
> underlying files O_RDONLY".  That's an implementation detail.  If that's 
> what ends up happening, great.  However, I'll make the argument also 
> that for certain circumstances that's not actually what we want.

And when the file is not owned by the user running QEMU?
I.e. it's shared.

> >>qemu-system-x86_64 -drive file=foo.img -drive file=boo.img,read-only=on
> >>
> >>Down the road, you do a savevm.  savevm has to create a checkpoint in 
> >>all disk images.  The checkpoint will be empty in boo.img but it still 
> >>needs to create one.
> >
> >Perhaps I don't understand clearly enough how you imagine this
> >scenario.  Surely when the snapshot is resumed it is sufficient for
> >the file boo.img to be identical ?
> 
> Not really.  When the snapshot is restored, what do you do with 
> boo.img?  Do you just use the main L1 table if no properly named 
> snapshots are available?  That seems quite error prone to me.

That's a fair question.

But if boo.img is used with several concurrent QEMUs - a legitimate
use of a read-only disk image - how can writing snapshot metadata to
it be safe?

TBH, the snapshot behaviour is really confusing and the snapshot
behaviour is not well documented.  Let's see:

   1. It will write a snapshot record to read only qcow2 images, but
      not to raw images?  So they *behave* differently - it's not
      merely a different format, it has side effects.  What if I don't
      want side effects, I just want a compact format?

   2. You *need* the snapshot record stored in qcow2, yet it's ok that
      raw doesn't store it?  Seems to me sometimes I don't need the
      snapshot record, it would be nice if I could request not to have
      it.  I always resume from the last saved snapshot anyway - which
      was always made with the CPU stopped.  (Simulated suspend/resume).

   3. The documentation (that I found) does not explain that snapshot
      records the *disk* state as well as the machine state.  This was
      a big surprise to me.  It does say you need at least one qcow2
      file before snapshot is possible.

   4. Which file is the machine state stored in?  The first one on the
      command line, or the first disk index?

   5. As the disk state is snapshotted - how do I extract a
      snapshotted disk e.g. to "qemu-img convert" it or transport it
      into something else?  Can I delete a snapshot without starting
      qemu with the *exact same arguments* as before, except -S, and
      doing it from the monitor?

   6. What do "commit" or "qemu-img commit" do to snapshots?  Do they
      break all snapshots but the current one?

   7. What happens if qemu dies / is killed / host crashes / power
      fails during "commit" or "savevm"?  Does it leave the files
      inconsistent and the VM wrecked?  Both functions can take quite
      a long time.

   8. Sometimes I want a (machine-state) snapshot and I *don't* want
      to use qcow2 for the disk image.  It seems non-orthogonal that I
      can use raw images (or other formats) for all but one disk - ok
      I have to be careful to only resume from that particular
      snapshot, or by rebooting afresh (simulated unclean boot) - but
      I can't use raw images for all disks.

   9. Sometimes I want a disk-state snapshot (now that I know about
      them :-) and I *don't* want a machine-state snapshot.  In other
      words, I may want to boot using a disk snapshotted earlier,
      without initialising device state from that snapshot -
      especially when using a much different version of QEMU, KVM or
      Xen.  There is no harm in using the disk - it just looks like a
      CPU reset to the guest, which is acceptable - even clean if the
      save happened with the guest in a safe state.  Currently I am
      using "qemu-img -b" branches to get a similar effect -
      snapshotting disks seems much better, since you don't have long
      commit pauses to tidy up.

> Another example is introducing a copy-on-read disk.  This would be 
> useful for image stream.  Think a qcow2 file that backs an http block 
> device.  The perfect use-case for something like this is an ISO image 
> which a user would want to export to the guest read-only.  However, we 
> need to modify the qcow2 image as the guest reads it (to do the 
> copy-on-read).

That's a good example.  If copy-on-read is implemented, you won't see
me or anyone objecting to it opening the file writable!

> N.B. I've said before that there's no reason that a read-only disk 
> cannot result in the file being opened O_RDONLY (for raw in particular) 
> but that is a detail of each block device and I don't think it should be 
> the case for qcow2.

Another reason why I've begun recommending to clients to stop using
qcow2 then for important VMs (the other is possible corruption on qemu
death / power failure), unless they have really tight space issues.

-- Jamie