[pve-devel] [RFC qemu-server stable-4] add workaround for pve 4.4 to 5.0 live migration

[Thomas Lamprecht]

Hi,

On 07/11/2017 10:06 PM, Stefan Priebe - Profihost AG wrote:
> Hello,
>
> Am 11.07.2017 um 16:40 schrieb Thomas Lamprecht:
>> commit 85909c04c49879f5fffa366fc3233eee2b157e97 switched from cirrus
>> to vga for non windows OSs.
>>
>> This adds an artificial blocker on live migrations from PVE 4.X to
>> PVE 5.0.
>> Address it in PVE 4.4 by explicitly setting cirrus in the config if
>> it would be used, so that a PVE 5.0 starts up the correct hardware in
>> the case of a migration. Do it only on running VMs with online
>> migration enabled.
>> Do not clean it up, as this would then make live migration fail again
>> until the VM had a real poweroff and power on cycle even from PVE 5.0
>> to PVE 5.0.
>> While not the nicest way it is a short and valid solution and doesn't
>> adds hackery in new code. We may also touch the config only on the
>> source site until migration phase 3 completes.
> this is a pretty hacky approach i don't like.

yes, I know and not proud of it :)
We will probably opt for the second approach mentioned in the patchs 
comment section.
The one where I check the qemu machine version.

> What about doing something different which is a more general approach an
> can be used for pve 6, 7 as well:
> 1.) write at each vm start pve-manager version to a field in the
>   vm conf f.e. pveversion: 4.4
>
> 2.) while doing an online migration check if there are special things to
> consider f. e. default vga = cirrus if !defined($conf->{vga} &&
> $conf->{pveversion} < 5;

Hmm, better approach for sure, but then you would need to rewrite the 
version at some point
and that cannot be after migration, as there the VM still runs with the 
"old" machines devices.

One a discussion here we came to another approach, which would be even 
more general
and easier to maintain, at least for the VM case.

Extract all devices and their current settings from the VM once locked
for migration and pass this to the target side.
There use the actual current device info to start the VM listening for 
an incoming migration.
This would prevent such things once and for all and had also hot 
plugging various devices in mind,
even if "manual" hot-plugged.

Thanks for your input! The config version is a nice idea, but for this 
specific case too much a
hassle at the moment, IMO, as it needs to touch both pve 4 and 5.

cheers,
Thomas

> Greets,
> Stefan
>
>    $
>> Signed-off-by: Thomas Lamprecht <t.lamprecht at proxmox.com>
>> ---
>>
>> Another approach would be to check the machine type on the target side and if
>> older than *-2.9 use cirrus, if not explicitly set already.
>> But this would then add code on PVE 5.0 which we would need to maintain for a
>> bit of time, so I'm not sure if that would be the nicer solution...
>>   
>>   PVE/QemuMigrate.pm | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
>> index e6f147e..6cfca0b 100644
>> --- a/PVE/QemuMigrate.pm
>> +++ b/PVE/QemuMigrate.pm
>> @@ -429,6 +429,14 @@ sub phase1 {
>>   
>>       my $conf = $self->{vmconf};
>>   
>> +    # HACK: avoid migration failure to 5.0 as the VGA default has changed
>> +    if (!defined($conf->{vga}) && $self->{running} && $self->{opts}->{online}) {
>> +	my $winversion = PVE::QemuServer::windows_version($conf->{ostype});
>> +	if ($winversion < 6) {
>> +	    $conf->{vga} = 'cirrus';
>> +	}
>> +    }
>> +
>>       # set migrate lock in config file
>>       $conf->{lock} = 'migrate';
>>       PVE::QemuConfig->write_config($vmid, $conf);
>>
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel