block: add read-only VMDK disk image support

[ChengyuZhu6]

This change adds read-only VMDK support to the virtio-block path, and the primary motivation is the EROFS fsmerge scenario described in containerd/nerdbox#30. In that workflow, multiple layer blobs are referenced through one VMDK descriptor, so the guest can consume them as one logical block device instead of attaching many devices.

Why this is needed:
The main driver is the EROFS fsmerge workflow (see containerd/nerdbox#30). In that setup, many layer blobs are referenced by a small metadata image. For VM-based runtimes, attaching one block device per layer does not scale well.

What is included in this patch:
This patch adds read-only VMDK support so those layers can be presented as one logical disk through a standard descriptor format. That removes the need to pass a large number of block devices or add an extra image conversion step before boot.

How this solves the problem:

• when a disk is opened, Firecracker detects VMDK and selects the VMDK engine;
• read requests are served through the VMDK backend and mapped into guest memory;
• write requests fail with a clear unsupported error, preserving read-only semantics;
• raw image behavior remains unchanged.

Changes

...

Reason

...

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• I have read and understand CONTRIBUTING.md.
• I have run tools/devtool checkbuild --all to verify that the PR passes
  build checks on all supported architectures.
• I have run tools/devtool checkstyle to verify that the PR passes the
  automated style checks.
• I have described what is done in these changes, why they are needed, and
  how they are solving the problem in a clear and encompassing way.
• I have updated any relevant documentation (both in code and in the docs)
  in the PR.
• I have mentioned all user-facing changes in CHANGELOG.md.
• If a specific issue led to this PR, this PR closes the issue.
• When making API changes, I have followed the
  Runbook for Firecracker API changes.
• I have tested all new and changed functionalities in unit tests and/or
  integration tests.
• I have linked an issue to every new TODO.

---

• This functionality cannot be added in rust-vmm.

[hsiangkao]

@ChengyuZhu6 what prevents this as a draft?

[ShadowCurse]

Hi @ChengyuZhu6, unfortunately we don't have enough bandwidth to review this for now.

[hsiangkao]

Hi @ChengyuZhu6, unfortunately we don't have enough bandwidth to review this for now.

@ShadowCurse I guess this one is not complicated and it seems almost half the change is test cases.
Since it uses imago library to handle vmdk format, I guess the remaining logic should be straight-forward?

Also I guess the commit message should be improved to make the usage clear at least.

[Manciukic]

Hey @hsiangkao, @ChengyuZhu6,

first of all, thank you very much for the contribution! I think this is a very promising solution for container workloads. Do you have any examples on how this would integrate with containerd?

However, we take every new feature very seriously and we need to undergo an internal security review for every new feature, which means that despite the change itself being small, it requires a non-trivial amount of time from our side that we don't have at the moment.

In any case, having a very quick look at the PR:

• do we really need a dependency on tokio?
• the dependency on imago is fine, I think (but I didn't check that crate yet), but it should be from crates.io and not gitlab.

[hsiangkao]

Hey @hsiangkao, @ChengyuZhu6,

first of all, thank you very much for the contribution! I think this is a very promising solution for container workloads. Do you have any examples on how this would integrate with containerd?

Hi @Manciukic, thank you very much for the reply! currently I don't have some free slot to run an end-to-end example using containerd + kata-containers + firecracker, but I will find (or I hope @ChengyuZhu6 could finish the pull request message at least) time to run an e2e later.

but the story is much similar to what we did for nerdbox + libkrun:
containerd/nerdbox#30

and my final interest is that to apply VMDK to virtio-pmem as well so that each backing file can be passthrough into guests and shared in a finer way: of course, virtio-pmem could bring some security concern, but depends on the workload, it could also be useful if memory sharing is not an issue.

However, we take every new feature very seriously and we need to undergo an internal security review for every new feature, which means that despite the change itself being small, it requires a non-trivial amount of time from our side that we don't have at the moment.

In any case, having a very quick look at the PR:

• do we really need a dependency on tokio?

I will defer this question to @ChengyuZhu6 .

• the dependency on imago is fine, I think (but I didn't check that crate yet), but it should be from crates.io and not gitlab.

yes, imago has published on crates.io with qcow2 and this limited vmdk support.

[ChengyuZhu6]

In any case, having a very quick look at the PR:

• do we really need a dependency on tokio?

Good catch. I removed the direct tokio dependency, tokio is still present transitively via imago’s sync-wrappers feature, so behavior is unchanged.

[ChengyuZhu6]

• the dependency on imago is fine, I think (but I didn't check that crate yet), but it should be from crates.io and not gitlab.

Agreed. I switched imago from gitlab to crates.io (imago = "0.2.3" with sync-wrappers).

[hsiangkao]

@ChengyuZhu6 @ShadowCurse @Manciukic could we consider enabling qcow2 using imago too?
Since qcow2 natively supports disk snapshots (and most cloud vendors already support qcow2 disks)and particularly useful for agent sandboxes.

[ChengyuZhu6]

@ChengyuZhu6 @ShadowCurse @Manciukic could we consider enabling qcow2 using imago too? Since qcow2 natively supports disk snapshots (and most cloud vendors already support qcow2 disks)and particularly useful for agent sandboxes.

I think this is a good idea. I suggest including it in the following PR, since it would make review easier.