r...@tastylime.net (Jeff Rizzo) writes:
>data over is to zfs send the zvol. However, a naive setting of
>-drive file=/dev/zvol/rdsk/tank/volumes/my-zvol
>in place of what (on my other VMs) is
>-drive file=/tank/volumes/my-disk.qcow2
>Doesn't seem to work, or at least qemu doesn't recognize it as having a
>bootable image.
>Should this work?
On NetBSD it does not.
The zvol:
NAME USED AVAIL REFER MOUNTPOINT
tank 4.13G 1.87T 88K /tank
tank/testvol 4.13G 1.88T 56K -
How qemu sees it:
d1 (#block386): /dev/zvol/rdsk/tank/testvol (raw)
Attached to: /machine/peripheral-anon/device[2]/virtio-backend
Cache mode: writeback
Images:
image: /dev/zvol/rdsk/tank/testvol
file format: raw
virtual size: 512 MiB (536870912 bytes)
disk size: 0 B
How the guest sees it:
[ 1.0259062] ld1: 512 MB, 1040 cyl, 16 head, 63 sec, 512 bytes/sect x 1048576
sectors
qemu has NetBSD support in upstream that uses DIOCGWEGEINFO and that
returns:
% dkctl /dev/zvol/rdsk/tank/testvol getwedgeinfo
tank/testvol at ZFS:
tank/testvol: 1048576 blocks at 0, type: ffs
Our zvol code uses:
dkw->dkw_size = dg->dg_secperunit;
where this is derived from:
dg->dg_secsize = secsize;
dg->dg_secperunit = volsize / secsize;
with
secsize = MAX(DEV_BSIZE, 1U << spa->spa_max_ashift);
and volsize being the size of the disk in bytes.
So ZFS and NetBSD think that the volume has 1M blocks of 4k size
but qemu:
static int64_t raw_getlength(BlockDriverState *bs)
...
if (ioctl(fd, DIOCGWEDGEINFO, &dkw) != -1) {
return dkw.dkw_size * 512;
assumes that a wedge always reports size in 512 byte sectors
and miscalculates the volume size.
