Re: [Qemu-devel] How do you do when write more than 16TB data to qcow2 on ext4?

[Eric Blake]

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