vzdump and qmrestore LV reordering

[ib.pl]

Hi,

When doing VM backup->restore in PVE2.1 (KVM, 2 LVM based disks) we've noticed that restored VM has reordereddisk LV naming; might be dangerous if one won't notice this change and resize wrong LV for example...

Example:

(1)
/etc/pve/qemu-server/123.conf:

bootdisk: virtio0
cores: 1
lock: backup
memory: 1024
name: TESTHOST
net0: virtio=3A:CE:E9:11:22:33,bridge=vmbr0
onboot: 1
ostype: l26
sockets: 2
startup: order=101,up=5,down=180
virtio0: myvg:vm-124-disk-1
virtio1: myvg:vm-124-disk-2
​

(2)
Backup of this VM in PVE web console:

INFO: starting new backup job: vzdump 124 --remove 0 --mode stop --compress gzip --storage backup --node myhv
[...]
INFO: adding '/bkp/dump/vzdump-qemu-124-2012_11_03-15_14_50.tmp/qemu-server.conf' to archive ('qemu-server.conf')
INFO: adding '/dev/myvg/vm-124-disk-2' to archive ('vm-disk-virtio1.raw') # here vzdump first processes second disk
INFO: adding '/dev/myvg/vm-124-disk-1' to archive ('vm-disk-virtio0.raw')
[...]
INFO: Backup job finished successfully
TASK OK
​

(3)
After backup qemu-server.conf file in backup tar.gz file contains:

bootdisk: virtio0
cores: 1
lock: backup
memory: 1024
name: TESTHOST
net0: virtio=3A:CE:E9:11:22:33,bridge=vmbr0
onboot: 1
ostype: l26
sockets: 2
startup: order=101,up=5,down=180
virtio0: myvg:vm-124-disk-1
virtio1: myvg:vm-124-disk-2
#vzdump#map:virtio1:vm-disk-virtio1.raw:3221225472:myvg:
#vzdump#map:virtio0:vm-disk-virtio0.raw:3221225472:myvg:
​

(4)
First disk image file in tar.gz is vm-disk-virtio1.raw. When extracting, fist disk image file (vm-disk-virtio1.raw) becomes vm-998-disk-1 not vm-998-disk-2 as in original VM:

qmrestore --storage myvg vzdump-qemu-124-2012_11_03-15_14_50.tar.gz 998
extracting archive '/bkp/dump/vzdump-qemu-124-2012_11_03-15_14_50.tar.gz'
extracting 'qemu-server.conf' from archive
extracting 'vm-disk-virtio1.raw' from archive # here qmrestore creates second disk
Logical volume "vm-998-disk-1" created # as LV with numer 1 which is confusing and different than in orig VM
new volume ID is 'myvg:vm-998-disk-1'
restore data to '/dev/myvg/vm-998-disk-1' (3221225472 bytes)
[...]
extracting 'vm-disk-virtio0.raw' from archive
Logical volume "vm-998-disk-2" created
new volume ID is 'myvg:vm-998-disk-2'
restore data to '/dev/myvg/vm-998-disk-2' (3221225472 bytes)
[...]
​

(5)
After restoring:

/etc/pve/qemu-server/998.conf:
bootdisk: virtio0
cores: 1
memory: 1024
name: TESTHOST
net0: virtio=3A:CE:E9:11:22:33,bridge=vmbr0
onboot: 1
ostype: l26
sockets: 2
startup: order=101,up=5,down=180
virtio0: myvg:vm-998-disk-2 # that's why guest won't see the difference
virtio1: myvg:vm-998-disk-1 # but mixed LV numbers may cause mistakes
# during manual operations on PVE LV level
​

(6)
Now guest VMID 998 does not see the difference but PVE LV disk naming is reordered.


Fix:

This patch resolved issue for us:

--- /usr/share/perl5/PVE/VZDump/QemuServer.pm_ 2012-08-17 10:34:57.000000000 +0200
+++ /usr/share/perl5/PVE/VZDump/QemuServer.pm 2012-11-03 16:53:29.469447765 +0100
@@ -79,7 +79,9 @@

PVE::Storage::activate_volumes($self->{storecfg}, $vollist);

- while (my ($ds, $drive) = each %$drivehash) {
+ foreach my $ds (sort keys %$drivehash) {
+
+ my $drive = $drivehash->{$ds};

my $volid = $drive->{file};
​

No sure if this won't break something else (just sorting alphabetically disk hash before packing drives).

Please verify and consider fixing in mainstream.

Regards,
Pawel

IB Development Team
http://dev.ib.pl/

 

[dietmar]

Thanks for that fix. I will include that in qemu-server_2.0-68_amd64.deb