[live-migration] Preserve host-side GCS logging across migration#2826
Open
rawahars wants to merge 2 commits into
Open
[live-migration] Preserve host-side GCS logging across migration#2826rawahars wants to merge 2 commits into
rawahars wants to merge 2 commits into
Conversation
By default vsockexec dials the host once, hands the socket to the child
as its stdio, and execs into it. If the host listener is absent when the
guest starts, or the connection later drops, the child's writes fail and
it exits. Because the child runs under PID 1 in the UVM, its death makes
PID 1 exit and the guest kernel panics, taking the VM down.
Add a new -r flag that keeps vsockexec running as a relay between the
child and the host instead of exec'ing into it:
- the child writes to a pipe (which never breaks), not to the socket;
- vsockexec keeps the host connection itself and forwards the pipe to it;
- it waits and retries if the host is not listening yet (late connect);
- it re-dials and resends if the connection drops (reconnect);
- the child's exit status is propagated, so PID 1 still sees the real
exit code and shutdown semantics are unchanged.
Without -r the behavior is byte-for-byte identical to before, so no
existing caller is affected. stdout and stderr sharing one port continue
to share a single host connection.
Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
Wire the reconnect mode (-r) added in the previous commit into the LCOW
live-migration path so live-migratable pods keep host-side GCS logging
instead of forgoing it.
Before, these pods dropped GCS log forwarding entirely: a plain
vsockexec would block on its outbound connect and stall guest init when
the host log listener was absent, so the wrapper and listener were
skipped. Reconnect mode removes that constraint:
- buildGCSCommand emits /bin/vsockexec -r for live-migratable
sandboxes, so the guest tolerates a missing listener and re-dials
LinuxLogVsockPort after the connection drops;
- StartWithMigrationOptions arms a fresh listener on the destination
before start, so the resumed guest can reconnect and resume
streaming;
- setupLoggingListener no longer early-returns and Resume no longer
force-closes logOutputDone.
Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
rawahars
force-pushed
the
vsockexec_relay
branch
from
13a58f5 to
96c7500
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Today a live-migratable LCOW pod gives up host-side GCS logging entirely, because the guest→host log connection is host-local state that migration doesn't carry: after a move there's no listener to reconnect to, and a guest that depended on the log socket would stall on boot. This PR makes that log path survive migration instead of disabling it.
It does so in two steps:
Make the forwarder resilient —
vsockexecgets an opt-in reconnect mode (-r) that runs as a relay between the child and the host: it tolerates the host listener being absent at boot, and re-dials and resumes if the connection drops. Default behavior is unchanged.Use it on the migration path — live-migratable pods now run
vsockexec -r, and the destination host arms a fresh log listener before resume, so the migrated guest simply reconnects and keeps streaming GCS logs.Net result: GCS logs keep flowing before, during, and after a live migration, with no change for non-migratable pods.