On Wed, Jan 18, 2012 at 4:32 PM, Eric Blake wrote: > On 01/18/2012 03:18 AM, Gianluca Cecchi wrote: >> symbol "--->" corresponds to live migration >> >> 6.1 --> 6.1 ok >> 6.1 --> 6.2 ok >> 6.2 --> 6.2 ok > > Yes, those are all supported migration patterns. > >> >> but >> >> 6.2 --> 6.1 ko > > This is expected - there is no guarantee of downgrade compatibility, > only upgrade compatibility. The qemu on 6.2 has different machine > models for 6.1 vs. 6.2 hosting, so that it can continue to run a guest > migrated in from a 6.1 host. But if a guest is started from scratch on > 6.2 rather than migrated in from 6.1, then chances are quite high that > the state of the machine will be using 6.2 features that are not > understood by 6.1, and thus you can't migrate to a downgraded qemu. > > --
yes, the general concept is ok. My concern was about guests that were born on 6.1 and after being migrated to 6.2 were not able to come back again to 6.1 (in live migration way) Possibly to cover a scenario where you migrate one host, then collapse there again some machines, but due to problems (performance, hangs or so on..) you are forced to come back. You cannot do this live but giving downtime inside all the migrated guests. And with 3 nodes as it is my case you have a little more flexibility because you pass from a stage where you still have two 6.1 hosts. In case of 2-nodes clusters you have to migrate all of the guests on the upgraded host and then if something goes wrong you have to give downtime for all the vms. Probably a sort of compatible switch for pre-6.2 guests would have been good. And note that if I shut down the guest on 6.2 and then power it on again on 6.1 it boots without problem. The guests' xml didn't change: it is still dated April 2011. The limiting point is concerning live migration where there is this hostuuid thing in 6.2 and not in 6.1... Gianluca _______________________________________________ virt mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/virt
