Skip to content

Add support for network block device (NBD)#690

Open
yibozhuang wants to merge 1 commit intoapple:mainfrom
yibozhuang:support-nbd
Open

Add support for network block device (NBD)#690
yibozhuang wants to merge 1 commit intoapple:mainfrom
yibozhuang:support-nbd

Conversation

@yibozhuang
Copy link
Copy Markdown
Contributor

@yibozhuang yibozhuang commented Apr 18, 2026

This change adds support for attaching network block device (NBD) to both LinuxContainer and LinuxPod.

For LinuxContainer, whether to use the underlying
VZNetworkBlockDeviceStorageDeviceAttachment is determined by the URL of the container Mount source.

For LinuxPod, adds additional API to support pod-level volumes that can be mounted into multiple containers. The PodVolume type provides enum to support multiple type of volume source. ContainerConfiguration for LinuxPod adds additional volumeMounts type which are container mounts where the source comes from a pod-level volume. This will allow the NBD to be attached to the pod at the VM level and then bind-mounted into a container.

For integration tests, added a lightweight NBD server implementation in swift that speaks the NBD protocol to ensure there is sufficient coverage for the changes introduced.

Apple Virtualization NBD support documentation:
https://developer.apple.com/documentation/virtualization/vznetworkblockdevicestoragedeviceattachment

@yibozhuang yibozhuang force-pushed the support-nbd branch 2 times, most recently from 5507fb0 to 351c727 Compare April 19, 2026 18:19
This change adds support for attaching network block device (NBD)
to both LinuxContainer and LinuxPod.

For LinuxContainer, whether to use the underlying
VZNetworkBlockDeviceStorageDeviceAttachment is determined by the
URL of the container Mount source.

For LinuxPod, adds additional API to support pod-level volumes
that can be mounted into multiple containers. The PodVolume
type provides enum to support multiple type of volume source.
ContainerConfiguration for LinuxPod adds additional volumeMounts
type which are container mounts where the source comes from a
pod-level volume. This will allow the NBD to be attached to
the pod at the VM level and then bind-mounted into a container.

For integration tests, added a lightweight NBD server
implementation in swift that speaks the NBD protocol to ensure
there is sufficient coverage for the changes introduced.
throw error
}
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have LinuxContainer tests?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/// forwarding and zombie reaping.
public var useInit: Bool = false
/// The container mounts that references pod-level attached volumes.
public var volumeMounts: [VolumeMount] = []
Copy link
Copy Markdown
Member

@dcantah dcantah Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not super happy with this in particular but I can't put my finger on it. This almost seems like a UX win really right? There's nothing they couldn't emulate by just asking for the same mount in every container in the pod?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we were to keep this I'd prefer sharedMounts or something.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dcantah How about this

  • remove the volumeMounts from ContainerConfiguration
  • Introduce a new Mount.sharedMount() constructor to indicate that this is a shared mount
  • Add a .shared RuntimeOptions to indicate that this is a shared mount between containers
  • PodContainer can do config.mounts.append(Mount.sharedMount(name: "shared-data", destination: "/data", options: ["ro"])) to add a shared mount to its configuration, no additional API surface needed

Does this work better?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants