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@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 -- /d "The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963) _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
