| Summary: | after live snapshot, a "snapshot=on" block device becomes read-only | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> | |
| Component: | qemu-kvm | Assignee: | Jeff Cody <jcody> | |
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.0 | CC: | acathrow, chayang, eblake, hhuang, jcody, juzhang, michen, pbonzini, qzhang, virt-maint, xfu | |
| Target Milestone: | rc | Keywords: | Reopened | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1036450 (view as bug list) | Environment: | ||
| Last Closed: | 2014-01-28 20:05:09 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1036450 | |||
|
Description
Sibiao Luo
2013-12-02 02:17:26 UTC
Specifying both readonly=on and snapshot=on is somewhat counterintuitive. With snapshot=on, that does not deal with live snapshots, but tells QEMU to make a temporary difference file for the current session. If the user then wants to save that data, the user can do a block commit from the HMP interface, which will commit the changes in the temporary difference file back into the image file. The flag readonly=on will make the actual image file readonly, which it would also be in the case of snapshot=on. So in reality, in both of those cases the image file remains read-only: With readonly=on without snapshot=on: [base]<----[top (r/o)] With readonly=on with snapshot=on: [base]<----[top (r/o)]<----[tmp (r/w)] In both of those cases, the image file 'top' is not modified and remains r/o (unless a block commit is performed to push 'tmp' changes into 'top') I am going to close the bug as "NOTABUG". If you disagree, go ahead and reopen the bug. > In both of those cases, the image file 'top' is not modified and remains r/o
> (unless a block commit is performed to push 'tmp' changes into 'top')
But here can the VM write to tmp?
[base]<----[top (r/o)]<----[tmp (r/w)]
If it can write, it should still be able to do that after a live-snapshot. If it cannot, the guest should see the disk as readonly, and it should remain read-only after a live-snapshot (even if you bypass the guest driver using virtio-scsi and, as root, "sg_dd blk_sgio=1").
(In reply to Paolo Bonzini from comment #2) > > In both of those cases, the image file 'top' is not modified and remains r/o > > (unless a block commit is performed to push 'tmp' changes into 'top') > > But here can the VM write to tmp? > > [base]<----[top (r/o)]<----[tmp (r/w)] > Yes. > If it can write, it should still be able to do that after a live-snapshot. Do you mean a live snapshot on top of tmp? I don't think you can do that. Do you mean: readonly=on [base]<----[top (r/o)]<-----[snap1 (r/w)] is the expected behavior? If so, that is not what happens. Instead, this is what happens: readonly=on [base]<----[top (r/o)]<-----[snap1 (r/o)] I suppose I could see the argument for snap1 being r/w, as the idea of a new difference file when the drive is read-only is kind of odd. > If it cannot, the guest should see the disk as readonly, and it should > remain read-only after a live-snapshot (even if you bypass the guest driver > using virtio-scsi and, as root, "sg_dd blk_sgio=1"). > > If it can write, it should still be able to do that after a live-snapshot.
>
> Do you mean a live snapshot on top of tmp? I don't think you can do that.
You can actually. It doesn't make much sense alone, but you could follow it by a block-stream command to remove tmp from the chain.
So after you start the VM you have this:
[base]<----[top (r/o)]<----[tmp (r/w)]
after you make a live snapshot you have this:
[base]<----[top (r/o)]<----[tmp (r/w)]<----[snap1 (r/o)]
And the bug is that snap1 should be r/w *or* tmp should be r/o *or* readonly=on,snapshot=on should be forbidden.
Given that, I think the most logical conclusion is to forbid readonly=on,snapshot=on as you mentioned. It is either redundant (in both cases the drive image is preserved r/o), or illogical (a read-only ephemeral snapshot with no data makes no sense). Reopening bug, and moving it to assigned - I'll submit a patch to prevent readonly=on,snapshot=on Eric, If QEMU flagged an error on snapshot=on,readonly=on being used together as a drive argument, do you know if this would affect libvirt negatively? (In reply to Jeff Cody from comment #6) > Eric, > > If QEMU flagged an error on snapshot=on,readonly=on being used together as a > drive argument, do you know if this would affect libvirt negatively? Libvirt doesn't use snapshot=on (probably never will - bug 1040068 says we want to avoid TMPDIR issues for sVirt reasons, and will instead have to implement our <transient> tag by pre-creating the snapshot before starting qemu). So no, this would have no ill effects on libvirt. (In reply to Eric Blake from comment #7) > (In reply to Jeff Cody from comment #6) > > Eric, > > > > If QEMU flagged an error on snapshot=on,readonly=on being used together as a > > drive argument, do you know if this would affect libvirt negatively? > > Libvirt doesn't use snapshot=on (probably never will - bug 1040068 says we > want to avoid TMPDIR issues for sVirt reasons, and will instead have to > implement our <transient> tag by pre-creating the snapshot before starting > qemu). So no, this would have no ill effects on libvirt. Since this option is not used by libvirt, we can safely close it as WONTFIX in RHEL7, because we won't support direct usage of QEMU. Jeff plans to fix it upstream though, as the patch appears to be simple. |