canonical / canonical/multipass
Mutipass TPM Features
- Dominant language
- C++
- Stars
- 9.2k
- Forks
- 828
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 44
Description
What are you trying to do?
I want to provision a Linux VM with Multipass on Windows (Hyper-V), apply cloud-init automation, and use TPM-based provisioning for Azure IoT Edge (DPS TPM attestation).
In my workflow, TPM is a hard requirement. Today, Multipass can create and manage the VM, but there is no reliable/supported way to ensure vTPM is configured as part of the instance lifecycle. If I try to modify TPM settings directly in Hyper-V after creation, Multipass can become desynced (instance stuck in Starting/Unknown, socket/service instability, or VM no longer recognized correctly).
I also want a safe way to “handoff” a provisioned VM from Multipass management to native Hyper-V ownership without risking deletion on multipass delete/purge.
What's your proposed solution?
1) First-class TPM support in Multipass instance lifecycle
Add official support for TPM-related configuration at launch time and/or instance settings, for example:
multipass launch ... --tpm (or similar)
multipass set local..tpm=true (or equivalent model)
This should be implemented by Multipass itself (not requiring external Hyper-V mutations), so state remains consistent and daemon/client stability is preserved.
2) Safe “detach / export ownership” workflow
Add a supported command to transfer an instance from Multipass ownership to standalone hypervisor ownership, e.g.:
multipass detach or
multipass export --as-hyperv-vm
Expected behavior:
VM disk/config is preserved
resulting VM remains bootable/manageable in Hyper-V
Multipass no longer tracks/purges that VM by accident
3) Better diagnostics for backend desync
When backend state is inconsistent, return actionable diagnostics instead of generic failures (cannot connect to socket, Unknown, etc.), including clear guidance for recovery paths.
Additional context
Platform: Windows + Hyper-V
Use case: Azure IoT Edge with DPS TPM attestation
Current workaround attempts (manual Hyper-V TPM edits after Multipass launch) are fragile and can lead to Multipass desync
Cloud-init provisioning works well for guest config, but host-level TPM lifecycle is the missing piece
This feature would make Multipass much more usable for secure device provisioning workflows where TPM is mandatory, while reducing unsupported/fragile host-side hacks.
Contributor guide
Research direction
The issue identifies Windows with Hyper-V, the Multipass instance lifecycle, TPM configuration, ownership handoff, and backend desynchronization as the areas involved. Start by mapping how instance creation and deletion interact with the Hyper-V backend, then define the scope and recovery behavior for TPM support, safe detachment, and actionable diagnostics; done requires an agreed design and tests for each workflow.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, cpp, linux
- Domain
- cloud, infrastructure, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100