Missing feature(s) - VM disk identification (notes), disk deactivation and more detailed backup handling

yummiweb

Well-Known Member
Sep 29, 2019
41
6
48
56
Feature Request 1 - VM Disk Identification (Notes)

There are numerous situations where it's crucial to be able to identify the individual disk images of a VM, for example, to perform a specific action such as resizing or moving them.

Unfortunately, identifying images is currently quite cumbersome, for example, using "qm guest cmd VMID get-fsinfo," and of course, this only works while the VM is running. But what happens if the VM is no longer running due to a problem?

Therefore, it would be beneficial to be able to assign certain information to each image to reliably identify it when needed. A UID would be one possibility, but its assignment would then have to be manually noted. A notes field for each image would probably be the most practical solution, but the fundamental question is, of course, where Proxmox should store this information to ensure reliable reconstruction. It would be worth discussing whether all information (including previous notes) should be retained when a VM is cloned or converted into a template.

Initially, I used to assign different image sizes during VM setup to use as identifiers. However, such assignments must be carefully recorded and, most importantly, not forgotten when resizing.

Another identifier, I thought, would be the disk numbers (Disk-0, Disk-1) or the SCSI LUN (sci0, sci9), but the disk numbers change when images are moved, and the SCSI LUNs are unfortunately not retained when an image is detached.

Another possibility was to include certain information in the disk image names, but so far I haven't found a simple (GUI) way to rename them. I could rename images at the file level, but this then had to be reflected in the respective VM configuration. But especially when working extensively with snapshots and wanting to add "the information" later, this becomes very error-prone, and when dealing with ZVOL volumes instead of images, the fun stops.

In my opinion, there is therefore an urgent need for an integrated way to assign identification information to each image or VM disk, or to have another fixed (unchanging) identifier. For easy assignment to storage locations, this would be helpful within the name. So, a DISKUID in the name after the VMID (vm-VMID-DISKUUID-disk-NR) or a freely selectable name component (vm-VMID-MYNAME-disk-NR). In my opinion, there is therefore an urgent need for an integrated way to assign identification information to each image or VM disk, or to have another fixed (unchangeable) identifier.


Feature Request 2 - Disk Deactivation

I've also noticed that it doesn't seem possible (in the GUI) to simply deactivate a VM disk when needed (and reactivate it later). In the GUI, I only see the option to remove a disk via "detach" (which results in the loss of the SCSI LUN) and then manually add it back (and specify the LUN again).

The GUI should provide an option to activate or deactivate a disk with a checkbox.
It would also be worth discussing whether there should be a way to allow activation or deactivation at runtime.

In this context (or in general), a "write-protection switch" might also be useful.


Feature Request 3 - More detailed backup handling


Currently, you can only choose whether or not each disk should be included in backups .

For example, I would like to set the switch to "off" for swap disks because their contents are generally not worth backing up. Swap disk consume a lot of space during each backup because they can hardly be reduced by using redundancies.

But if I don't back up swap, then the disk will be missing during a restore. I would have to manually recreate and mount it in PVE, I think? But then the disk would be completely empty and wouldn't have an internal UUID, or I would have to generate or assign one within the VM.

I would therefore like a special backup button "Backup once (again)" which, when checked, includes the respective disk in the backup during the next backup run and only references its backup in all subsequent backup runs.


Regards Yummiweb
 
Last edited:
Feature requests should be filed on bugzilla.proxmox.com since there is no guarantee that a staff member will read any post here. The bugzilla on the other hand is monitored by staff