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