[Engine-devel] oVirt upstream meeting : VM Version

[Livnat Peer]

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