[pve-devel] Fix Bug #889 and allow automatic VMID selection on create

[Fabian Grünbichler]

On Mon, Oct 17, 2016 at 05:44:31PM +0200, Thomas Lamprecht wrote:
> The get /cluster/nextid API call is not secured against race conditions and
> parallel accesses in general.
> Users of the API which created multiple CT in parallel or at least very fast
> after each other run into problems here: multiple calls got the same VMID
> returned.
> 
> Fix this by allowing the /cluster/nextid call to virtually reserve VMIDs
> temporary.
> Also add the possibility that the create_vm calls from CTs and VMs can auto
> select a VMID, for convenience (also it was requested as a feature).
> 
> This means changes on a few packages (cluster, common, container,
> qemu-server)
> 
> The first to patches should be quite straight forward and relevant for the
> bug fix.
> 
> The other three may be seen as RFC.

I think "reserve" is a bit misleading here - if I GET cluster/nextid
with reserve set, it returns an ID. but now anybody can use this ID
(create/restore VM/CT), not just me. this is not what I would expect ;)

I know the purpose is to take it out of the "pool" that the nextid API
call uses, but IMHO for that we could just change the default behaviour
of nextid to always do that (there's no harm, especially if it's
documented and just for 60 seconds) and drop the reserve parameter
altogether (maybe introduce a switch to get the old, non-"reserving"
behaviour back?).

If you want to take it a step further into the direction of actual
reservation, you could (optionally, with "reserve" set) return an ID
plus token pair, and only allow usage of that ID (for the set amount of
time) when the given token is also passed to the create/restore API.

All of the above can of course be combined as well:
- default: ID without token, but taken out of pool
- with "reserve" set: ID plus token, taken out of pool
- with "legacy" set: ID, not taken out of pool