[openstack-dev] [nova] locked instances and snaphot

Jay Pipes jaypipes at gmail.com
Wed Jun 18 20:49:15 UTC 2014

On 06/18/2014 01:15 PM, Day, Phil wrote:
>> -----Original Message----- From: Ahmed RAHAL
>> [mailto:arahal at iweb.com] Sent: 18 June 2014 01:21 To:
>> openstack-dev at lists.openstack.org Subject: Re: [openstack-dev]
>> [nova] locked instances and snaphot
>> Hi there,
>> Le 2014-06-16 15:28, melanie witt a écrit :
>>> Hi all,
>> [...]
>>> During the patch review, a reviewer raised a concern about the
>>> purpose of instance locking and whether prevention of snapshot
>>> while an instance is locked is appropriate. From what we
>>> understand, instance lock is meant to prevent unwanted
>>> modification of an instance. Is snapshotting considered a logical
>>> modification of an instance? That is, if an instance is locked to
>>> a user, they take a snapshot, create another instance using that
>>> snapshot, and modify the instance, have they essentially modified
>>> the original locked instance?
>>> I wanted to get input from the ML on whether it makes sense to
>>> disallow snapshot an instance is locked.
>> Beyond 'preventing accidental change to the instance', locking
>> could be seen as 'preventing any operation' to the instance. If I,
>> as a user, lock an instance, it certainly only prevents me from
>> accidentally deleting the VM. As I can unlock whenever I need to,
>> there seems to be no other use case (chmod-like).
> It bocks any operation that would stop the instance from changing
> state:  Delete, stop, start, reboot, rebuild, resize, shelve, pause,
> resume, etc
> In keeping with that I don't see why it should block a snapshot, and
> having to unlock it to take a snapshot doesn't feel good either.

VMs should be cattle, not pets, but yes, a locked instance should be 
able to be snapshotted, for sure, IMO.

>> If I, as an admin, lock an instance, I am preventing operations on
>> a VM and am preventing an ordinary user from overriding the lock.
> The driver for doing this as an admin is slightly different - its to
> stop the user from changing the state of an instance rather than a
> protection.   A couple of use cases: - if you want to migrate a VM
> and the user is running a continual sequence of say reboot commands
> at it putting an admin lock in place gives you a way to break into
> that cycle. - There are a few security cases where we need to take
> over control of an instance, and make sure it doesn't get deleted by
> the user

But the user would still be able to SSH into their instance and do:

shutdown -r now


>> This is a form of authority enforcing that maybe should prevent
>> even snapshots to be taken off that VM. The thing is that enforcing
>> this beyond the limits of nova is AFAIK not there, so
>> cloning/snapshotting cinder volumes will still be feasible.
>> Enforcing it only in nova as a kind of 'security feature' may
>> become misleading.
>> The more I think about it, the more I get to think that locking is
>> just there to avoid mistakes, not voluntary misbehaviour.
>> --
>> Ahmed
>> _______________________________________________ OpenStack-dev
>> mailing list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list