Re: [pve-devel] [PATCH qemu-server v3 stable-bookworm 8/8] migration: preserve host_mtu for virtio-net devices

[Fiona Ebner <f.ebner@proxmox.com>]

Am 05.09.25 um 11:09 AM schrieb Thomas Lamprecht:
> Am 05.09.25 um 10:54 schrieb Fiona Ebner:
>> Am 04.09.25 um 8:11 PM schrieb Thomas Lamprecht:
>>> Am 04.09.25 um 14:42 schrieb Fiona Ebner:
>>>> The virtual hardware is generated differently (at least for i440fx
>>>> machines) when host_mtu is set or not set on the netdev command line
>>>> [0]. When the MTU is the same value as the default 1500, Proxmox VE
>>>> did not add a host_mtu parameter. This is problematic for migration
>>>> where host_mtu is present on one end of the migration, but not on the
>>>> other [1]. Moreover, the effective setting in the guest (state) will
>>>> still be the host_mtu from the source side, even if a different value
>>>> is used for host_mtu on the target instance's commandline. This will
>>>> not lead to an error loading the migration stream in QEMU, but having
>>>> a larger host_mtu than the bridge MTU is still problematic for certain
>>>> network traffic like
>>>>> iperf3 -c 10.10.10.11 -u -l 2k
>>>> when host_mtu=9000 and bridge MTU=1500.
>>>>
>>>> Pass the values from the source to the target during migration to be
>>>> able to preserve them.
>>>
>>> Which breaks migration from new to old, which can be fine, but seems
>>> avoidable given that we got a tunnel that we can query stuff over.
>>
>> How can we query? The old tunnel only supports very specific commands
>> like 'quit' and 'resume $vmid'. Note that remote migration using the new
>> tunnel version is not broken - an old node will just ignore the
>> additional parameter in the passed-along JSON.
> 
> The absence of a command gives you also information.

Okay, so you mean adding a new command and using that to detect that the
node is recent enough? What should that command be? The capabilities one
you suggest below?

>>
>> We could do something like
>>
>> ssh ... qm start 0 --nets-host-mtu
>>
>> and match for "Unknown option: nets-host-mtu" for detection.
> 
> Yeah, that's exactly what I wrote later in my reply.

I thought you meant matching the error for the actual command. My
suggestion is using a dummy command for early detection and guard using
the new option for the actual command based on that.

>> Alternatively, we could bump the pve-manager version and guard adding
>> the option via the pmxcfs 'version-info' node kv. That mechanism wasn't
>> super reliable in the past though.
> 
> FWIW, we now re-broadcast that periodically and IIRC even on pmxcfs
> start up though.

Yes, and if we really can't get the info we can err on the side of
"assume it's recent enough".

>>> Maybe we could at least catch the "Unknown option: nets-host-mtu"
>>> error explicitly and add some context that the target likely just
>>> needs to be updated to make the migration work.
>>
>> If we don't want to go for either of the above or if there isn't an
>> other way to query, I'll go for that?
> 
> Would be fine for me, it's the simplest thing to do for now.
> 
> Adding some more fleshed out general approach for such things might
> be nice to have available for the future. That could be some
> versioning or a more structured capabilities query, that is split
> into required ones (which block the migration) and hints, that are
> for best-effort stuff, probably also including some basic version
> info like qemu-server, as that often is needed to know if a
> capability is required or not, like here, when migrating to a
> another 8.x node it won't matter, but for a 9.x target node we
> should enforce an e.g. nets-host-mtu to be available.

Sounds sensible.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel