On 9/20/24 2:54 PM, Jeff Rizzo wrote:


On 9/20/24 1:13 PM, Michael van Elst wrote:
r...@tastylime.net (Jeff Rizzo) writes:

...errno 22 is EINVAL, but I'm not familiar enough to know what I'm
hitting, here.  Or why the console seems one-way.  Thoughts?
EINVAL would be a typical error caused by a sector size mismatch.


That does sound like a likely candidate; now to figure out where that mismatch is occurring.  The ld0 attachment sees 512 bytes/sector in both VMs (the working and non-working ones) - and I assume (though will check momentarily) that the zvols should be identical (but possibly with larger blocks?) on the two systems (since I assume, probably wrongly, that zfs send/receive should coordinate that).

I wonder if this is a case where bhyve does some translation while qemu does not. hm.



OK, I can seemingly confirm it's a sector/block size issue; when I copy the zvol to a plain ("raw") file, it boots normally.

I tried zvols with volblocksize=512 and 4k (the original is 16k), but neither of those worked correctly either.  Given that it's using the raw device (/dev/zvol/rdsk/path/to/zvol), I would have expected things to work.  Anyone know if maybe there's a qemu setting which helps?   Here's what I'm currently using:

IMG=/dev/zvol/rdsk/tank/volumes/myzvol

qemu-system-x86_64 --accel nvmm -cpu max -smp cpus=2 -m 1G -object rng-random,filename=/dev/urandom,id=viornd0 -device virtio-rng-pci,rng=viornd0 -drive format=raw,file=${IMG} ,if=none,id=hd0 -device virtio-blk-pci,drive=hd0 -usb -device usb-mouse,bus=usb-bus.0 -vga vmware -nographic


...I'd love suggestions!

+j

--
Jeff Rizzo
r...@tastylime.net
+1 415 823 1847

Reply via email to