LinuxPod post-create addContainer fails with "hotplug not supported" on 0.33.4; is there a public HotplugProvider extension to enable?

[MarlonJD]

Summary

I'm testing LinuxPod post-create addContainer on apple/containerization
0.33.4 after PR #740 added hotplug interfaces:

#740

The API surface exposes LinuxPod.Configuration.extensions,
VMConfiguration.extensions, VZInstanceExtension, and
VZVirtualMachineInstance.hotplugProvider, but I cannot find a public
extension/provider implementation to install. A live-pod post-create
addContainer attempt fails with:

unsupported: "hotplug not supported"

Environment

• Package: apple/containerization
• Version: 0.33.4
• Checkout commit: 9275f365dd555c8f072e7d250d809f5eb7bdd746
• macOS: 26.5.1
• Host architecture: arm64
• VM init image: ghcr.io/apple/containerization/vminit:0.33.4

What I tried

1. Create a LinuxPod with VZVirtualMachineManager.
2. Add/register an initial container before pod.create().
3. Start the initial container successfully.
4. Reuse the same live pod object.
5. Attempt pod.addContainer(...) after pod.create() using an ext4 block
   rootfs mount.

The attempted post-create rootfs is a block mount:

rootfsMountType=block
rootfsMountFormat=ext4
rootfsMountIsBlock=true

Runtime introspection around VM creation shows:

vmConfigExtensionCount=0
vmConfigExtensionTypes=[]
hotplugProviderInstalled=false
hotplugProviderStatus=missing

Source inspection suggests VZVirtualMachineInstance.hotplug(_:, id:) throws
ContainerizationError(.unsupported, message: "hotplug not supported") when
hotplugProvider is nil.

Question

Is there a public VZInstanceExtension / HotplugProvider implementation or
configuration step that consumers should append to
LinuxPod.Configuration.extensions to enable block-device and virtiofs hotplug
for post-create addContainer?

If the provider is not public yet, should LinuxPod.addContainer post-create be
considered unsupported for public 0.33.4 consumers, despite the public API
surface?

Expected behavior

Either:

• a documented public extension/provider can be added to LinuxPod.Configuration
  so post-create addContainer can hotplug an ext4 block rootfs into a running
  VZ-backed pod; or
• the public API/docs clearly state that post-create LinuxPod.addContainer
  requires a provider implementation that is not currently included by default.

Actual behavior

pod.addContainer(...) after pod.create() fails with:

unsupported: "hotplug not supported"

No provider appears to be installed by the default VZVirtualMachineManager
path, and I could not find a public provider/extension implementation in the
0.33.4 source checkout.

Follow-up: custom provider feasibility probe

I ran a second local probe to separate no provider installed by default from
can a consumer install a provider and receive the post-create hotplug request?

Result: a consumer-installed VZInstanceExtension / HotplugProvider can be
installed and LinuxPod.addContainer(...) after pod.create() does reach that
provider. However, I still could not complete a real LinuxPod container hotplug
for an ext4/block rootfs using only public APIs.

Summary:

containerizationVersion=0.33.4
containerizationRevision=9275f365dd555c8f072e7d250d809f5eb7bdd746
customExtensionInstalled=true
hotplugProviderInstalled=true
providerHotplugCalled=true
publicUSBMassStorageAttachDetachWorks=true
postCreateAddContainerSucceeded=false
secondContainerStarted=false
realHotplugSucceeded=false
blocker=unsupportedRootfsBlockHotplug

I intentionally did not return a fake AttachedFilesystem or guess a /dev/...
path. I only counted hotplug as successful if the second container actually
started, which it did not.

Updated question:

Is there an intended public mechanism for a consumer-provided HotplugProvider
to attach an ext4/block rootfs image and return a LinuxPod-compatible
AttachedFilesystem source?

More specifically:

1. Is block/ext4 rootfs hotplug expected to be supported by the public VZ
   backend?
2. If yes, what public API should a provider use to obtain the correct guest
   block-device path?
3. Is the intended provider expected to use USB mass storage, Virtio block, NBD,
   or another mechanism?
4. If this is not currently supported, should post-create
   LinuxPod.addContainer be treated as unsupported for public VZ consumers
   until a provider implementation is included?

For my local-dev orchestrator use case, this means I should not rely on
post-create hotplug yet. I am moving the product path toward fast pod recreate
plus rootfs copy avoidance / APFS clone / writable-layer investigation, while
keeping LinuxPod hotplug as an upstream/research track.