Bug 183401

Summary:	[bhyve] bhyve virtio-blk cannot be a raw disc device; bad GEOM interaction
Product:	Base System	Reporter:	symbolics <symbolics>
Component:	kern	Assignee:	freebsd-virtualization (Nobody) <virtualization>
Status:	Closed Feedback Timeout
Severity:	Affects Only Me	CC:	allanjude, eugene.kiev, freebsd, geom, harry.weppner, petercjclifton
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description symbolics@gmx.com 2013-10-28 15:30:00 UTC

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.

Comment 1 Mark Linimon freebsd_committer

2013-11-18 06:24:25 UTC

Responsible Changed
From-To: freebsd-amd64->freebsd-bugs

reclassify

Comment 2 Allan Jude freebsd_committer

2015-03-20 03:08:39 UTC

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

Comment 3 Peter Clifton 2017-10-05 16:10:47 UTC

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.

Comment 4 Eitan Adler freebsd_committer

2018-05-28 19:46:58 UTC

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.

Comment 5 Andriy Gapon freebsd_committer

2018-05-29 09:28:16 UTC

Can anyone affected report what actual problems they see?