Hi, I just finished installing and configure Proxmox 2.1 (by the way many thanks for your wonderful work) on a cluster of 4 Fujitsu blades. Cluster is UP, all 4 nodes seems OK:
To test everything I created a first KVM virtual machine, put it under HA, and having it running inside one of the blades. Everything seemed to work fine, but I got problems when I did a backup. I'm doing them running vzdump to saving VM images on a dedicated /backup directory. Because its filesystem is made inside a shared logical volume extracted from an SAN, I'm not using the Web console for the backups, instead I'm going to make them using a cron script on each blade to mount the filesystem, do the dump, and unmount it, so it would accessible from next blade. I need this also because I have to access to the same filesystem from another machine outside the cluster to copy the VM images over tapes. Because I want to be sure that all service are stopped when I did the backup, and the services are always unavailable during night, I just did the backup this using vzdump -mode stop. Because now I have just a single VM I manually launched the script (using screen to detach the console). The image was generated fine, but just after the VM was stopped I saw it migrated to another blade, and when the image generation was completed it was not restarted. The following is the command output I saved:
The problem seems that the VM was migrated after it was stopped and so not restarted on the blade running vzdump. But I do not understand why, I avoided any operation after launching the script. When I tried to restart the VM on the blade were it migrated (with qm start 101) I got the same error. And then it also migrated to another blade. I managed to restart it (going to the other blade it was) after removing the lock with qm unlock.
I still do not understand why the VM is migrated when it is stopped by vzdump, but if this is the correct behaviour it seems quite strange to me, and it undermines my backup strategy. I suspect I did not use the right way to launch vzdump but I could not find any hint on its manpage.
So there is a canonical way to make a dump for an HA VM from a blade, and make sure that the VM will stay on it?
Regards
Simone
Code:
root@lama9:~# pvecm nodes
Node Sts Inc Joined Name
1 M 40 2012-10-20 11:19:27 lama1
2 M 40 2012-10-20 11:19:27 lama2
3 M 28 2012-10-20 11:19:27 lama9
4 M 40 2012-10-20 11:19:27 lama10
To test everything I created a first KVM virtual machine, put it under HA, and having it running inside one of the blades. Everything seemed to work fine, but I got problems when I did a backup. I'm doing them running vzdump to saving VM images on a dedicated /backup directory. Because its filesystem is made inside a shared logical volume extracted from an SAN, I'm not using the Web console for the backups, instead I'm going to make them using a cron script on each blade to mount the filesystem, do the dump, and unmount it, so it would accessible from next blade. I need this also because I have to access to the same filesystem from another machine outside the cluster to copy the VM images over tapes. Because I want to be sure that all service are stopped when I did the backup, and the services are always unavailable during night, I just did the backup this using vzdump -mode stop. Because now I have just a single VM I manually launched the script (using screen to detach the console). The image was generated fine, but just after the VM was stopped I saw it migrated to another blade, and when the image generation was completed it was not restarted. The following is the command output I saved:
Code:
INFO: starting new backup job: vzdump 101 --dumpdir /backup --mode stop --maxfiles 1
INFO: Starting Backup of VM 101 (qemu)
INFO: status = running
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: stopping vm
INFO: creating archive '/backup/vzdump-qemu-101-2012_10_20-16_36_25.tar'
INFO: adding '/backup/vzdump-qemu-101-2012_10_20-16_36_25.tmp/qemu-server.conf' to archive ('qemu-server.conf')
INFO: adding '/dev/fast/vm-101-disk-1' to archive ('vm-disk-virtio0.raw')
INFO: Total bytes written: 450979957248 (85.67 MiB/s)
INFO: archive file size: 420.01GB
INFO: no such VM ('101') command 'qm unlock 101' failed: exit code 2
INFO: restarting vm
INFO: command 'clusvcadm -e pvevm:101 -m lama9' failed: exit code 255
INFO: Executing HA start for VM 101
INFO: Member lama9 trying to enable pvevm:101...Failure command 'qm start 101 --skiplock' failed: exit code 255
INFO: Finished Backup of VM 101 (01:24:30)
INFO: Backup job finished successfully
The problem seems that the VM was migrated after it was stopped and so not restarted on the blade running vzdump. But I do not understand why, I avoided any operation after launching the script. When I tried to restart the VM on the blade were it migrated (with qm start 101) I got the same error. And then it also migrated to another blade. I managed to restart it (going to the other blade it was) after removing the lock with qm unlock.
I still do not understand why the VM is migrated when it is stopped by vzdump, but if this is the correct behaviour it seems quite strange to me, and it undermines my backup strategy. I suspect I did not use the right way to launch vzdump but I could not find any hint on its manpage.
So there is a canonical way to make a dump for an HA VM from a blade, and make sure that the VM will stay on it?
Regards
Simone
Last edited: