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

On 05/02/12 10:34, Yaniv Kaul wrote: > ----- 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. > Currently we do not persist the VM version at all, it is derived from the cluster version the VM belongs to (that's why I suggested to save it as part of the OVF so we can be aware of the VM version when exporting/importing a VM etc.). The VM does not have to be edited to be influenced by the cluster version. For example if you start a VM on 3.1 cluster you get the stable device address feature with no manual editing. Livnat

>> >> 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 >> _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel