NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Boot VM from a zvol using qemu and nvmm?



riz%tastylime.net@localhost (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.




Home | Main Index | Thread Index | Old Index