Skip to content

[Feature Request] Support changing the vsock CID on snapshot restore #3344

Open
@simonis

Description

@simonis

Feature Request

I'm aware of the vsock device limitations described in snapshot-support.md.

However there's no mentioning of how to support multiple clones of a snapshot with a configured vsock on the same host (they'll all share the same CID). For network interfaces, Network Connectivity for Clones describes pretty nicely how multiple clones can be run on the same host by using network namespaces. But to my knowledge, there's no network namespace support available for vsock sockets (I only found "vsock: support network namespace" which doesn't seem to have been finished yet).

I tried to configure a different vsock CID/path before restoring a snapshot, but in that case restoring fails with:

2022-12-30T20:46:38.507150111 [anonymous-instance:fc_api:ERROR:src/api_server/src/parsed_request.rs:190] Received Error. Status code: 400 Bad Request. Message: Loading a microVM snapshot not allowed after configuring boot-specific resources.

Describe the desired solution

The vsock man page mentions the following about "live migrations":

   Sockets are affected by live migration of virtual machines.
   Connected SOCK_STREAM sockets become disconnected when the
   virtual machine migrates to a new host.  Applications must
   reconnect when this happens.

   The local CID may change across live migration if the old CID is
   not available on the new host.  Bound sockets are automatically
   updated to the new CID.

I wonder if it wouldn't be possible to implement the vsock support in Firecracker such that the CID/socket path can be changed for a snapshot at restore time?

In addition to allowing multiple clones with configured vsockets, such a change would also make it possible to use the vsock device for obtaining a simple SysGenID (see #2546).

Please let me know if there's anything obvious that I'm missing?

Checks

  • Have you searched the Firecracker Issues database for similar requests?
  • Have you read all the existing relevant Firecracker documentation?
  • Have you read and understood Firecracker's core tenets?

Metadata

Metadata

Assignees

Labels

Priority: MediumIndicates than an issue or pull request should be resolved ahead of issues or pull requests labelledStatus: ParkedIndicates that an issues or pull request will be revisited laterType: EnhancementIndicates new feature requests

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions