Recommendation from a client

[jmperrote]

We usually use proxmox on production environments, and it is a excellent product.

We have two recommendation that we believe that better the product.

1. One: backups is nice, but it will be really nice if we can insert a name a backup file. The problem generate because proxmox make a backup and the file name of backup is the vm id. When use a product for a long time in practice are creating and deleting vms, and the id is reutilization on other vms, so staring a mix on vms id and backups realized.
For that inconvenient on any bakcup we go to command line and rename the backup file maintenance the vzdump-qemu on the start.

So we want to recommend that proxmox available to possibility change the name on a backup action.

2. Size of disk on a vm.
Proxmox permit to create a vm disk on a VM with any size of disk, even if the physical size is not available.
We recommend that insert a control or something similar to limit the creation a new vm disk, corresponding to the size of disk available.

We have serious problem (vms freezing) on production environments, because for a error create a vm disk mayor of physical disk available and later when the disk if full vm crash. Is a human error on creating a VM but we think that the product can help limitation the creation or similar action.

 

[oguz]

hi,

1. One: backups is nice, but it will be really nice if we can insert a name a backup file. The problem generate because proxmox make a backup and the file name of backup is the vm id. When use a product for a long time in practice are creating and deleting vms, and the id is reutilization on other vms, so staring a mix on vms id and backups realized.
For that inconvenient on any bakcup we go to command line and rename the backup file maintenance the vzdump-qemu on the start.

this has been requested a couple of times already. you can see the feature request and discussion here[0]

2. Size of disk on a vm.
Proxmox permit to create a vm disk on a VM with any size of disk, even if the physical size is not available.
We recommend that insert a control or something similar to limit the creation a new vm disk, corresponding to the size of disk available.

this is called thin-provisioning (it's a feature). it allows you to create disks of arbitrary size, regardless of the physical limit. read more about it here[1]

[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=438
[1]: https://en.wikipedia.org/wiki/Thin_provisioning

 

[czechsys]

ad 2.]
this point is very annoying. Even on thick storages we can set vm disk higher than available space. It's dangerous and again, very dangerous, one mistake can destroy all vms on datastore for cluster.

What i am hugely missing:
1] total size of configured VM disks sizes for specific datastore, actual used/available/total for this datastore
2] when configuring VM size, there is no info about available size on specific datasttore
3] even tick box to allow overcomit is missing

I don't know, why Proxmox team think that such critical informations aren't needed.

Thin provision is the feature. But missing points 1-3] are the critical bugs that will eat data!

 

[Glowsome]

ad 2.]
this point is very annoying. Even on thick storages we can set vm disk higher than available space. It's dangerous and again, very dangerous, one mistake can destroy all vms on datastore for cluster.

What i am hugely missing:
1] total size of configured VM disks sizes for specific datastore, actual used/available/total for this datastore
2] when configuring VM size, there is no info about available size on specific datasttore
3] even tick box to allow overcomit is missing

I don't know, why Proxmox team think that such critical informations aren't needed.

Thin provision is the feature. But missing points 1-3] are the critical bugs that will eat data!

So in essence what you are saying is that ProxMox allows 'Overbooking' of storage .... which (both on thin and thick provisioning) is a big No for every admin.
My standing on this : Overbooking should _never_ be allowed as it fools the admin unless the admin knows exactly what he/she is doing .. and if he knows he/she should'nt, instead more storage should be made available ... i've had my share of issues with (other OS/solutions) customers abusing overbooking to keep management happy and not asking for more funds for storage ... the outcome was always bad for admins ... either being strung up by management, or users who then complained to management for loss of data and then got strung up by management.

 

[oguz]

My standing on this : Overbooking should _never_ be allowed as it fools the admin unless the admin knows exactly what he/she is doing .. and if he knows he/she should'nt, instead more storage should be made available ... i've had my share of issues with (other OS/solutions) customers abusing overbooking to keep management happy and not asking for more funds for storage ... the outcome was always bad for admins ... either being strung up by management, or users who then complained to management for loss of data and then got strung up by management.

there are always more than one perspectives. we do not want to limit options.

advantages of thin provisioning are not to be ignored (in terms of flexibility and ease of management), however if it does not fulfill your use case, you can use a different storage type without thin provisioning (or disable it depending on your storage and image format)

you can take a look here[0] for other options and a comparison table between types of storage.

[0]: https://pve.proxmox.com/wiki/Storage

 

[Glowsome]

@oguz i agree, as said i only expressed my standing, so its a personal preference/way to coap with it ...

I Did notice (and loved it) .. you honored the "array starts at 0"