----- 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). 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. > > >> block moving VM if it's version is not fully supported compatible > >> with > >> the target Cluster. > >> One idea for getting the VM version is the OVF which actually > >> holds > >> inside its header OvfVersion. > >> The question is , is the OVF good enough for all our needs or > >> should > >> we persist that else (for example in DB) > >> Also, any other issues/difficulties we may encounter implementing > >> and > >> storing VM version. > >> > >> Keep in mind that this is a new feature that impacts the Stable > >> Device > >> Addresses feature but may be useful/relevant > >> for other features as well. > > > > Can you give some examples which will cause an issue moving a VM > > from a > > 3.1 cluster to a 3.0 one? > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
