On 08/17/2018 03:05 AM, lampahome wrote:
Really? How to mount a blk device to /dev/nbdN?
I always find tips to mount from file-like image to /dev/nbdN
Please don't top-post on technical lists, it makes the conversation
harder to follow.
I'm not sure how your question about /dev/nbdN relates to your setup of
trying to produce a large guest image. You can export ANYTHING that qemu
can recognize to /dev/nbdN, via:
qemu-nbd -c /dev/nbd$n $image_that_qemu_recognizes
This is true for raw images:
qemu-nbd -c /dev/nbd$n -f raw /path/to/file
for block devices such as LVM storing qcow2 format:
qemu-nbd -c /dev/nbd$n -f qcow2 /dev/mapper/vg_$whatever
for remote access to another NBD server:
qemu-nbd -c /dev/nbd$n -f raw nbd://remote:10809/export
again, but this time with only a 1M subset exported:
qemu-nbd -c /dev/nbd$n --image-opts
driver=raw,offset=1M,size=1M,file.driver=nbd,\
file.server.type=inet,file.server.host=remote,\
file.server.port=10809,file.export=export
and so on.
Basically, if qemu can access storage, it can also export that storage
as NBD, and you can then hook up the kernel's NBD client to expose that
storage as a local block device for inspecting what the guest image
contains (word of caution: don't mount untrusted guest images in this
manner, as the guest could have planted a malicious file system bug that
will crash the host. Instead, use libguestfs for mounting guest images
in a safe VM environment where at most you crash the VM instead of the
host). And there's no requirement that you have to involve the kernel
via /dev/nbdN - you can instead access NBD servers via userspace
(qemu-img is one such userspace client, and Nir Soffer recently posted
to this list about a client being written in python).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
