[Engine-devel] oVirt upstream meeting : VM Version

[Itamar Heim]

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.

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