blob: fd41078ad10c150720016af9909eb492a8769472 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
virtual: 0.851
graphic: 0.817
device: 0.804
PID: 0.782
network: 0.762
hypervisor: 0.756
peripherals: 0.750
performance: 0.749
architecture: 0.747
semantic: 0.746
KVM: 0.744
user-level: 0.742
socket: 0.730
files: 0.707
arm: 0.705
vnc: 0.702
permissions: 0.701
mistranslation: 0.701
ppc: 0.692
risc-v: 0.688
assembly: 0.688
kernel: 0.676
x86: 0.674
VMM: 0.666
debug: 0.628
i386: 0.621
register: 0.613
boot: 0.549
TCG: 0.521
qemu-nbd: always first snapshot loaded from VDI images with snapshots
When mounting a virtual box disk image of a VM with snapshots, always the state of the first snapshot is shown.
How to reproduce:
1. Create a new VirtualBox VM or use an existing one, while choosing VDI as the disk image format.
2. Create a snapshot of the VM.
3. Modify the file system from within the VM enough that differences to the snapshotted version are apparent.
4. Create another snapshot.
5. Shut down the VM.
6. Mount the partition from the disk image with `qemu-nbd -c /dev/nbd0 /path/to/disk.vdi; mount /dev/nbd0pX /mnt`
Expected result: The mounted disk image shall represent the latest state of the VM
Actual result: The mounted disk image represents the VM state at the first snapshot
version information: qemu-nbd-2.11.1(openSUSE Tumbleweed)
Hi,
As far as I can tell that's because only the first snapshot is actually stored in the VDI.
(1) I've created a VM with /tmp/foo.vdi as storage
(2) Executed "echo 'snapshot' > /dev/sda" in the guest
(3) Took a snapshot
(4) Executed "echo 'next snapshot' > /dev/sda" in the guest
(5) Took a snapshot
(6) Executed "echo 'active layer' > /dev/sda" in the guest
$ strings /tmp/foo.vdi
<<< Oracle VM VirtualBox Disk Image >>>
snapshot
$ ls ~/VirtualBox\ VMs/foo/Snapshots
{c9a75c86-6c0d-4aaa-9d24-cbd4456c74fb}.vdi {ce16e224-fa61-4b26-a5c5-21d92062ced7}.vdi
$ strings ~/VirtualBox\ VMs/foo/Snapshots/\{ce16e224-fa61-4b26-a5c5-21d92062ced7\}.vdi
<<< Oracle VM VirtualBox Disk Image >>>
next snapshot
$ strings ~/VirtualBox\ VMs/foo/Snapshots/\{c9a75c86-6c0d-4aaa-9d24-cbd4456c74fb\}.vdi
<<< Oracle VM VirtualBox Disk Image >>>
active layer
So snapshots in VDI apparently are what qemu calls external snapshots, so they work through backing file links -- and the original file is simply the bottom-most backing file (that is, the oldest snapshot). So the file you'd want to open is {c9a75c86-6c0d-4aaa-9d24-cbd4456c74fb}.vdi.
However:
$ qemu-img info \{ce16e224-fa61-4b26-a5c5-21d92062ced7\}.vdi
qemu-img: Could not open '{ce16e224-fa61-4b26-a5c5-21d92062ced7}.vdi': unsupported VDI image (non-NULL link UUID)
So qemu doesn't support this now. The current behavior is more or less correct (because the file only contains the data of the oldest snapshot), supporting snapshots would be a feature request.
Max
Closing this as WontFix since it works as expected, and keeping it open as wishlist item does not make too much sense.
The QEMU project normally doesn't implement new features like these external snapshots on demand; they're a lot of work to do. Instead we simply code-review and incorporate such features as and when people decide to write them and submit the patches. So there's not much point in having a 'wishlist' bug in the bug tracker saying "support for feature X would be nice", because it will likely never happen, unless by the coincidence that somebody happened to implement and submit it to us anyway. Sorry for the inconvenience and thanks for your understanding.
|