vm id and vm name

[taich]

Hi,

every vm in proxmox has an ID (nubmer). On any storage all vm's are referenced by this ID and not the name. Does anyone know why this is so?

If I have a NFS storage that is used from different proxmox servers it is quite difficult to determine which ID belongs to what virtual machine.

Is it possible to change this, so that the name is used instead of the ID?
Is there a possibility on command line to find out the name of the VM?

Regards
Thomas

 

[dietmar]

every vm in proxmox has an ID (nubmer). On any storage all vm's are referenced by this ID and not the name. Does anyone know why this is so?

We use integer IDs to uniquely identify VMs (by design). Names are not unique (i.e. 'www')

Is it possible to change this, so that the name is used instead of the ID?

no

Is there a possibility on command line to find out the name of the VM?

On the pve server, you can inspect the VM config ...

 

[flove]

I also struggle identifying disks to the corresponding VM names.
Especially when you browse through old backups. I can't tell which VM it belongs to.

In this example I had a VM with ID 113 which has been deleted in May.
In August I created a new VM which got the same ID - I assume because it was free? Or does PVE keep track of all already used IDs?
Why not using something really unique like GUIDs?

Do you have some tips how to better identify the disks / datasets?
We could leverage ZFS custom attributes like pve-vm-name for example.


Thanks and best regards, Flo.

 

[LnxBil]

In this example I had a VM with ID 113 which has been deleted in May.

It's in your pool autobackup, so this is your fault, not PVEs fault that those datasets still exist. PVE removes the datasets if you remove the VM. Of course you also have to remove the automatic snapshots done by a third party software by hand and you would not have those problems.

Do you have some tips how to better identify the disks / datasets?

You mean besides that the ID is ALWAYS written in the dataset name / filename / lvm volume name?
The PVE configuration is based on a database, so a simple 1-to-1 (surjective) mapping of id to name is possible and can be queried by hand via SQL, API and CLI.

 

[flove]

Fault is a strong word I din't blame PVE for anything.

I know that it is in the dataset "zfs-autobackup" - I just find it difficult to tell whats really in the dataset with only the ID and no "friendly name"

Another Example: you delete a VM / Container but don't destroy the disk / zfs dataset.

You end up with a disk lingering around "vm-113-disk-0". I would be easier to recognise if we also could have the VM-name in it or for ZFS datasets the VM-Name inside a custom zfs attribute.

 

[LnxBil]

Fault is a strong word I din't blame PVE for anything.

Good ...

Another Example: you delete a VM / Container but don't destroy the disk / zfs dataset.

Technically true, but why would you unreference disks and the delete the VM without the disks? Why not just reconfigure the VM to your liking?

You end up with a disk lingering around "vm-113-disk-0". I would be easier to recognise if we also could have the VM-name in it or for ZFS datasets the VM-Name inside a custom zfs attribute.

Yes, and the attributes would most probably be for most people something like windows or test, so that you don't have any additional information at all. For me, the name is not enough either. I'm working with hundreds of VMs and store any information in the VM comments field and it still is not big enough for everything, so I created an documentation system that generates images that are then just accessed and displayes via the comments markdown field. Primary key is of course the VMID and yes, we have also problems with reusing IDs and backups etc ... yet we just store the creating and destroying of VMs also in our own database so that we have this information too.

 

[flove]

but why would you unreference disks and the delete the VM without the disks

Human error, Software error (VM moved to different host but some orphaned disks).

Reusing of IDs is also my biggest pain point - especially when it comes to backups.

WE should at leaset think about getting unique IDs instead of the incrementing IDs.

Of course you can workaround with custom scripts, documentation, etc.

 

[Neobin]

Somewhat related discussion:
https://bugzilla.proxmox.com/show_bug.cgi?id=4369

 

[flove]

Thanks @Neobin!
The discussion with Fabian Grünbichler is interesting.

In my opinion the whole VMID thing smells like a bad design decision in the first place.
There should be at least an option to work with GUIDs.
Whats max field size of VMID ?

Especially @mart.v has a point:

I believe that reusing a VMID is a security bug, not only a backup-related bug.

When I give permission for user X to VMID 123, that permission remains valid even after delete that server. So after VMID 123 is recycled to another server, that same user has permission to completely different server.

This is serious security breach when we try to give user access to Proxmox to several customers.

GUIDs are there for a reason.
Think of LDAP without SIDs...

