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

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

> > 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >