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.
Responsible Changed From-To: freebsd-amd64->freebsd-bugs reclassify
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.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: 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?