[Engine-devel] oVirt upstream meeting : VM Version

[Doron Fediuck]

On 07/02/12 17:43, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> On 02/05/2012 02:57 PM, Miki Kenneth wrote:
>>> ...
>>>
>>>>>>> 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
>>>>>>
>>>> However, I do agree with Yaniv that changing the VM version
>>>> "under
>>>> the hood" is a bit problematic. Version is a parameter associated
>>>> with create/update operation, and less with Run command.
>>
>> It's not under the hood, user effectively chose to change it when she
>> changed the cluster level.
>>
>> Going forward, we could check the version before running the VM and
>> then warning the user (so that the change would take effect per VM
>> and not per cluster) but that would be annoying and to mitigate
>> that, we would need to add a checkbox when changing the cluster
>> level "Automatically upgrade VMs" or something (to keep current
>> simple behaviour).
> 
> Another thing that would require VM version is unicode support in the ovf.
> 
Why isn't unicode an OVF version issue?

>>
>>>
>>> but the engine currently has no logic to detect the need to
>>> increase
>>> the
>>> emulated machine to support feature X.
>>> the engine currently does not save this parameter at VM level.
>>> it will also need to compare it to the list of supported emulated
>>> machines at the cluster, and prevent running the VM if there isn't
>>> a
>>> match.
>>> it also increases the matrix of possible emulated machines being
>>> run
>>> on
>>> different versions of hypervisor to N*cluster_levels, instead of
>>> just
>>> the number of cluster levels.
>>> plus, if a cluster is increased to a new version of hosts which
>>> doesn't
>>> support an older emulated machine level - user will need to upgrade
>>> all
>>> VMs one by one?
>>> (or will engine block upgrading cluster level if the new cluster
>>> level
>>> doesn't have an emulated machine in use by one of the virtual
>>> machines)
>>> it also means engine needs to handle validation logic for this
>>> field
>>> when exporting/importing (point of this discussion), as well as
>>> just
>>> moving a VM between clusters.
>>>
>>> so before introducing all this logic - were issues observed where
>>> changing the cluster level (i.e., -M at host level) resulted in
>>> problematic changes at guest level worth all of these?
>>> _______________________________________________
>>> 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


-- 

/d

"The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963)