On 20.08.25 05:33, Jason Wang wrote:
On Tue, Aug 19, 2025 at 4:41 PM Vladimir Sementsov-Ogievskiy
<vsement...@yandex-team.ru> wrote:
On 19.08.25 05:45, Jason Wang wrote:
On Mon, Aug 18, 2025 at 10:06 PM Vladimir Sementsov-Ogievskiy
<vsement...@yandex-team.ru> wrote:
Hi all!
As preparation for further development of TAP live local migration
(passing open fds through unix socket),
I'm not sure I understand this, but I think it has been supported now,
or anything I miss?
Hmm, may be I missing something, but where?
I see no code which put TAP fd into migration channel. Nothing about migration
in tap.c at all.
So, normally, to make local migration with TAP device, you have to create a new
TAP for new QEMU
process.
I want to add a migration state, which will include needed part of TAPState,
including fd,
to continue using same TAP device in target process, avoiding also any
initialization steps
on that fd.
Ok, I see. But the question is that TAP is not something that is
visible to guests. Doing that may be a suboptimal as we need to deal
with the migration compatibility.
Can we simply teach the management layer to use the same TAP fd
instead assuming it's a local migration.
Theoretically yes: we can pass same fds to the target. We'll still need some
new option, to avoid
some operations with TAP on initialization (as when we initialize it on target,
source is still running,
and TAP should work on source), but that's possible.
Still, at least in our case, making an additional migration state looks more
straightforward.
1. Management layer doesn't store these fds. And its not simple to store them
in our architecture,
as management layer just doesn't live as long as QEMU, it's being restarted
more often.
2. So, we'll need to add interfaces to get all these fds from QEMU, and than
pass them to the target
QEMU.
So, it's a lot simpler for QEMU to care about these fds. QEMU owns them, why
not to pass them through
migration stream?
Also, that's not a precedent of passing fds (which are not visible to the
guest) through migration
channel, see docs/devel/migration/CPR.rst.
(Hmm, I missed that Steve recently resent his "[RFC V2 0/8] Live update: tap and
vhost", which
transfers TAP fds through CPR state.. I still think, using one migration
channel is quite
possible and more convenient. But that's a topic to discuss on corresponding
series, and this
one is just a refactoring, which just make the code more readable)
--
Best regards,
Vladimir
--
Best regards,
Vladimir
