Re: [Engine-devel] oVirt upstream meeting : VM Version

----- Original Message ----- > On 03/02/12 17:00, Itamar Heim wrote: >> On 02/02/2012 12:15 PM, Ayal Baron wrote: >>> >>> >>> ----- Original Message ----- >>>> On 02/02/2012 08:46 AM, Itamar Heim wrote: >>>>> On 02/02/2012 02:56 AM, Eli Mesika wrote: >>>>>> Hi >>>>>> >>>>>> We had discussed today the Stable Device Addresses feature >>>>>> One of the questions arose from the meeting (and actually >>>>>> defined >>>>>> as >>>>>> an open issue in the feature wiki) is: >>>>>> What happens to a 3.1 VM running on 3.1 Cluster when it is >>>>>> moved >>>>>> to a >>>>>> 3.0 cluster. >>>>>> We encountered that VM may lose some configuration data but >>>>>> also >>>>>> may >>>>>> be corrupted. >>>>>> From that point we got to the conclusion that we have somehow >>>>>> to >>>>>> maintain a VM Version that will allow us to >>>> >>>> What do you mean by VM version? >>>> Is that the guest hardware abstraction version (which is the kvm >>>> hypervisor release + the '-M' flag for compatibility)? >>>> >>>> I think its the above + the meta data /devices you keep for it. >>> >>> Correct. >>> There are several issues here: >>> 1. you loose the stable device addresses (no point in keeping the >>> data >>> in the db as the next time the VM is run the devices can get >>> different >>> addresses) >>> 2. If you move the VM to an older cluster where the hosts don't >>> support the VM's compatibility mode (-M) then the VM would be >>> started >>> with different virtual hardware which might cause problems >>> 3. Once we support s4 then running the VM again with different >>> hardware might be even more problematic than just running it from >>> shutdown (e.g. once we have a balloon device with memory assigned >>> to >>> it which suddenly disappears, what would happen to the VM?) >>> 4. Same applies for migrate to file, but this can be dealt with by >>> not >>> allowing to move a VM between incompatible clusters in case it has >>> a >>> migrate to file state (or delete the file). >> >> same would apply for a direct lun on the vm, custom properties >> defined >> to it, multiple monitors for spice for linux guests, etc. >> I think we should add validations for things we know are not >> supported, >> but otherwise allow it. >> > > IIUC you suggest to use features granularity for setting on which > cluster (version) the VM can be started. Note that *all* VMs that > were > started on a 3.1 cluster will loose functionality when running on 3.0 > cluster (stable device addressed will be lost). > > I would go with a simple approach here. > Derive the VM version from the cluster version, VM can be executed on > all hosts in the cluster without loosing any functionality, when we > change the VM cluster we practically change the VM version. > I would require a force flag to execute the VM on a lower cluster > version. Isn't the VM version derived from the version of the cluster on which it was last edited? For example: you've created a VM on a cluster v3.0. When it is running on a v3.2 cluster, is there any reason to change its version? When it is edited, then perhaps yes - because it may have changed/added properties/features that are only applicable to v3.2. But until then - let it stay in the same version as it was created. (btw, how does this map, if at all, to the '-m' qemu command line switch?) Y.

> > What we are missing today is saving this version as part of the OVF > to > support version compatibility functionality during import/export VM > flows and snapshots of VM configuration. > >>> A side note - I'm not sure if exporting a VM also exports the >>> state >>> file after migrate to file? if not then probably it should... >>> >>> I'm sure there are additional scenarios we're not thinking of. >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >