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