Hi Guys,
Not sure if this issue is known or perhaps even unintentional. However, the basic issue is that when creating a VM you can attach multiple virtual hard disks (raw/qcow2/LV) but they can be from different storage targets. However, after a backup, if you attempt to restore it, you can only choose 1 single storage target for ALL attached disk images. This is an especially large problem if the drive types differ (in particular mixing qcow2 and LV).
This is an example case:
VM100 is KVM running FreeNAS. FreeNAS requires 2 drives to operate (one dedicated 4GB+ "system" drive and one or more "Data" drives specifically for storage).
Drive 1: 8GB QCow2 format on /var/lib/vz RAID1 for minimal footprint and high backup speed. FreeNAS only uses a small amount, but there's plenty of space for plugins/etc.
Drive 2: 100GB LVM attached to separate dedicated RAID5 storage to act as the shared data.
When backed up you get your tar.gz which contains the qemu conf file which maintains the "original" storage locations it came from.
However, when you then restore the tarball through either commandline or GUI, you only have the option of selecting 1 storage target.
So in the example case, on restore you'll either end up with 2 drive images on /var/lib/vz, or the 8GB qcow2 image will end up as an LV. I believe qmrestore will also assume RAW if it is restoring to a directory, even if the original drive was LV.
Are there plans to correct this? I can see how this could be a problem however, as the Restore dialog essentially isn't aware of how many drive images are contained in the tarball until AFTER it has begun extracting.
Either way it would be nice to have the functionality as it essentially means any restores of these types of VM have to be done by hand which is very painful. Taking the example case, I would have to untar the backup file to a temporary location, move the qcow2 image to the proper location, copy the qemu conf, DD the "Drive 2.raw" -> Volume Group, then run.
What would be great, is if the restore function pre-read the qemu conf file, then listed each drive image and allowed you to select a restore location for each. Qcow/VMDK would be limited to a directory store, RAW/LVM could restore to any.
Not sure if this issue is known or perhaps even unintentional. However, the basic issue is that when creating a VM you can attach multiple virtual hard disks (raw/qcow2/LV) but they can be from different storage targets. However, after a backup, if you attempt to restore it, you can only choose 1 single storage target for ALL attached disk images. This is an especially large problem if the drive types differ (in particular mixing qcow2 and LV).
This is an example case:
VM100 is KVM running FreeNAS. FreeNAS requires 2 drives to operate (one dedicated 4GB+ "system" drive and one or more "Data" drives specifically for storage).
Drive 1: 8GB QCow2 format on /var/lib/vz RAID1 for minimal footprint and high backup speed. FreeNAS only uses a small amount, but there's plenty of space for plugins/etc.
Drive 2: 100GB LVM attached to separate dedicated RAID5 storage to act as the shared data.
When backed up you get your tar.gz which contains the qemu conf file which maintains the "original" storage locations it came from.
However, when you then restore the tarball through either commandline or GUI, you only have the option of selecting 1 storage target.
So in the example case, on restore you'll either end up with 2 drive images on /var/lib/vz, or the 8GB qcow2 image will end up as an LV. I believe qmrestore will also assume RAW if it is restoring to a directory, even if the original drive was LV.
Are there plans to correct this? I can see how this could be a problem however, as the Restore dialog essentially isn't aware of how many drive images are contained in the tarball until AFTER it has begun extracting.
Either way it would be nice to have the functionality as it essentially means any restores of these types of VM have to be done by hand which is very painful. Taking the example case, I would have to untar the backup file to a temporary location, move the qcow2 image to the proper location, copy the qemu conf, DD the "Drive 2.raw" -> Volume Group, then run.
What would be great, is if the restore function pre-read the qemu conf file, then listed each drive image and allowed you to select a restore location for each. Qcow/VMDK would be limited to a directory store, RAW/LVM could restore to any.
