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

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Yaniv Kaul" <ykaul(a)redhat.com&gt; Cc: dlaor(a)redhat.com, engine-devel(a)ovirt.org Sent: Sunday, February 5, 2012 10:46:56 AM Subject: Re: [Engine-devel] oVirt upstream meeting : VM Version On 05/02/12 10:45, Livnat Peer wrote: > 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 >

About the -m switch the engine derives it from the cluster level. >>> >>> 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 _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel