Suggestion for a Feature to Temporarily Remove VM Configuration

[diegocostaroot]

Hello Proxmox Team,

I would like to suggest a useful feature for Proxmox VE. Currently, there is no built-in option to remove only the VM configuration or to unregister a deactivated VM from the list without deleting its disks. This functionality would be very helpful for managing inactive VMs more efficiently.

Since this option does not exist, I have developed a script that temporarily moves the VM configuration (without moving the disk) to another location, specifically to /root/backup-vm. This allows for a temporary "unregistration" of the VM while keeping its data intact.

I am sharing this script with you so that you can consider implementing a similar feature in future Proxmox VE updates. Let me know if you find this idea valuable!


To run the script, simply place it in /bin/move-conf.sh and grant execution permission with:
chmod +x /bin/move-conf.sh

The script will prompt for the VM ID to move. When restoring, it will list the VMs already stored in the destination (/root/backup-vm/

 

[bbgeek17]

I would like to suggest a useful feature for Proxmox VE. Currently, there is no built-in option to remove only the VM configuration or to unregister a deactivated VM from the list without deleting its disks. This functionality would be very helpful for managing inactive VMs more efficiently.

Can you expand on a use-case for such action?

If one were to use your script, wouldn't a next VM create potentially fail due to disk presence conflict? Or, having forgotten about this action there would be stranded orphan disks. Or, a restore could erase these disks if the VMID collided.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[Gilberto Ferreira]

Hello Proxmox Team,

I would like to suggest a useful feature for Proxmox VE. Currently, there is no built-in option to remove only the VM configuration or to unregister a deactivated VM from the list without deleting its disks. This functionality would be very helpful for managing inactive VMs more efficiently.

Since this option does not exist, I have developed a script that temporarily moves the VM configuration (without moving the disk) to another location, specifically to /root/backup-vm. This allows for a temporary "unregistration" of the VM while keeping its data intact.

I am sharing this script with you so that you can consider implementing a similar feature in future Proxmox VE updates. Let me know if you find this idea valuable!


To run the script, simply place it in /bin/move-conf.sh and grant execution permission with:
chmod +x /bin/move-conf.sh

The script will prompt for the VM ID to move. When restoring, it will list the VMs already stored in the destination (/root/backup-vm/

I think turns the VM into a template or even clone it would be a more efficient way to deal with it.
Just move the vm config to another folder doesn't fix the issue, because the VM virtual disk will be there anyway.
This could be lead for potential mistakes.
Just my 2 cents.

 

[diegocostaroot]

Use Case for Temporarily Moving VM Configuration​

Scenario​

An administrator is managing a Proxmox VE cluster and needs to temporarily remove a virtual machine (VM) from the list without deleting its storage. This can be useful in situations such as:

• Archiving a VM: The VM is no longer in use but might be needed in the future. Instead of deleting it, the admin moves the configuration file from /etc/pve/qemu-server/ to /root/backup-vm/, effectively "unregistering" the VM without affecting its disks.
• Cleaning up the VM list: The Proxmox web interface and the qm list command show all configured VMs. This script allows an admin to hide deactivated VMs from the list without permanently removing them.
• Avoiding accidental deletion: Instead of removing the entire VM, which would delete both the configuration and disks, the admin can safeguard the VM configuration while keeping the disks intact.

---

Potential Issues & Considerations​

1. New VM Creation with the Same ID
   
   • If a new VM is created with the same ID as a "moved" VM, it may end up using the same disk names as the old one, leading to conflicts.
   • Mitigation: Before restoring, the script can check whether an active VM with the same ID already exists. Additionally, the admin should manually verify disk mappings before creating a new VM.
2. Orphaned Disks
   
   • If the admin forgets about the moved VM, its disks could remain unused, consuming storage space without being associated with any VM.
   • Mitigation: The script could log actions in a separate file, or the administrator should periodically review the contents of /root/backup-vm/ to manage orphaned disks manually.
3. Data Loss on Restoration
   
   • If a new VM is created with the same ID and the old configuration is later restored, there could be unintended overwrites or mismatches.
   • Mitigation: Before restoring, the script should check whether a VM with the same ID already exists and warn the user before proceeding.

---

Enhancing the Script for Safety​

• Check for Active VMs Before Restoring
  Before restoring a VM, verify if another VM with the same ID exists using:
  
  
  if qm status $VM_ID &>/dev/null; then
  echo "Error: A VM with ID $VM_ID already exists. Restoration aborted."
  exit 1
  fi
  
  
  
  
  
• Log Moved and Restored VMs
  The script could maintain a log file (/var/log/move-conf.log) tracking moved/restored VM configurations.
• Prevent Accidental VM ID Reuse
  The script could add an option to "reserve" moved VM IDs to avoid conflicts when creating new VMs.

---

Conclusion​

The script provides a quick and useful way to "hide" or temporarily unregister a VM without deleting its data. However, careful management is necessary to avoid conflicts, orphaned disks, or accidental overwrites when restoring.

 

[bbgeek17]

Hi @diegocostaroot , I've taken a look at your script and noticed that it presumes that it is being run from a node where the VM resides, without cluster awareness. This suggested to me that its more homelab oriented than enterprise.

That being said, there are other, existing, methods of addressing your use-case requirements:

Archiving a VM

Generally, in enterprise environment, archiving means that both metadata (configuration) and data of the VM are preserved in a consistent matter. A "vzdump" of the VM is one such method. In general, "backup" is an appropriate archival method. As was mentioned previously, you could use "template" functionality even though it's main purpose is different.

Cleaning up the VM list

You could employ "tags" in combination with "Tag View" in UI to organize the list of VMs. Another method is to rename the VM with a prefix, i.e. archived_*.

Avoiding accidental deletion

Safeguarding by obfuscating is less than ideal. Someone can still come to Storage/Disk list and then delete the "unused" disk from there.
In fact, if you were to try to delete a disk for an existing VM, you'd get an error. But there is no safe-guard for orphan disk.
There already exists a mechanism to prevent deletion - you can "lock" the VM (man qm).

The script provides a quick and useful way to "hide" or temporarily unregister a VM without deleting its data. However, careful management is necessary to avoid conflicts, orphaned disks, or accidental overwrites when restoring.

I would recommend you continue working on your script. Here are a few improvements you can make:
- convert to using API or pvesh
- adjust to using cluster
- save "archived" config in a folder in /etc/pve , perhaps in addition to locally, so it will be available to all nodes in the cluster
- publish your script on github for further input by the community

Cheers

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox