When will OVF support disk reference paths and not embed disk data into mgiration file?

[Schorschi]

When moving VMs from RHEV, KVM, Hyper-V, and VMware, which many are doing today, OVF makes sense as a starting point, however, OVF is very ineffecient if the given VMs already have virtual disks in the correct location. For example, moving VMs from VMware to KVM, and from KVM to VMware, since KVM supports VMDK as does VMware, and both could and can access the same datastore/NFS mount point, the encode/decode of the virtual machine disks in OVF is not needed, just use a reference path to the VM disks, not the actual data. So the question is, When will OVF support disk reference paths and not embed disk data into mgiration file? Interesting feature no?

[admin]

The OVF specs states that VM disk are a reference in the reference section but for all common workloads it makes sense to copy the disk along with the OVF package and I'm guessing that you don't want to store the disk on a common webserver because the VM uses the disk to read and store data to. You will simply get too poor performance and non responding VMs. Each vendor have his or her own disk format but as far as I can see all specs on formats are open so it should not be a problem to convert between them. The disks we convert to when using ovftool or vi client is http://www.vmware.com/interfaces/vmdk.html#streamOptimized" which are optimized to copying around when moving the VMs and disks.

What you are suggesting is to make a common disk format inside the OVF spec and I don't think that will ever fly. Please remember that OVFs are not a runtime package but is a MSI-installer (or other install systems) like package for installing VMs and vApps. Another thing is that delta disk (supported by ovftool for import/export) will not work with this approach.

With all that said I will add your idea to a todo list of what we need to make better in the OVF spec.

eske

[Schorschi]

Common disk formats already exist, VHD and VMDK, so that is not the issue, the issue is disk encapsulation. Want the option to migrate VM, but not have to encode and decode the VM disks since they are already in the correct or common location. Others have tried this, in fact, I have tried tricking the OVF import application/tools from VMware to do this, but direct edit of the OVF files breaks the self validation method integrated into the OVF file format. So the logical next step is to get this concept integrated into the standard. Per my reasoning, theremore, there is no need for creating or establishing a common disk format since VHD and VMDK are sufficient for the migrations expected, so this feature would seem to be a very simple addition to OVF specification. The fact that a common datastore reference path feature does not already exist, is driven, by the fact that common disk formats would not exist, and yet they do, or if you will, not a common disk format but a format that is supported across multiple vendors.