Encrypt VM disk upon VM creation

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

this may help: Images — OpenNebula 6.4.0 documentation

@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

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

Did you define the secret in the hypervisors?

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>

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.