[pve-devel] [PATCHES] Add VM.Snapshot.Rollback privilege

[Matthias Urban]

Hello,

thank you for your comments.

On 09.09.2017 16:47, Dietmar Maurer wrote:
> First, thanks for that patch!
>
> Further comments inline:
>
>> there is only one privilege for controlling the access to snapshots,
>> i.e. VM.Snapshot. This makes it impossible to separate administrative
>> access (create, update, delete) from user access (rollback) to
>> snapshots.
> rollback destroys all current data, so this is more dangerous than
> create, update or delete a snapshot. IMHO, nothing a user should be
> allowed to do.
You're absolutely right for virtual machines running infrastructure 
services for instance. The current state of such VMs is crucial.

This is not necessarily the case for VMs just used for running tests, 
especially not for automated tests. Such VMs you want to roll back to a 
defined VM state before a new test run is started to get reproducible 
results. The current state doesn't matter at all when the tests are done 
and all results collected.

The new privilege wouldn't break the first use-case until not granted to 
any non-administrative user. But it would clearer support the second 
use-case.
>> Changing and deleting snapshots can be very sensible
>> operations in certain environments, e.g. if snapshots are
>> programmatically used for resetting unit test VMs in an automated test
>> environment (our use-case). Separating the ability to setup snapshots
>> from using them becomes crucial in such environments. This separation
>> can be achieved with an additional privilege, i.e. VM.Snapshot.Rollback,
>> allowing read and rollback access to snapshots only.
> For such automated test environment, I would simply clone a template.
> The admin can prepare the template, and the test user has full control over
> the cloned test machine.
>
> Would that work in your scenario?
We tested the template/clone alternative to snapshots because we use a 
Ceph cluster as storage (and snapshots with Ceph storage surprisingly 
doesn't seem to use copy-on-write, so we now use CephFS additionally), 
but had to reject it due to following reasons:

1. When a template needs to be updated, a full clone is required which 
not only may take a long time and a lot of free storage space, 
especially in a 3/2 Ceph cluster. But this also may lead to unwanted 
side-effects, like to loose activation of Windows-VMs due to a changed 
UUID and MAC (which may be fixed with some manual fine-tuning though).

2. The VM.Clone privilege alone is not enough to clone a template. 
Unfortunately you also need the VM.Allocate privilege, not only allowing 
to create new VMs but also to delete VMs. This is even worse than the 
snapshot privileges, at least for us.

3. There is a strong dependency between templates and linked clones 
which is not very well reflected in the Proxmox GUI. They are all placed 
on the same hierarchy level in the miscellaneous views of Proxmox making 
it hard to keep track on these dependencies. This is much better solved 
for snapshots. Viewing templates and linked clones as a tree structure 
would help a lot.
> Also, please read: https://pve.proxmox.com/wiki/Developer_Documentation
> for details about patches and CLA ...
Sorry, I had to place all patches in one mail because our intranet 
doesn't allow to send mail using git.
> Regards,
>
> Dietmar
>
Regards

-- 
Matthias Urban
Phone: +49-391-544569-32 Fax: +49-391-544569-90
-- 
pure-systems GmbH
Geschäftsführung: Danilo Beuche, Holger Papajewski
Sitz der Gesellschaft: Magdeburg
Registergericht: Amtsgericht Stendal, HRB 113044