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:
(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:
(5)
After restoring:
(6)
Now guest VMID 998 does not see the difference but PVE LV disk naming is reordered.
Fix:
This patch resolved issue for us:
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/
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
[...]
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)
[...]
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
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};
+++ /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/