Your message dated Sun, 3 Oct 2021 21:33:17 +0300 with message-id <6cbd6152-7952-4336-0a87-416467d3a...@msgid.tls.msk.ru> and subject line Re: Bug#993688: 'file' driver requires '/dev/mapper/<cryptodevice>' to be a regular file has caused the Debian Bug report #993688, regarding 'file' driver requires '/dev/mapper/<cryptodevice>' to be a regular file to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 993688: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993688 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: qemu-system-x86 Version: 1:6.1+dfsg-4 Severity: normal Hi, this is a regression from qemu in bullseye to qemu in sid. I am using a VM with a block device that is a crypted LV. It gets unlocked by sudo cryptsetup --type=luks open /dev/mapper/drop-c_lv cryptodevice, resulting in /dev/mapper/cryptodevice being a symlink to /dev/dm-something with something being a different number every time. The corresponding XML is <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/mapper/cryptodevice'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x> </disk> With qemu 6.1, this VM doesn't start any more: [9/5183]mh@drop:~ $ virsh start myvm error: Failed to start domain 'myvm' error: internal error: process exited while connecting to monitor: 2021-09-04T19:05:45.464658Z kvm: -blockdev {"driver":"file","filename":"/dev/mapper/cryptodevice","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}: 'file' driver requires '/dev/mapper/cryptodevice' to be a regular file This XML gets generated by virt-manager in current sid. Going back to qemu 5.2 from Debian bullseye fixes the issue. This is possibly a compatibility issue between qemu, libvirt and virt-manager. I am not in a position to debug this in any detail, but I think that there should be some versioned dependencies. Using a crypted LV as raw block device is a rather common setup for me. How can I continue doing this? Greetings Marc -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.1-zgws1 (SMP w/4 CPU threads) Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 ii libaio1 0.3.112-9 ii libasound2 1.2.5.1-1 ii libbrlapi0.8 6.3+dfsg-3 ii libc6 2.31-17 ii libcacard0 1:2.8.0-3 ii libcapstone4 4.0.2-3 ii libepoxy0 1.5.8-1 ii libfdt1 1.6.0-1 ii libgbm1 21.2.1-2 ii libgcc-s1 11.2.0-4 ii libglib2.0-0 2.68.4-1 ii libgnutls30 3.7.2-2 ii libibverbs1 33.2-1 ii libjpeg62-turbo 1:2.0.6-4 ii libncursesw6 6.2+20201114-4 ii libnettle8 3.7.3-1 ii libnuma1 2.0.12-1+b1 ii libpixman-1-0 0.40.0-1 ii libpmem1 1.11.0-2 ii libpng16-16 1.6.37-3 ii librdmacm1 33.2-1 ii libsasl2-2 2.1.27+dfsg-2.1 ii libseccomp2 2.5.1-1 ii libslirp0 4.6.1-1 ii libspice-server1 0.14.3-2.1 ii libtinfo6 6.2+20201114-4 ii libudev1 247.9-1 ii liburing1 0.7-3 ii libusb-1.0-0 2:1.0.24-3 ii libusbredirparser1 0.11.0-2 ii libvdeplug2 4.0.1-2 ii libvirglrenderer1 0.8.2-5 ii libxendevicemodel1 4.14.2+25-gb6a8c4f72d-2 ii libxenevtchn1 4.14.2+25-gb6a8c4f72d-2 ii libxenforeignmemory1 4.14.2+25-gb6a8c4f72d-2 ii libxengnttab1 4.14.2+25-gb6a8c4f72d-2 ii libxenmisc4.14 4.14.2+25-gb6a8c4f72d-2 ii libxenstore3.0 4.14.2+25-gb6a8c4f72d-2 ii libxentoolcore1 4.14.2+25-gb6a8c4f72d-2 ii qemu-system-common 1:5.2+dfsg-11 ii qemu-system-data 1:5.2+dfsg-11 ii seabios 1.14.0-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages qemu-system-x86 recommends: ii ovmf 2020.11-5 ii qemu-system-gui 1:5.2+dfsg-11 ii qemu-utils 1:5.2+dfsg-11 Versions of packages qemu-system-x86 suggests: ii qemu-block-extra 1:5.2+dfsg-11 ii qemu-system-data [sgabios] 1:5.2+dfsg-11 pn samba <none> pn vde2 <none> -- no debconf information
--- End Message ---
--- Begin Message ---Ok. After seeing what it is all about, I'm closing this bugreport. libvirt has the necessary code for a long time now. When you want to use a host device, please specify the corresponding setting in the libvirt config for this. If you insist on using `file' driver, this is exactly what you get. One can argue (as I did) that in unix, everything's a file and we should not distinguish between a regular file and a block device. But there are multiple things which can be done with a block device which can't be done with a regular file. For example, direct-access async-io can be done only with a block device. Yes, in theory qemu can be a bit more user-friendly and try to enable those features which are appropriate for the given "type" of file. But things will quickly become complicated when you consider what to do with e.g. migration. Probably libvirt can be more user-friendly and at least give a warning in a situation like this. But this is a different story. Either way, please specify the proper driver in libvirt configuration. Thanks, /mjt
--- End Message ---
