mirror of
https://git.proxmox.com/git/qemu-server
synced 2025-11-02 23:30:40 +00:00
a06b779489
tpmstate0 is already included in `get_vm_volumes`, and our only storage plugin that has unmap_volume implemented is the RBDPlugin, where we call unmap in `deactivate_volume`. So it's already ummapped by the `deactivate_volumes` calls above. For third-party storage plugins, it's natural to expect that deactivate_volume() would also remove a mapping for the volume just like RBDPlugin does. While there is an explicit map_volume() call in start_swtpm(), a third-party plugin might expect an explicit unmap_volume() call too. However, the order of calls right now is 1. activate_volume() 2. map_volume() 3. deactivate_volume() 4. unmap_volume() Which seems like it could cause problems already for third-party plugins relying on an explicit unmap call. All that said, it is unlikely that a third-party plugin breaks. If it really happens, it can be discussed/adapted to the actual needs still. Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Acked-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> |
||
|---|---|---|
| debian | ||
| PVE | ||
| qemu-configs | ||
| qmeventd | ||
| test | ||
| vm-network-scripts | ||
| .gitignore | ||
| bootsplash.jpg | ||
| bootsplash.xcf | ||
| Makefile | ||
| modules-load.conf | ||
| qm | ||
| qmextract | ||
| qmrestore | ||
