----- 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(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel