[Engine-devel] oVirt upstream meeting : VM Version

[Livnat Peer]

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 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
>>