Other Rescan for new virtio disk devices

[AndyUKG]

Hi,

Is anyone aware of a way to get a virtual FreeBSD server to rescan for new disks when using the virtio disk driver? The virtual buses don't appear under camcontrol so I'm at a bit of a loss how to do this without rebooting the virtual server.

Thanks, Andy.

 

[Sebulon]

Hey AndyUKG!

Have you tried VirtIO-SCSI? Performance is the same as with virtio-blk and they show up just like a normal SCSI disk, hot-plug, hot-pull, etc.

/Sebulon

 

[AndyUKG]

Hi Sebulon,

Thanks a lot for the tip, I'll have to set[]up a test VM and give it a go. Unfortunately I'd have to convert all my existing VMs, guess its not the end of the world!

Thanks, Andy.

 

[Sebulon]

Hi Sebulon,

thanks a lot for the tip, I'll have to setup a test VM and give it a go. Unfortunately I'd have to convert all my existing VMs, guess its no the end of the world!

thanks, Andy.

Why would you have to convert them? FreeBSD has drivers for both virtio-blk and virtio-scsi so you'd only have to change the controller- and disk type and you'd be set. Found a really good article that very clearly explains the procedure: http://www.tokiwinter.com/adding-scsi-controller-scsi-disks-to-kvm-based-guests/

 

[AndyUKG]

Yeah, by convert them I meant, convert the disk type in the guest configuration on the Hypervisor, reboot each system and deal with any issues related to changed device names within the virtual machine. I have quite a lot of virtualised FreeBSD systems so it's a bit of a pain, in fact I can't see myself doing this for existing servers unless I'm taking them offline for some other reason. One for the future I think,

thanks, Andy.

 

[Sebulon]

Yeah, by convert them I meant, convert the disk type in the guest config on the hypervisor, reboot each system and deal with any issues related to changed device names within the virtual machine. I have quite a lot of virtualised FreeBSD systems so its a bit of a pain, in fact I can't see myself doing this for existing servers unless I'm taking them offline for some other reason. One for the future I think,

thanks, Andy.

So you're saying you haven't used labels when partitioning the drives, using those to mount, huh? Bites you in the ass now, doesn't it

/Sebulon

 

[AndyUKG]

I don't really trust labels on FreeBSD, between the various types there's too many weird things like overwrite last block or sector of where your data sits or GPT labels displaying under /dev one minute and not the next. If you include this issue, I've had one issue ever from using device paths so can't complain.

 

[wblock@]

I don't really trust labels on FreeBSD, between the various types there's too many weird things like overwrite last block or sector of where your data sits

Labels do not do this, although misunderstanding users sometimes do. If you use glabel(8) to create a label on a device, it takes the last block of that device for metadata, but that block is not made available to the user. Users sometimes continue to use the base device, which is wrong. For example:

# glabel label example /dev/ada0s1b

Now the user is expected to not write to /dev/ada0s1b any more, but to use the new label device, /dev/label/example. Compare the device sizes, and /dev/label/example is one block smaller than /dev/ada0s1b.

or GPT labels displaying under /dev one minute and not the next. If you include this issue, I've had one issue ever from using device paths so can't complain.

GPT labels and other labels will "wither" when their device is mounted. This is intentional--they are in use, so the labels are hidden.

Really, use GPT labels. The metadata is kept in the GPT, and it is nice to have disks keep working when drives are added or moved around.

 

[AndyUKG]

Ok, thanks for the info. Still seems odd to me designing special device files to disappear when the device is in use, but if its by design at least it can stop scaring me. I'll bear it in mind for future installations....

thanks, Andy.

 

[phoenix]

It's by design. You have multiple ways to access a device; but only one method can be active (mounted/accessed) at a time.

How best to prevent users from trying to access the same device via multiple pathways simultaneously? Make the rest inaccessible while one is in use.

The only time you might run into issues is when using the auto-generated GPTID (/dev/gptid/*) or UFSID (/dev/ufsid/*), as these appear to sometimes take priority over the other access methods, especially when it comes to ZFS. Disabling these in /boot/loader.conf makes things much more stable.

 

[wblock@]

Another way to look at it: when a device is write-locked by a filesystem, other aliases to that device are "withered" because they do not (or should not) have write access to the base device at the same time.