search for: luksdev

...es to a VM. This does not work when I create a filesystem directory storage pool in virt-manager since virt-manager obviously choked in /dev/mapper/control, which is a character special device that is only readable by root. I currently help myself by linking the devices in question manually to /dev/luksdev and having a filesystem directory storage pool point to that directory. this works, but is ugly. Is there a nicer way to get the contents of /dev/mapper available as volumes in virt-manager? Greetings Marc -- ----------------------------------------------------------------------------- Marc Hab...

I was attempting one way to solve: https://bugzilla.redhat.com/show_bug.cgi?id=1400332 "RFE: virt-builder should support templates with encrypted filesystems" However this approach doesn't really work because templates containing encrypted partitions cannot be compressed, and therefore the guest template would be a multi-gigabyte download. I better approach will likely be to use

...ocket,id=charmonitor,path=/var/lib/libvirt/qemu/snsvw001.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/dev/luksdev/mywindows,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:c4:16:65,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -d...

Original version linked from here: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 There is no change in the code in this series, but feedback from the original series was we shouldn't lose the error message in patch 7. When I tested this just now in fact we don't lose the error if debugging is enabled, but I have updated the commit message to note what the error message is in the

These commits, along with the associated changes to common: https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html support the transparent decryption and inspection of Windows guests encrypted with BitLocker encryption. To do the BitLocker decryption requires cryptsetup 2.3.0 (although cryptsetup 2.3 is not required for existing LUKS use). It also requires a new-ish Linux kernel, I

As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.

...n in `seq 1 100`; do printf "write /foo.%03d %d\n" $n $n; done @@ -863,7 +863,7 @@ Identify encrypted block devices and partitions using L</vfs-type>: crypto_LUKS Then open those devices using L</luks-open>. This creates a -device-mapper device called C</dev/mapper/luksdev>. +device-mapper device called F</dev/mapper/luksdev>. ><fs> luks-open /dev/sda2 luksdev Enter key or passphrase ("key"): <enter the passphrase> @@ -899,7 +899,7 @@ The parameter is rewritten "behind the scenes" by looking up the position where the...