[Engine-devel] oVirt upstream meeting : VM Version

[Ayal Baron]

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