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
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
