[pve-devel] avoiding VMID reuse

Lauri Tirkkonen lauri at tuxera.com
Tue Mar 13 10:15:23 CET 2018


On Tue, Mar 13 2018 10:06:41 +0100, Thomas Lamprecht wrote:
> On 03/12/2018 03:13 PM, Lauri Tirkkonen wrote:
> > Hi,
> > 
> > we'd like to keep VMIDs always unique per node, so that we can use zfs
> > for backups more easily (ie. avoid dataset name collisions; granted,
> > this still leaves room for collisions if disks are removed and added to
> > a VM). We've implemented the following (crappy) PoC that accomplishes
> > just this by storing the highest allocated VMID and returning that for
> > /cluster/nextid.
> > 
> 
> Sorry if I misunderstood you but VMIDs are already _guaranteed_ to be
> unique cluster wide, so also unique per node?

I'll try to clarify: if I create a VM that gets assigned vmid 100, and
use zfs for storage, its first disk image is called
<zfsstorage>/vm-100-disk-1. If I then later remove vmid 100, and create
another new VM, /nextid will suggest that the new vmid should be 100,
and its disk image will also be called vm-100-disk-1. We're backing up
our disk images using zfs snapshots and sends (on other ZFS hosts too,
not just PVE), so it's quite bad if we reuse a name for a completely
different dataset - it'll require manual admin intevention. So, we want
to avoid using any vmid that has been used in the past.

> Your approach, allowing different nodes from a cluster to alloc
> the same VMID also should not work, our clustered configuration
> file system (pmxcfs) does not allows this, i.e. no VMID.conf
> file can exist multiple times in the qemu-server and lxc folders
> ()i.e., the folders holding CT/VM configuration files)

Right. We're not actually running PVE in a cluster configuration, so I
might've been a little confused there - if the VMID's are unique in the
cluster anyway, then the storage for the counter shouldn't be under
"local/", I suppose.



More information about the pve-devel mailing list