applied series, and sending a followup commit...
On Fri, Jun 01, 2018 at 04:37:37PM +0200, Thomas Lamprecht wrote:
> This aligns the VM creation code more with the CT one.
> We to not lock and then execute a worker but rather fork the worker
> first and lock there then, which allows nested flock-ing if needed.
> Add a small helper which creates a new locked (vm creation/restore to
> new) or just locks the existing one (vm restore to existing) before even
> forking the worker - which improves responsiveness and API usability
> as we abort early not only once we forked and checked in the locked
> context of the worker.
> With this then we can add a property which let's the VM auto start after
> it was created successfully.
> This is more a RFC for if the general approach is OK, I did not yet
> tried to test through edge cases.
> Thomas Lamprecht (3):
> API/create: move locking inside worker
> reserve config with create lock early
> api create: allow auto vm start after create finished
> PVE/API2/Qemu.pm | 61 ++++++++++++++++++++++++++----------------------
> 1 file changed, 33 insertions(+), 28 deletions(-)
> Thomas Lamprecht (1):
> add create_and_lock_config
> PVE/AbstractConfig.pm | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
pve-devel mailing list