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