On 14.10.25 19:33, Peter Xu wrote:
On Fri, Oct 10, 2025 at 08:39:54PM +0300, Vladimir Sementsov-Ogievskiy wrote:
To migrate virtio-net TAP device backend (including open fds) locally,
user should simply set migration parameter
backend-transfer = ["virtio-net-tap"]
Why not simple boolean? To simplify migration to further versions,
when more devices will support backend-transfer migration.
Alternatively, we may add per-device option to disable backend-transfer
migration, but still:
1. It's more comfortable to set same capabilities/parameters on both
source and target QEMU, than care about each device.
But it loses per-device control, right? Say, we can have two devices, and
the admin can decide if only one of the devices will enable this feature.
Right. But, in short:
1. I'm not sure, that such granularity is necessary.
2. It may implemented later, on top of the feature.
2. To not break the design, that machine-type + device options +
migration capabilities and parameters are fully define the resulting
migration stream. We'll break this if add in future more
backend-transfer support in devices under same backend-transfer=true
parameter.
Could you elaborate?
I thought last time we discussed, we planned to have both the global knob
and a per-device flag, then the feature is enabled only if both flags are
set.
Right, here in v3:
https://lists.nongnu.org/archive/html/qemu-devel/2025-09/msg01644.html
Still at this point, I also needed local-incoming=true target option, so I
considered all the parameters like "I can't make feature without extra
per-device options, so here they are".
A day later, after motivating comment from Markus (accidentally in v2),
I found and suggested the way:
https://lists.nongnu.org/archive/html/qemu-devel/2025-09/msg01960.html
And further versions v4-v7 were the realization of the idea. Still, main
benefit is possibility to get rid of per-device local-incoming=true
options for target, not about a kind of per-device "capability" flag we
discuss now.
A, and here I said [1]:
1. global fds-passing migration capability, to enable/disable the whole feature
2. per-device fds-passing option, on by default for all supporting devices, to
be
able to disable backing migration for some devices. (we discussed it here:
https://lore.kernel.org/all/[email protected]/ ).
Still, normally these options are always on by default.
And more over, I can postpone their implementation to separate series, to
reduce discussion field, and to check that everything may work without
additional user input.
And then, went this way, postponing realization of per-device options..
And then, developing similar migration for vhost-user-blk, found
that I can't use on boolean capability for such features, the reason
in commit message, which we discuss now.
Than, current design came in v5 (v4 was skipped).. And I even got an
approval from Fabiano :)
https://lists.nongnu.org/archive/html/qemu-devel/2025-09/msg03999.html
If these parameters are all set the same on src/dst, would it also not
break the design when new devices start to support it (and the new device
will need to introduce its own per-device flags)?
Yes, right.
I missed, that, "postponing (probably forever)" per-device options
realization, I started to implement another way to solve the same
problem (switching from one boolean capability to a backend-transfer
list).
In other words, if at some point implement per-device options, that will
partly intersect by functionality with current complex migration
parameter..
-
But still, I think, that parameter backend-transfer = [list of targets]
is better than per-device option. With per-device options we'll have to
care about them forever. I can't imagine a way to make them TRUE by
default.
Using machine type, to set option to TRUE by default in new MT, and to
false in all previous ones doesn't make real sense: we never migrate on
another MT, but we do can migrate from QEMU without support for
virtio-net backend transfer to the QEMU with such support. And on target
QEMU we'll want to enable virtio-net backend-transfer for further
migrations..
So, I think, modifying machine types is wrong idea here. So, we have to
keep new options FALSE by default, and management tool have to care to
set them appropriately.
-
Let's look from the POV of management tool.
With complex parameter (list of backend-transfer targets, suggested with
this series), what should we do?
1. With introspection, get backend-transfer targets supported by source
and target QEMUs
2. Get and intersection, assume X
3. Set same backend-transfer=X on source and target
4. Start a migration
But with per-device parameters it becomes a lot more complicated and
error prone
1. Somehow understand (how?), which devices support backend-transfer on
source and target
2. Get an intersection
3. Set all the backend-transfer options on both vms correspondingly,
doing personal qom-set for each device
4. Start a migration
-
In short:
1. per device - is too high granularity, making management more complex
2. per feature - is what we need. And it's a normal use for migration
capabilities: we implement a new migration feature, and add new
capability. The only new bit with this series is that "we are going to"
implement similar capabilities later, and seems good to organize them
all into a list, rather than make separate booleans.
The commit only brings the interface, the realization will come in later
commit. That's why we add a temporary not-implemented error in
migrate_params_check().
[..]
+bool migrate_virtio_net_tap(void)
+{
+ MigrationState *s = migrate_get_current();
+ BackendTransferList *el = s->parameters.backend_transfer;
+
+ for ( ; el; el = el->next) {
+ if (el->value == BACKEND_TRANSFER_VIRTIO_NET_TAP) {
So this is also something I want to avoid. The hope is we don't
necessarily need to invent new device names into qapi/migration.json.
OTOH, we can export a helper in migration/misc.h so that devices can query
wehther the global feature is enabled or not, using that to AND the
per-device flag.
Understand. But I can't imagine how to keep management simple with per-device
options..
-
What do you think?
--
Best regards,
Vladimir
