[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode
From: |
Jamie Lokier |
Subject: |
Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode |
Date: |
Wed, 13 Aug 2008 00:56:56 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, (continued)
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Anthony Liguori, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Daniel P. Berrange, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Ian Jackson, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Anthony Liguori, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Jamie Lokier, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Ian Jackson, 2008/08/11
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Kevin Wolf, 2008/08/12
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Anthony Liguori, 2008/08/12
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode,
Jamie Lokier <=