4

I am trying to encrypt a 25gb partition on my SSD with cryptsetup in such a way that will allow QEMU-KVM to use it as the guests drive.

I have tried luksformatting the drive:

cryptsetup luksFormat /dev/disk/by-id/...

then opening it:

cryptsetup luksOpen /dev/disk/by-id/... windows-vm

although QEMU gets permission denied when trying to access the /dev/mapper/windows-vm device with this script:

#!/bin/bash exec qemu-system-x86_64 \ --enable-kvm \ -netdev user,id=vmnic -device virtio-net,netdev=vmnic \ -usbdevice tablet \ -monitor stdio \ -machine type=pc,accel=kvm \ -cpu host \ -m 4G \ -balloon virtio \ -name Windows \ -smp cores=2 \ -vga std \ -soundhw ac97 \ -drive file=/dev/mapper/windows-vm,cache=none,if=virtio \ "$@"

I have also tried mounting it, but mount complains that it has the wrong fs type, which makes sense since I did not run mkfs on the device. Although I would assume I wouldn't need to since Windows would format the device anyways.

Is there any way to pair the cryptsetup luks encryption with a partition in such a way so that once opened QEMU-KVM can read/write/boot from it as it would a normal qcow2/raw image file?

Edit: It turns out this may be a permissions issue with the /dev/mapper/windows-vm block device as when I run QEMU with root access the installation process began rather than giving me a permission denied error. Is there a way to allow a normal user to have direct access to the block device? By default cryptsetup gave the `/dev/mapper/windows-vm device root:root 0600.

Thanks.

Improve this question
1
  • You could probably set up a udev rule to change the group of the /dev/mapper/windows-vm block device to that of the qemu user (libvirt-qemu, perhaps?), and the perms to allow g+rw Commented Nov 12, 2015 at 22:26

1 Answer 1

Reset to default
2

I believe QEMU wants a disk image file and /dev/mapper/windows-vm is a block device. According to the Arch wiki you can pass QEMU a partition, but this would require you to run mkfs on the block device. The wiki then goes on to say that this approach is problematic since you cannot install a bootloader to a partition (which I do not think is 100% accurate). There might be some hope of getting this to work since Xen, which I think relies to an extent on QEMU, can handle a block device.

The easiest option, if you are not worried about the overhead of using a raw disk image file, would be to create a file system on the partition and then create a raw disk image file in that new file system. This disk image file will be encrypted since it is on the encrypted partition.

Improve this answer
5
  • What format should I format the block device to? NTFS? Would it work if I created a raw qemu-raw image and somehow mounted it as a loopback device via losetup then used luks encryption on it? Commented Nov 12, 2015 at 20:19
  • @randynewfield see my edit for what I would probably do, but I if you want to pass the block device to Windows, then NTFS is a good choice. Commented Nov 12, 2015 at 20:27
  • I think I figured out more of my problem. I launched qemu with root and it started up fine accessing /dev/mapper/windows-vm and began the installation process. So I should probably rephrase the question as "How can I access a /dev/mapper device as a normal user so that qemu can read/write to it". The block device is currently root:root 0600 by default. Commented Nov 12, 2015 at 20:37
  • @randynewfield that is in the arch wiki. You just need to change the owner/group or permissions on the block device. Commented Nov 12, 2015 at 20:39
  • 1
    Thank you, I've adjusted my script to use sudo to unlock the partition and to chown the block device, then run qemu without elevated privileges. This fixed alot of performance problems I was having and reduced install times from your suggested method I was using before (1 hour 20 minutes) down to 10-15 minutes. Commented Nov 12, 2015 at 21:04

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.