Remove VM also deletes all VM hd's?

[Vassilis Kipouros]

Also deleting the actual rbd images?
Can anyone verify this pls?
Isn't this a little risky-weird?
Is there a way to disable/change this behaviour, leaving the disk deletion to be done manually?

Kind Regards

 

[tom]

yes. but in order to remove a VM (with the disks), you need to confirm this by entering the VMID, so there is already a hint to double check here.

 

[Alessandro 123]

Probably would be better to add a checkbox like "Delete associated virtual disk images" that as default is left unchecked

Something like XenCenter does.

Better stay of safety side....... Users tend to do copy/past, asking for vm id is mostly useless as a simple paste will skip the check

Would be better to ask for hostname or something more easier to remember
If I have 300 VM, asking a confirm deleting vm 100 is useless, I don't remember what vm 100 is but I know for sure that deleting "sql.mydomain.tld" is not what I want (and disable pasting in that field, you have to write manually)

 

[Vassilis Kipouros]

WTF?

Also removing a VM hd from hardware, says this:

"Are you sure you want to remove entry 'Hard Disk (scsi0)'
YesNo"


It says "entry" but deletes the image.

I just lost 8T of valuable data ffs....

Is there a way to undelete and rbd image???

 

[Vassilis Kipouros]

I agree with Alessandro, there should be a checkbox for also removing storage
that will be unchecked by default, and asked for confirmation when checked...
Both for VMs and CT storage...

 

[udo]

Also deleting the actual rbd images?
Can anyone verify this pls?
Isn't this a little risky-weird?
Is there a way to disable/change this behaviour, leaving the disk deletion to be done manually?

Kind Regards

Hi,
I would say of couse - because you remove the VM!
On the other case, you fill your storage with old, unknown disk... and it can be an bad surprise if you create an new VM with an old ID and has old, perhaps private data in access. Also not an good choice!

Udo

 

[fabian]

WTF?

Also removing a VM hd from hardware, says this:

"Are you sure you want to remove entry 'Hard Disk (scsi0)'
YesNo"


It says "entry" but deletes the image.

I just lost 8T of valuable data ffs....

Is there a way to undelete and rbd image???

huh? if you remove a disk of a VM, it will just be moved from the disk controller (like "scsi0") to "unusedX", where X is the next free unused index. only when you remove the "unusedX" entry, the actual disk image is deleted.. the same is true for container mountpoints, where "mpX" becomes "unusedY".

 

[Vassilis Kipouros]

I just learn about this now.

So when you have removed the entry and remains unused, and then remove the VM, the unused image also gets wiped.
That's how I managed to wipe my 8T image without even knowing...
I thought that removing the disk from the VM would save it from being deleted when removing the VM. Damn...

Is it only me finding both these behaviours totally wrong?

When removing a VM, or a disk from a VM there should be absolutely no deletion of HD's and images.
Especially when you don't get double informed and asked about confirmation.
OR there should be an option to preserve HD or purge with the VM.
And maybe unused image management should be done manually, or somewhere else in the gui.

 

[Alessandro 123]

Vassilis you are totally right

 

[fabian]

http://pve.proxmox.com/pve-docs/pve...ng_qm_strong_qemu_kvm_virtual_machine_manager

qm destroy <vmid> [OPTIONS]

Destroy the vm (also delete all used/owned volumes).

<vmid>: <integer> (1 - N)
The (unique) ID of the VM.

-skiplock <boolean>
Ignore locks - only root is allowed to use this option.

this is unlikely to change. while I am sorry for your loss, blindly assuming that the disks will be kept around without any indication that this is actually the case (or rather, with documentation stating the exact opposite) seems kind of careless to me.

(I also don't really understand why you would want to destroy a VM but keep the disks around - a VM is just a text file on our cluster file system which takes up virtually no space.. either you want to continue using the disks in a VM, then you can just adapt the configuration, or you don't, but then you normally want to remove the disks together with the configuration..)

 

[mir]

or making proper backup before deletion.

 

[ZachH83]

huh? if you remove a disk of a VM, it will just be moved from the disk controller (like "scsi0") to "unusedX", where X is the next free unused index. only when you remove the "unusedX" entry, the actual disk image is deleted.. the same is true for container mountpoints, where "mpX" becomes "unusedY".

How can you move the unusedX back to the a usuable state? I removed the harddrive to put it on another vm, but need to put it back, and seem to be stuck. I'm sure this requires its own topic, but I had seen you mention the unused status, so I'd imagine you konw how to get it back to a usable state.

 

[fabian]

you re-attach it (on the GUI) or simply set it into a regular disk slot (like scsiX) via the API/qm set. if you want to move a volume from one guest to another, there is a feature being worked on that allows that with all the proper checks, but it's not yet been applied/released. until that exists, you need to manually remove the entry from one config file and add it to another (not via the 'detach -> remove' flow, that will delete the volume!)

 

[ZachH83]

you re-attach it (on the GUI) or simply set it into a regular disk slot (like scsiX) via the API/qm set. if you want to move a volume from one guest to another, there is a feature being worked on that allows that with all the proper checks, but it's not yet been applied/released. until that exists, you need to manually remove the entry from one config file and add it to another (not via the 'detach -> remove' flow, that will delete the volume!)

Thanks for the reply.

When I attempt to reattach it, it shows a much lower volume available amount. It doesn't give me the option to attach the original 24TB, but instead shows only a few hundred GB available to attach. If I change the number to the 24tb amount, it says its not available to attach.

 

[fabian]

please post the guest and storage configs..

 

[mcdebugger]

Isn't it better to use some kind of randomly generated UUIDs in vm disk names? With some metadata stored in a cluster (attaching it to instance VID for example).
Thus we can safely remove instance without wiping the data and of course we can do it later in storage management.

There are many use cases for it. We can have some data storage logical volumes (for databases, smb share, backups/archives etc) that we definitely don't want to lose and we can use later in new instances or even separately on another machine.

Also sometimes we need to attach external disks to our instances (pre-filled with data or for some maintenance).

UPD: probably I don't understand the concept correctly. We can attach "persistent" storage just by pointing to the block device itself in qm set.Need to do some testing but I hope that this way it won't being wiped when I remove vm.

 

[fabian]

only volumes "owned" by a particular VMID (by having it in the volume iD according to the schema) should be freed on guest or disk/mountpoint removal. anything else will just be logically removed from the config. there are some corner cases that might warrant attention though, especially if you use a "fake" VMID as owner of such volumes - that information might not be tracked across all operations involving volumes, such as cloning or moving them from one storage or node to another.