encrypted volumes are directly attached to instances after a compute host reboot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Matthew Booth |
Bug Description
Description
===========
Encrypted volumes are directly attached to instances after a compute host reboot. These volumes should be decrypted by the os-brick encryptors that provide libvirt with decrypted dm devices for use by the instance/domain.
This is due to the following encryptor.
5204 def _create_
5205 block_device_
5206 power_on=True, reboot=False,
5207 vifs_already_
5208 post_xml_
5209 destroy_
[..]
5218 if (not reboot and 'data' in connection_info and
5219 'volume_id' in connection_
5220 volume_id = connection_
5221 encryption = encryptors.
5222 context, self._volume_api, volume_id, connection_info)
5223
5224 if encryption:
5225 encryptor = self._get_
5226 encryption)
5227 encryptor.
Steps to reproduce
==================
- Create an instance with an attached encrypted volume:
$ cinder type-create LUKS
$ cinder encryption-
$ cinder create --display-name 'encrypted volume' --volume-type LUKS 1
$ nova boot --image cirros-
$ nova volume-attach c762ef8d-
- Before continuing note that the instance is connected to the decrypted dm device:
$ sudo virsh domblklist c762ef8d-
Target Source
-------
vda /opt/stack/
vdb /dev/disk/
$ ll /dev/disk/
lrwxrwxrwx. 1 root root 56 Oct 18 08:28 /dev/disk/
- Restart the n-cpu host _or_ fake a host reset by stopping the n-cpu service, destroying the domain, removing the decrypted dm device, unlinking the volume path before finally restarting n-cpu:
$ sudo systemctl stop devstack@n-cpu
$ sudo virsh destroy c762ef8d-
$ sudo cryptsetup luksClose /dev/disk/
$ sudo unlink /dev/disk/
$ sudo systemctl start devstack@n-cpu
- The instance should be SHUTDOWN after n-cpu starts up again. So start the instance:
$ nova start c762ef8d-
- The instance is restarted but now points at the original encrypted block device:
$ sudo virsh domblklist c762ef8d-
Target Source
-------
vda /opt/stack/
vdb /dev/disk/
$ ll /dev/disk/
lrwxrwxrwx. 1 root root 9 Oct 18 08:32 /dev/disk/
- Additional stop and start requests will not correct this:
$ nova stop c762ef8d-
$ nova start c762ef8d-
$ sudo virsh domblklist c762ef8d-
Target Source
-------
vda /opt/stack/
vdb /dev/disk/
$ ll /dev/disk/
lrwxrwxrwx. 1 root root 9 Oct 18 08:32 /dev/disk/
Expected result
===============
The decrypted volume is attached to the instance once it is restarted.
Actual result
=============
The encrypted volume is attached to the instance once it is restarted.
Environment
===========
1. Exact version of OpenStack you are running. See the following
list for all releases: http://
# git rev-parse HEAD
fce56ce8c04b
2. Which hypervisor did you use?
(For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
What's the version of that?
Libvirt + KVM
2. Which storage type did you use?
(For example: Ceph, LVM, GPFS, ...)
What's the version of that?
LVM+iSCSI
3. Which networking type did you use?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
Logs & Configs
==============
See above.
Changed in nova: | |
assignee: | nobody → Lee Yarwood (lyarwood) |
status: | New → In Progress |
Changed in nova: | |
assignee: | Lee Yarwood (lyarwood) → Matthew Booth (mbooth-9) |
summary: |
- When using resume_guests_state_on_host_boot encrypted volumes are - directly attached to instances after a host reboot + encrypted volumes are directly attached to instances after a compute + host reboot |
description: | updated |
tags: | added: libvirt |
tags: | added: volumes |
Changed in nova: | |
importance: | Undecided → Medium |
Huh, so this actually reproducible by just using `nova stop $instance ; nova start $instance` after the host reboot. I missed this when initially creating the bug as I assumed it was due to the state the host was in after resume_ guests_ state_on_ host_boot attempted and failed to run the instance.
IMHO resume_ guests_ state_on_ host_boot is just broken and not tested anywhere, I'd like to re-purpose this bug to tackle the simpler stop;start use case that should be fixed by the following change:
https:/ /review. openstack. org/#/c/ 400384/