Change hypervisor to truenas scale?

[ThisTruenasUser]

Hi
I am using proxmox, with truenas as a virtual machine.

So I am maybe looking to use truenas scale as hypervisor instead.

I have questions:

GPU passtthought to a virtual machine. It is possible, but can it be done in a machine with a single GPU?
There is no room for another, or space on the motherboard, or free slots.
Pass through a single USB port to a virtual machine?
Is this possible?
Hardware passthrough apparently on the motherboard on works with only components connected directly to the CPU.
Anything through the motherboard is a no, so passing through a USB controller is not an option.

Backup up & restoring a virtual machine. Is there an option for this?
Maybe an option to upload & download an image to a zvol?
I am not talking about snapshots, but saving the data elsewhere & restoring from elsewhere, ideally over the GUI.

Useful info appreciated.

 

[morganL]

PCIe/GPU and USB Passthru described here:

Adding and Managing VM Devices

Provides instructions on adding or managing devices used by VMs.

www.truenas.com

Uploading an image is how a VM is created.. please review the docs

For backup, ZFS replication is preferred... its non-disruptive

 

[Basserra]

Personally, I highly suggest against using TrueNAS_Scale as a primary hypervisor. Trunas_Core/Scale is a NAS server first just like a SynologyNAS. While you can freely use VMs on Synology/Unraid/TrueNAS, it is only a secondary feature. A real hypervisor would be like ESXi/XCP-ng/Hyper-V/Proxmox. BUT! It really does depend on what you intend to do with your host/VMs, as you could run all VMs under Win10 as some people do.

(1) GPU Passthrough: (If you mean you only have a dGPU and no iGPU) In theory yes, you could run one GPU and pass it thru. But, like any other distro, it would REQUIRE hacking the OS to make the host pass it off/back nicely, and it would not survive updates/upgrades on TrueNAS. You might want to try this on a baremetal testbench first to better understand it; there are some ArchLinux tuts in the wild on this topic.
(2) USB Passthrough: Yes! USB passthru is finally added as a functional feature in TN_Scale. I have had no problem using a keyboard/mouse dongle passthru, though I don't know if you can live trade it off, I only needed it for diagnostics and was shutting down the VMs but not the host. Proxmox allows you to passthru through a 'port' that might allow you to live swap the USB device, but in TNScale you passthru the USB device-id only, so not 'port' passthru. But if you intend on keeping the USB(s) tied to the VM forever, you should consider PCI_passthru a USB controller. (like an add-in card or mobo upgrade)
(3) Not sure what you mean exactly about "Hardware passthrough apparently on the motherboard on works with only components connected directly to the CPU." Sounds like IOMMU grouping issue with the mobo's PCH to me (use lspci -v to see IOMMU groups), if you can't separate the groups in Proxmox you almost definitely can't with another OS as it's a hardware issue. (look into acs_override otherwise you're SOL with the mobo like my desktop's one. Unraid has a web_UI option for this you could try before hand)
(4-1) Backups: There is no system for 'managed' backups, the best we get is automated ZFS snapshots (which are great and have saved two of my VMs), but they may not play nicely with certain applications that use lock files, keep files open, or write constantly like databases (I don't have experience with this).
(4-2) VM Transfer: Again, there is no managed system for this. But, you can. The procedure would entail: Shutdown VM, snapshot zvol, send/recv zvol snapshot, recreate new VM with new zvol. If you are talking about converting, yes. I haven't converted a disk myself, but some people report that dd to a zvol does the job fine. More CLI work involved.

 

[ThisTruenasUser]

Thank you for the replies.
It would for hardware GPU passthrough, but sadly not an option here.
It is a 3600X with B450 tomahawk motherboard + 64GB memory.
Maybe at some point, a second hand APU could be the solution.

As for backups, windows is apparently much easier than linux.
I have macrium reflect free version.
You can create a bootable recovery ISO.
Boot from it, then save/restore to/from a network drive.
I can only get it to work with a public share though.

Linux it seems dd is he only option.

I am glad USB passthrough is an option.

Oh and an Edit:

I think macrium reflect can also 'work' with linux.
After using it to install on the virtual, attach & use the linux boot repair disk which fixes the grub setup.

Here are the links which may be useful:

Create a Boot Repair Live USB disk drive in Linux

Boot-Repair utility is a free & open-source utility that lets you fix and recover the GRUB bootloader. It can reinstate those lost operating systems for you. Earlier, we published a detailed post on the utility and how to install it on Ubuntu, Linux Mint, and elementary OS. Now, we shall see…

www.fosslinux.com

I am unsire if macrium reflect is still free, so will be keeping the boot ISO.

For virtual machines with freebsd based system, have little idea. I guess DD is the safe option.
In my case, my opnsense router is in another machine, a VM inside proxmox.

 

[jgreco]

For virtual machines with freebsd based system, have little idea. I guess DD is the safe option.

dd is not atomic and is therefore not safe on its own.

When you open an object and start reading it with dd, you get atomic reads at whatever the block size (bs=) option is, typically something like 1MB. With a running VM, you often find that the contents are changing as you go, so your first 1MB block was from ten seconds ago, while your next one is from five seconds ago and the third one is from "now", while the fourth one will reflect what will be on disk five seconds into the future. This leads to inconsistencies.

Using something like ZFS snapshotting results in a snapshot that does not have these particular inconsistencies (can still have some others) and so what is recommended is to snapshot your VM and then either just retain the snapshot, replicate it, or dd the snapshot image -- all of which result in a much better copy.

For best luck, you really need to quiesce the VM, which may include asking things such as database servers (etc) to sync their contents out to disk before allowing the VM snapshot to proceed. Or just shut down the VM prior to backup, which has a similar effect on disk image consistency but is inconvenient in other ways.