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

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