If you try to use a raw disk with virtio-blk for a Bhyve guest you will
not be able to install the OS. grehan@ suggests this is because the
host's GEOM subsystem detects the alterations occurring within the guest.
Apparently this may also be a problem for volumes exported as iSCSI LUNs.
It would appear GEOM needs a generic way to disconnect/connect parts of
the topology from the usual tasting procedure.
I have a PoC patch that is semi-functional: it enables the installation
to complete and the guest to boot, but there are still some problems that
I need to investigate further. The patch adds a connect and disconnect
verb to the disk class, accessible via the geom utility. Using disconnect
sets a DISCONNECTED flag and removes all but the DEV consumer from the
device. The connect command removes the flag. If I can tidy it up I will
attach it to this PR. I have requested some guidance on this connect/
disconnect interface to geom@ but had no feedback as yet.
How-To-Repeat: Use vmrun.sh and specify a /dev/adaN device or similar instead of a file.
I've seen a similar issue with ZFS zvol's, which was solved by adding a 'dev' mode that doesn't get picked up by GEOM. Might be worth looking at how it is done in the freebsd bits for ZFS.
the sysctl is: vfs.zfs.vol.mode
and the ZFS property is volmode
Also appears to affect sharing a whole disk with gpt partition as an iSCSI export. My use case was an experiment with importing a ZFS pool where the disks had been shared from another box (both FreeNAS) over iSCSI.
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Can anyone affected report what actual problems they see?