this adds a reboot api call for vms, which uses a reboot trigger file that gets detected by the qm cleanup call to start the vm again
this api call is useful when users want to apply pending hardware changes without waiting for the vm to shutdown i send this as rfc because i am not sure with the following things: (probably makes more sense to read this after looking at the patches) * how to properly handle locks in this case? afaics with containers, we do not, as in there could be a race (albeit a short one) where the user could start/delete/move the container when rebooting it here i also simply trust that the code runs fast enough for the user not be able to do anything in between... we could of course also start with '--skiplock', while still holding the lock during cleanup * makes the whole design sense? should we instead start our own task instead and poll the shutdown/start procedure? Dominik Csapak (4): qm: cleanup: detect and handle reboot trigger api: add reboot api call qm: add reboot command api: add missing index child links PVE/API2/Qemu.pm | 49 ++++++++++++++++++++++++++++++++++++++++++++++++ PVE/CLI/qm.pm | 15 +++++++++++++++ 2 files changed, 64 insertions(+) -- 2.20.1 _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
