There's an edge case with 'restart' migration for containers that breaks
because of the new content type on startup checks:
If there is an already running container with a volume on storage A, and
now storage A is reconfigured to not support 'rootdir' anymore, then
migration itself does work, but there'll be an error on startup on the
remote node. It would be nicer if the error would appear at the start of
the migration already.
For VMs (with 'online' migration) the situation is not as bad, because
the remote start happens earlier, so the VM will still be running on the
original node after the error.
And one can offline migrate such unstartable guests around ;)
IMHO, if we add the checks for content type on startup, it's all the
more reason to have content type checks for migration as well. For VM
migration with the targetstorage option, there already are such checks.
It's a tangential problem of course, your patches look fine to me:
Reviewed-by: Fabian Ebner <f.eb...@proxmox.com>
Am 27.05.21 um 14:23 schrieb Lorenz Stechauner:
changes to v2:
* typo s/supoort/support/
* more detailed error messages
* implemented check also for vms
pve-container:
Lorenz Stechauner (1):
fix #3421: allow custom storage plugins to support rootfs
src/PVE/LXC.pm | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
qemu-server:
Lorenz Stechauner (1):
vm_start: check if storages of volumes support content images
PVE/QemuServer.pm | 7 +++++++
1 file changed, 7 insertions(+)
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