Also found this:
https://lists.proxmox.com/pipermail/pve-devel/2018-March/030993.html
https://lists.proxmox.com/pipermail/pve-devel/2018-April/031490.html

 

[Zerstoiber]

I've read some of the discussion and Fabian writes "but it's not important for us" (slightly out of context, was specifically towards a security concern, but seems to apply to the whole VMID topic)

As a user, i have to say that it's a real day-to-day problem seeing only those VMIDs in many places.
And PVE not forgetting everything about previously used IDs - for example, re-creating a VM with a previous ID then shows old logs, is problematic, too. If a VM gets deleted, it's old performance-data, eventlog, etc. should be gone, too. (and therefor maybe included in PBS?).

I was not even aware of the security-implication of PVE re-using old permissions (but i did not check if that changed in the meantime).
But it is also an administrative concern with e.g. PBS* - it's really really really hard to distinguish stuff by ID alone!
*you only see the VMID, then have to "open" a backup-tree to see the comment which can be used to show the name as a tag - really cumbersome UX!

The VM-Name is way more important in an administrators day-to-day job and makes life much easier.
It was very nice to get the "show by Name in GUI" with 7.4 ("Guests in resource tree can now be sorted by their name, not only VMID")
But still mostly everywhere there's only IDs and you have to do visual matching with several browser-tabs to find what you need.


What might make sense to you developers or hardcore-automators does not make sense to most of us administrators!

If you could at least add the Name to e.g. disk-names, PBS,... next to the VMID, that would make life much easier - even if those files don't get renamed in case the VM ever gets renamed.

 

[flove]

Just trying to cleanup some backups on an off-site destination which receives backups from some standalone proxmox hosts.
It's impossible to tell, which vm / container is in the backup. Especially when the vm has been deleted and you want to restore it. What was the ID?
I don't know.

 

[LnxBil]

It's impossible to tell, which vm / container is in the backup.

No, it's not. Just look inside with vma.

 

[flove]

No, it's not. Just look inside with vma.

I don't understand, can you explain, please?

How can I tell with a list of zfs datasets like vm-103-disk-0, vm-104-disk-0, etc. what was the original VM name? What if the VM was deleted a year ago, the ID was used again? There is so much potential for errors.

 

[LnxBil]

I don't understand, can you explain, please?

man vma

Or just search the forum.

How can I tell with a list of zfs datasets like vm-103-disk-0, vm-104-disk-0, etc. what was the original VM name? What if the VM was deleted a year ago, the ID was used again? There is so much potential for errors.

What does that has to do with your initial question? You're talking about a backup and what is in the backup, this paragraph is about the actual VM files stored on the disk.

 

[wigor]

I've read some of the discussion and Fabian writes "but it's not important for us" (slightly out of context, was specifically towards a security concern, but seems to apply to the whole VMID topic)

As a user, i have to say that it's a real day-to-day problem seeing only those VMIDs in many places.
And PVE not forgetting everything about previously used IDs - for example, re-creating a VM with a previous ID then shows old logs, is problematic, too. If a VM gets deleted, it's old performance-data, eventlog, etc. should be gone, too. (and therefor maybe included in PBS?).

I was not even aware of the security-implication of PVE re-using old permissions (but i did not check if that changed in the meantime).
But it is also an administrative concern with e.g. PBS* - it's really really really hard to distinguish stuff by ID alone!
*you only see the VMID, then have to "open" a backup-tree to see the comment which can be used to show the name as a tag - really cumbersome UX!

The VM-Name is way more important in an administrators day-to-day job and makes life much easier.
It was very nice to get the "show by Name in GUI" with 7.4 ("Guests in resource tree can now be sorted by their name, not only VMID")
But still mostly everywhere there's only IDs and you have to do visual matching with several browser-tabs to find what you need.


What might make sense to you developers or hardcore-automators does not make sense to most of us administrators!

If you could at least add the Name to e.g. disk-names, PBS,... next to the VMID, that would make life much easier - even if those files don't get renamed in case the VM ever gets renamed.

In our cluster there the VMs are renamed often. So "most of us administrators" - 1. Please do not put any part of the VM Name in the disk-names.

 

[aduzsardi]

Kind of an old thread but i hope at one point that VMIDs as it is now go away and instead it's handled as a hidden field by proxmox itself as other people suggested having a UUID instead of an integer so that ID clashes are less likely