Encrypt VM disk upon VM creation

Community Support Storage
1

Hi

I am trying to encrypt VM disk upon VM creation. Any clue how this could be done from OpenNebula as a part of VM template where disk formate is qcow2

Thanks in advance

2

this may help: Images — OpenNebula 6.4.0 documentation

3

@tinova thank you for your reply.

I exactly followed the steps on the documentation page you sent.
I encrypted the OS image used in one VM template. Then I instantiated one VM from that template.
However, the VM is running normally but OS can’t be bootable. it says :

" Booting from Hard Disk
Boot failed: not a bootable disk
No bootable device. "

Then Tried to make a specific usage for the secret, so I added the image path to the secret XML definition file as follows, but OS did not boot as well.

<secret ephemeral='no' private='yes'>
   <description>LUKS Sample Secret</description>
   <uuid>f52a81b2-424e-490c-823d-6bd4235bc57</uuid>
   <usage type='volume'>
      <volume> /var/lib/one/datastores/102/Windows_image</volume>
   </usage>
</secret>

Any clue about the reason?
might it be related to the inability to decrypt the VM disk to read from it?
Thnx

4

It looks like the VM indeed cannot read the encrypted disk.

Did you define the secret in the hypervisors?

5

Hi @tinova ,
Thank you for your reply. Yes, I defined the secret in the hypervisors.

Basically, I want to encrypt an image that is being used for instantiating new VMs. So, first I created and encrypted an empty image of raw formate then I converted the already existing unencrypted image whose formate is qcow2 to the new empty encrypted image by the following command:

qemy-img convert …

Then I compared them by qemu-img compare …, and they were identical.

Then, I defined the secret in the hypervisor on which the VM was instantiated.
basically, I executed two versions of defining the secret and setting its value.

First, I executed the following by oneadmin, but the secret was not recognized when I execute virsh secret-list by oneadmin but it was recognized by other user accounts.

virsh -c qemu:///system secret-define secret.xml
virsh -c qemu:///system secret-set-value f52a81b2-424e-490c-823d-6bd4235bc57 "$(echo secret-passphrase | base64)"

Then, I executed the following by oneadmin, and the secret got recognized by oneadmin when I executed virsh secret-list later.

virsh secret-define secret.xml
virsh secret-set-value f52a81b2-424e-490c-823d-6bd4235bc57 "$(echo secret-passphrase | base64)"

However, the error was not resolved in both cases (i.e., I got “No bootable device” in both cases)

I am wondering how the decryption will be occurred without specifying the secret UUID in the VM XML definition, for this reason, I tried to add the following in the VM definition but I couldn’t find the context variables provided by OpenNebula and it is supposed to be used for defining the secret UUID.

<encryption format='luks'>
  <secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc57'/>
</encryption>
6

What you describes is similar to one use case in our QA certification.

The only difference is probably the use of qemu-img convert. Can you try creating an empty image with qemu-img create? Basically just following the documentation as verbatim as possible.

If that doesn’t work I guess the next step is to try and replicate the error without OpenNebula, using virsh commands.

7

Hi @tinova

Thank you for your reply!

I followed the documentation, but it did not work.

Then, I tried to create a VM using an encrypted disk using virsh and qemu commands; I created encrypted empty image, created the secret XML, defined the secret, and set a value for the secret which was used for encrypting the image in the beginning.

However, I got the same problem: the VM is not bootable. This means the hypervisor can not read the secret to decrypt the VM disk. When I started the VM (virsh start VM_name), I got the following error message; even i am sure that password is identical to that used for creating the image

Error starting domain: internal error: process exited while connecting to monitor: 2022-08-22T08:42:52.109337Z qemu-system-x86_64: -blockdev {“node-name”:“libvirt-2-format”,“read-only”:false,“driver”:“luks”,“key-secret”:“libvirt-2-format-luks-secret0”,“file”:“libvirt-2-storage”}: Invalid password, cannot unlock any keyslot

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 75, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 111, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/object/libvirtobject.py”, line 66, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/object/domain.py”, line 1279, in startup
self._backend.create()
File “/usr/lib/python3/dist-packages/libvirt.py”, line 1234, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirt.libvirtError: internal error: process exited while connecting to monitor: 2022-08-22T08:42:52.109337Z qemu-system-x86_64: -blockdev {“node-name”:“libvirt-2-format”,“read-only”:false,“driver”:“luks”,“key-secret”:“libvirt-2-format-luks-secret0”,“file”:“libvirt-2-storage”}: Invalid password, cannot unlock any keyslot

Any information about the reason here is appreciated!

8

apologies for the slow turnaround.

i cannot reproduce your problem, but i’ll try to redo the setup.

“Invalid password, cannot unlock any keyslot” is the relevant error message, I see you are trying to perform this operation without OpenNebula first, which is the right approach.

you can refer to libvirt doc to clarify concepts, this may help: libvirt: Secret XML format

9

Hi,

I know, is an old post, but as I jumped into the same issue:

virsh -c qemu:///system secret-set-value f52a81b2-424e-490c-823d-6bd4235bc57 "$(echo secret-passphrase | base64)"

use
printf %s “secret-passphrase” | base64

“echo” adds a CR to the output before it is encoded with base64 → wrong password stored.

Best, M

10

That’s surely it Michael :slight_smile: thanks for letting us know

11

@michael_kutzner Thank you for your response, i will try it

12

I exactly followed the steps on the documentation page you sent.

13

Thank you for your response.

.

14

We have updated our documentation on LUKS-encrypted images and provided more details on that topic. Now it covers two scenarios:

2 Likes