[Engine-devel] oVirt upstream meeting : VM Version

[Miki Kenneth]

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: dlaor at redhat.com, engine-devel at ovirt.org
> Sent: Sunday, February 5, 2012 10:46:56 AM
> Subject: Re: [Engine-devel] oVirt upstream meeting : VM Version
> 
> On 05/02/12 10:45, Livnat Peer wrote:
> > On 05/02/12 10:34, Yaniv Kaul wrote:
> >> ----- 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.
> >>
> > 
> > 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.
> 
> About the -m switch the engine derives it from the cluster level.
> 
> >>>
> >>> 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
> >>>
> > 
> > _______________________________________________
> > 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
>