What is the use case for "persistent" images?

Solutions
1

Last year, I have found out (after reporting a bug) that I’ve always used the “persistent” flag when instantiating a VM wrong.

In essence, I’ve always flagged that option when launching a new VM (in my mind they were “persistent”) and this resulted in a few things:

  • A new image was created for every VM in my “templates” datastore
  • Each VM had its own template

The first bit was a pain, the second turned useful over time - for example for changing parameters and easily re-instantiating.

I’ve now moved to “non persistent” - which works much better for all my intents and purpose but this left me with a question: what is the use case for “persistent” VMs? Am I missing something?

Also, maybe a bit of feedback - the term is probably misleading (and multiple discussions in this forum sort of prove it) - last thing I would have expected is for it to mean that storage will persist to a termination.

Thanks!

2

Hello.

We use persistent images for production VM where data must survive a terminate.

In addition to locking the VM, we make sure data are never lost.

Regards.

3

So you consider this flag as a last resort safety net? Someone unlocks by mistake AND terminates by mistake?

How do you handle the datastores? Do you manually copy the tpl or you have a single datastore and are happy with tpls and everything else living in it?

4

Damn, I’ve just found the use case, two days in. I’ve smashed the kernel on a test instance, so went down the usual path of detaching and attaching the volume to a temporary instance to chroot & fix… Except after detaching, my data was gone.

(I should have copied the volume and fixed there, the problem is that then I would not have been able to restore the qcow2 “tree” and save space)

5

Sad to here you learned the hard way.

Non persistent images are always cloned to the system datastore and disappear when a VM is terminated or, as you found, the disk detached.