On Mon Apr 25, 2022 at 5:09 AM CDT, Bob Power wrote: > Hi, > The man page for qemu-nbd reads: qemu−nbd − QEMU Disk Network Block Device > Server > I'm accessing a qcow2 image on a host using: qemu-nbd -c /dev/nbd0 test.qcow2 > > It appears that when used this way qemu-nbd does not operate as a server ... > > While the fs on the image is mounted and in use : > > ]# nmap -p 10809 localhost > 10809/tcp closed nbd > > ]# systemctl list-units --type=service | grep nbd > ]# > So is it the case that when used in this manner it does not and is not > intended to act as a server ?
The manual also says this about the -c switch you're using: Expose the guest-visible contents of a qcow2 file via a block device /dev/nbd0 (and possibly creating /dev/nbd0p1 and friends for partitions found within), then disconnect the device when done. Access to bind qemu-nbd to a /dev/nbd device generally requires root privileges, and may also require the execution of modprobe nbd to enable the kernel NBD client module. CAUTION: Do not use this method to mount filesystems from an untrusted guest image - a malicious guest may have prepared the image to attempt to trigger kernel bugs in partition probing or file system mounting. qemu-nbd -c /dev/nbd0 -f qcow2 file.qcow2 qemu-nbd -d /dev/nbd0 Are you able to interact with the image with /dev/nbd0*? If so, I wonder if what's happening here is that your host kernel is the client and the qemu-nbd server process is just exiting when its client hangs up. That's qemu-nbd's default behavior, unless you also supply the -p or --persistent switch. I'm just guessing here. I haven't used qemu-nbd with the -c switch before. -- Connor