This week i installed a new PVE Host in a new environment with PVE 2.2 ISO and all updates and i found an annoying behaviour in the backup/restore-procedure.
I created a new guest with 2 disks, one 400GiB and one 200GiB and even if i start a backup of the complete empty vm it takes about half an hour.
here some facts about the host and the guest
it looks like the backup is going through the whole empty space and packing it up
if i do the same on a guest created with pve2.1, then upgraded to the latest pve2.2 version its much faster (in this case there are already about 30GiB data in the guest)
i know that the behaviour on creating a qcow between 2.1 and 2.2 changed, cause in 2.1 qcows grew continually and with 2.2 they take the place they need immediately
the problem now is that it takes 25minutes longer for "nothing".
of course, you could say make the hdd smaller and expand it if necessary, but in my opinion thats not really practically
the overall 600GiB will be filled with time and the problem with lost backup-time for empty space will shrink cause then its backuping real data, but there will be always some lost time that can multiply to hours (with more machines and the more space is assigned)
is this behaviour known or even wanted?
for the end a quick pveperf so you see that the server shouldn't be the root-cause
if this is wanted by design, is there a manual possibility how i can create qcows the "old" way like in 2.1 with continually growing space?
thanks in advance, keep up the great work
I created a new guest with 2 disks, one 400GiB and one 200GiB and even if i start a backup of the complete empty vm it takes about half an hour.
here some facts about the host and the guest
Code:
pveversion -v
pve-manager: 2.2-32 (pve-manager/2.2/3089a616)
running kernel: 2.6.32-17-pve
proxmox-ve-2.6.32: 2.2-83
pve-kernel-2.6.32-11-pve: 2.6.32-66
pve-kernel-2.6.32-17-pve: 2.6.32-83
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.4-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.93-2
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.9-1
pve-cluster: 1.0-34
qemu-server: 2.0-72
pve-firmware: 1.0-21
libpve-common-perl: 1.0-41
libpve-access-control: 1.0-25
libpve-storage-perl: 2.0-36
vncterm: 1.0-3
vzctl: 4.0-1pve2
vzprocps: 2.0.11-2
vzquota: 3.1-1
pve-qemu-kvm: 1.3-10
ksm-control-daemon: 1.1-1Code:
bootdisk: ide0
cores: 4
ide0: local:102/vm-102-disk-1.qcow2,size=400G
ide1: local:102/vm-102-disk-2.qcow2,size=200G
ide2: pve:iso/ATIH2010.iso,media=cdrom,size=78656K
memory: 24576
name: guest
net0: e1000=EE:22:17:C8:F3:BD,bridge=vmbr0
ostype: win7
sockets: 2Code:
INFO: starting new backup job: vzdump 102 --remove 0 --mode snapshot --compress lzo --storage nem --node pvenem01
INFO: Starting Backup of VM 102 (qemu)
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: creating archive '/mnt/pve/nem/dump/vzdump-qemu-102-2013_02_20-14_43_13.tar.lzo'
INFO: adding '/mnt/pve/nem/dump/vzdump-qemu-102-2013_02_20-14_43_13.tmp/qemu-server.conf' to archive ('qemu-server.conf')
INFO: adding '/var/lib/vz/images/102/vm-102-disk-1.qcow2' to archive ('vm-disk-ide0.qcow2')
INFO: adding '/var/lib/vz/images/102/vm-102-disk-2.qcow2' to archive ('vm-disk-ide1.qcow2')
INFO: Total bytes written: 644343925760 (315.45 MiB/s)
INFO: archive file size: 2.44GB
INFO: Finished Backup of VM 102 (00:32:30)
INFO: Backup job finished successfully
TASK OKif i do the same on a guest created with pve2.1, then upgraded to the latest pve2.2 version its much faster (in this case there are already about 30GiB data in the guest)
Code:
INFO: starting new backup job: vzdump 101 --remove 0 --mode snapshot --compress lzo --storage nem --node pvenem01
INFO: Starting Backup of VM 101 (qemu)
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: creating archive '/mnt/pve/nem/dump/vzdump-qemu-101-2013_02_20-13_30_49.tar.lzo'
INFO: adding '/mnt/pve/nem/dump/vzdump-qemu-101-2013_02_20-13_30_49.tmp/qemu-server.conf' to archive ('qemu-server.conf')
INFO: adding '/var/lib/vz/images/101/vm-101-disk-1.qcow2' to archive ('vm-disk-ide0.qcow2')
INFO: adding '/var/lib/vz/images/101/vm-101-disk-2.qcow2' to archive ('vm-disk-ide1.qcow2')
INFO: Total bytes written: 32336382976 (110.53 MiB/s)
INFO: archive file size: 8.49GB
INFO: Finished Backup of VM 101 (00:05:11)
INFO: Backup job finished successfully
TASK OKthe problem now is that it takes 25minutes longer for "nothing".
of course, you could say make the hdd smaller and expand it if necessary, but in my opinion thats not really practically
the overall 600GiB will be filled with time and the problem with lost backup-time for empty space will shrink cause then its backuping real data, but there will be always some lost time that can multiply to hours (with more machines and the more space is assigned)
is this behaviour known or even wanted?
for the end a quick pveperf so you see that the server shouldn't be the root-cause
Code:
pveperf
CPU BOGOMIPS: 45598.56
REGEX/SECOND: 1076158
HD SIZE: 94.49 GB (/dev/mapper/pve-root)
BUFFERED READS: 559.72 MB/sec
AVERAGE SEEK TIME: 3.99 ms
FSYNCS/SECOND: 4390.28
DNS EXT: 50.07 ms
DNS INT: 3.16 msthanks in advance, keep up the great work