[Engine-devel] oVirt upstream meeting : VM Version

[Yaniv Kaul]

----- Original Message -----
> On 03/02/12 17:00, Itamar Heim wrote:
> > On 02/02/2012 12:15 PM, Ayal Baron wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> On 02/02/2012 08:46 AM, Itamar Heim wrote:
> >>>> On 02/02/2012 02:56 AM, Eli Mesika wrote:
> >>>>> Hi
> >>>>>
> >>>>> We had discussed today the Stable Device Addresses feature
> >>>>> One of the questions arose from the meeting (and actually
> >>>>> defined
> >>>>> as
> >>>>> an open issue in the feature wiki) is:
> >>>>> What happens to a 3.1 VM running on 3.1 Cluster when it is
> >>>>> moved
> >>>>> to a
> >>>>> 3.0 cluster.
> >>>>> We encountered that VM may lose some configuration data but
> >>>>> also
> >>>>> may
> >>>>> be corrupted.
> >>>>>  From that point we got to the conclusion that we have somehow
> >>>>>  to
> >>>>> maintain a VM Version that will allow us to
> >>>
> >>> What do you mean by VM version?
> >>> Is that the guest hardware abstraction version (which is the kvm
> >>> hypervisor release + the '-M' flag for compatibility)?
> >>>
> >>> I think its the above + the meta data /devices you keep for it.
> >>
> >> Correct.
> >> There are several issues here:
> >> 1. you loose the stable device addresses (no point in keeping the
> >> data
> >> in the db as the next time the VM is run the devices can get
> >> different
> >> addresses)
> >> 2. If you move the VM to an older cluster where the hosts don't
> >> support the VM's compatibility mode (-M) then the VM would be
> >> started
> >> with different virtual hardware which might cause problems
> >> 3. Once we support s4 then running the VM again with different
> >> hardware might be even more problematic than just running it from
> >> shutdown (e.g. once we have a balloon device with memory assigned
> >> to
> >> it which suddenly disappears, what would happen to the VM?)
> >> 4. Same applies for migrate to file, but this can be dealt with by
> >> not
> >> allowing to move a VM between incompatible clusters in case it has
> >> a
> >> migrate to file state (or delete the file).
> > 
> > same would apply for a direct lun on the vm, custom properties
> > defined
> > to it, multiple monitors for spice for linux guests, etc.
> > I think we should add validations for things we know are not
> > supported,
> > but otherwise allow it.
> > 
> 
> IIUC you suggest to use features granularity for setting on which
> cluster (version) the VM can be started. Note that *all* VMs that
> were
> started on a 3.1 cluster will loose functionality when running on 3.0
> cluster (stable device addressed will be lost).
> 
> I would go with a simple approach here.
> Derive the VM version from the cluster version, VM can be executed on
> all hosts in the cluster without loosing any functionality, when we
> change the VM cluster we practically change the VM version.
> I would require a force flag to execute the VM on a lower cluster
> version.

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.

> 
> What we are missing today is saving this version as part of the OVF
> to
> support version compatibility functionality during import/export VM
> flows and snapshots of VM configuration.
> 
> >> A side note - I'm not sure if exporting a VM also exports the
> >> state
> >> file after migrate to file? if not then probably it should...
> >>
> >> I'm sure there are additional scenarios we're not thinking of.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>