bug(vm): creating a sandbox from a local Docker image reports the bootstrap image as "Image pulled" and shows no export progress #4771

User Story

I use OpenShell (0.1.3, checked against 0.1.5) with the MicroVM driver. I create sandboxes from images I build locally with Docker; some are several GB.

I directly see sandbox create report Image pulled (512 MB) within a second and then sit for minutes in image export and root-disk preparation without byte progress for my image. The stock v0.1.5 non-interactive output reported [0.6s] Image pulled (512 MB).

This affects the first create of every local image.

Problem Statement

For a local Docker image, the create progress completes the image step with the size and time of the VM driver's bootstrap image, not the requested image. The long steps that follow (exporting the image's root filesystem from Docker, staging it and formatting the root disk) show only as detail text under "Starting sandbox", with no byte counts.

The export is also staged more than once:

• streamed out of Docker into a tar;
• copied into the staging directory;
• packed into an ext4 image;
• extracted by the guest prep VM.

In an earlier 0.1.3 run, a cold create of a 4.9 GB image took about 6 minutes: about 3 for the export and about 1.5 for formatting the root disk. On v0.1.5, the 8.1 GB test image reached VM-supervisor startup after 227.1 s; policy activation then timed out, so no successful total time was measured.

Impact / Why This Matters

• Users read the subsecond "Image pulled" result as done and then assume the create hung. There is no way to tell export progress from a stall.
• The cold create time for a large local image approaches the 5-minute provisioning deadlines discussed in Hard-coded 5-minute provisioning/bootstrap deadlines make sandboxes unusable on slow isolation backends (CoCo/peer-pods) #4364.
• The only workaround is to pre-create one throwaway sandbox per image ahead of time.

Acceptance Criteria

• For a local image, the image step names the local image, not the bootstrap image, and is reported only when that image's root filesystem is ready.
• The export and root-disk steps show progress (bytes or percent) or at least elapsed time per step.
• The exported root filesystem is not copied in full a second time on the host, so a cold create of a multi-GB local image is measurably faster than on 0.1.5.

Reproduction Steps

1. Run docker build -t local-big:1 ., using a Dockerfile FROM ghcr.io/nvidia/openshell-community/sandboxes/base that adds a few GB of files.
2. On a VM-driver gateway with an empty image cache, run openshell sandbox create --from local-big:1 -- true.

Expected: progress that names local-big:1 and the export.
Actual on v0.1.5: [0.6s] Image pulled (512 MB) described the bootstrap disk, then the 8.1 GB local image export and root-disk preparation appeared only as unquantified detail lines. Preparation reached Waiting for VM supervisor at 227.1 s. The CLI test wrapper ended after 450 s; the gateway later marked the sandbox Error with ProvisioningTimedOut after a 300-second policy-repair window.

Suggested UX (if applicable)

✓ Image exported from local Docker (local-big:1, 4.9 GB) (3m02s)
✓ Root disk prepared (1m31s)

Environment

• Stock OpenShell 0.1.5 release binaries, checksum verified.
• RHEL 9.8, kernel 5.14.0-687.45.1.el9_8.x86_64, x86_64 KVM; Docker 29.8.1; Podman 5.8.2. The VM gateway ran as a separate user-level installation with temporary kvm and docker supplementary process groups.
• VM driver pinned with driver_dir to the isolated v0.1.5 binary; local-big:1 was built locally from the community base image with a 3 GiB file and had Docker image size 8,089,725,051 bytes.

Logs

[0.6s] Image pulled (512 MB)
[0.6s] Preparing image cache
[0.6s] Exporting local image rootfs
[90.8s] Formatting root disk
[165.8s] Preparing rootfs
[227.0s] Preparing overlay disk
[227.1s] Waiting for VM supervisor
ConfigurationReady False ConfigurationInvalid Effective configuration could not be activated; replace the policy or repair attached providers
Ready False ProvisioningTimedOut Provisioning repair window expired after 300 seconds: Effective configuration could not be activated; replace the policy or repair attached providers