How to add raw block dev to Linux VM in FreeNAS 12?

[ad31677]

Hi, Folks

I am a FreeNAS newbie here, with a background in Solaris and Linux. I have moved to trying FreeNAS/TrueNAS after getting fed-up/bored doing everything manually on Ubuntu server installations. Overall, I very much like the GUI.

I am trying to add one of my WD RED NAS disks directly to a Linux VM. My old Intel SH3210SHLX board died and left me with no choice but to get the resurrect the server (albeit temporarily) on my TrueNAS installation as a VM while I finalise the storage configuration in the native OS.

Installing a VM with Ubuntu 20 has been fine. But, I was hoping to directly add /dev/ada0 to my Linux VM. I cannot do this in the GUI but I can at least do this manually in virsh by editing the XML directly. But doing it that way, the changes don't survive a reboot.

Is there some way to commit the changes to the configuration database? Or is there some ZFS trick to make the whole device into a ZVol?

Thanks in advance.
Aidan
--
TrueNAS 12.0-RELEASE
CPU: Intel Xeon E-2226G, 32GB RAM
MB: Something by Asus or Gigabyte. Can't remember right now. But C206 chipset.
Storage: 1x SamSung EVO 860 PLUS M.2, 2x WD RED NAS 3TB, 1x WD RED NAS 2TB.
Net: 1x HP NC550SFP, 1x Intel 4-port 1GB Ethernet, 2x on-board 1GB Ethernet

 

[artlessknave]

only GUI settings reliably survive reboots and updates. only changes from the GUI are in the database, by design, really
.bhyve itself is still relatively immature, truenas GUI for it is still relatively immature, and you are attempting an edge case.

if you must do this, you should be able to keep a copy of the modified xml in /root (which survives) and use a cron task to replace the existing one on startup. obviously you would want to sort out a GUI approved GUI ASAP, but that's one way I can think to make your workaround at least survive reboot, though if you make changes those wouldnt survive. you could though probably make a cron task to backup the xml too.
the only solutions to this problem really available to you are going to be hacks. truenas is a NAS with some VM capability, and that capability is very limited.

 

[ad31677]

only GUI settings reliably survive reboots and updates. only changes from the GUI are in the database, by design, really
.bhyve itself is still relatively immature, truenas GUI for it is still relatively immature, and you are attempting an edge case.

if you must do this, you should be able to keep a copy of the modified xml in /root (which survives) and use a cron task to replace the existing one on startup. obviously you would want to sort out a GUI approved GUI ASAP, but that's one way I can think to make your workaround at least survive reboot, though if you make changes those wouldnt survive. you could though probably make a cron task to backup the xml too.
the only solutions to this problem really available to you are going to be hacks. truenas is a NAS with some VM capability, and that capability is very limited.

I had a feeling this was the case, trying to read a bit more into it. It would be useful to be able to do this officially, although I dare say it would take a bit of work behind the scenes for the GUI to allow this without also allowing people to accidentally do something dangerous (unrecoverably so).

I will automate with cron as you suggest. Hopefully once I've sorted out separate problems I'm having sharing with SMB, the Linux VM can be removed.

Thanks.
Aidan

 

[artlessknave]

I would be curious of the results, whether that cron idea actually works or not.

GUI to allow this

Ideally the GUI would allow everything, but that's unreasonable, so they try and get the most likely used things, and everything else gets ignored. even you say you only need it temporarily, so yea.