Installing HAOS in a VM on TrueNAS SCALE

Thanks @troy , I also thought it didn’t work as per the comments but unfortunately I’don’t see it neither in /dev/serial neither I passtrough.
Instead if I try to connect on my laptop I see it correctly. But maybe I need to check again somethings in bios or similar, because freeness is updated but nothing:

ls: /dev/serial: No such file or directory

freenas% ls /dev/serial/

ls: /dev/serial/: No such file or directory

Thanks again

1 Like

If you go to VM settings and try to add a USB device does it show up in the drop down list

(Screenshot is for reference, showing differant device)

thanks for reply @troy, nothing shown, I tried both with vm powered off that running but not appear in device list

It should show up as a USB pass through device… Not PCI pass through

If it doesn’t show up there either then I’m sorry I don’t think I can help at the moment. Maybe someone else can jump in with something to try.

Sorry I hadn’t noticed… but I don’t have the option for usb pass trough.
Thanks I undstrand an thanks for your support!!

This is fantastic! Thank you.

I have a question, why did you choose UTC for the “System clock” instead of the default Local? I am going forward with Local, but am curious if there is an advantage to UTC?

1 Like

Great question @BrianHanifin

When I first started using Linux, it is what was recommended. Basically, your computer needs to keep the both hardware (BIOS) and software (what the OS shows) times in sync. Linux systems typically prefer the hardware clock in UTC. This prevents the need to change it on daylight savings and timezone changes.

Here is a little copy/paste from the Arch Wiki

The localtime standard is dependent on the current time zone and possible Daylight Saving Time. UTC a global time standard and is independent of time zone values and DST.

The standard used by the hardware clock (CMOS clock, the BIOS time) is set by the operating system. By default, Windows uses localtime, macOS uses UTC, other UNIX and UNIX-like systems vary. An OS that uses the UTC standard will generally consider the hardware clock as UTC and make an adjustment to it to set the OS time at boot according to the time zone

If multiple operating systems are installed on a machine, they will all derive the current time from the same hardware clock: it is recommended to set it to UTC to avoid conflicts across systems. Otherwise, if the hardware clock is set to localtime , more than one operating system may adjust it after a DST change for example, thus resulting in an over-correction

1 Like

Is your TrueNAS server up to date @dinoc93?

USB passthrough is only available in TrueNAS SCALE Version 22.12 and later

1 Like

Thanks @troy i resolved thanks at your info, I didn’t used the Scale version, now working well!

1 Like

Anyone tried TrueNAS-SCALE-23.10-BETA.1? Not sure if its just me but CPU usage has been more erratic (and much higher power consumption!) since upgrade from 22.12.3.3. Before load was very even across all threads with lower temps. Only 2 VM’s & 1 App running and did shut down each one if any particular one was causing issue. But no particular one causing it. Any ideas? I have HA VM with 2xvCPU, 1xCore. 1xThread. Also tried the optional CPU set to ‘0-14’
image

You could try: 1x vCPU, 2x Core, 1x Thread - but I’d be surprised if that changes anything.

This is probably a better question to ask in the TrueNAS Forum (there’s a new section for Cobia)


EDIT

So I just tried SCALE-23.10-BETA.1 on my server @fireblade70 - I ended up reverting back to SCALE-22.12.3.1 because I was seeing a spike in CPU usage about every 20 seconds. A message EDID block 0 is all zeroes also appears in my TrueNAS console every 20 seconds.

Friendly side note: Those CPU temps seem pretty excessive in my opinion. Are you sure your server has adequate cooling?

Can somebody help me out i can’t seem to get past

'qemu-img convert -O raw haos_ova-10.4.qcow2 /dev/zvol/apps/HA

protocol driver ‘host_device’ does not support image creatin, and opeing the image failed: could not open ‘/dev/zvol/apps/HA’ : permission denied

It is it does have any rights to do so see picture. Can somebody tel me whats wrong with what i am doing?

Probably need to use sudo

sudo qemu-img convert -O raw haos_ova-10.4.qcow2 /dev/zvol/apps/HA

i tried that but then i get the screen which asks the admin pasword but i can’t enter it

It should be the same password as the user you have logged in with.

Sorry for the trouble. My server is still running with (and I made this guide using) the root account. I’ll look at updating this guide for the “admin” user once Cobia is released

thx for the tip it fixed my problem just logged into the root account for the config of HA

1 Like

Thank you for this.

Like others, I had been stuck in an eternal GRUB loop following the guide, but using /dev instead of /mnt fixed the issue straight.

You sir are a god send.

This info should be added to the initial fantastic instructions!

1 Like

This guide has never used the /mnt path, but I’ll add something to clarify that. Or at least add something about this to the troubleshooting information in the second post.

One more kudos for this one.

In addition I had to fight with my server’s BIOS too. If anyone has issues with a HP machine, here’s some hint fixing the BIOS to get the PCI passthrough work:
https://www.reddit.com/r/Hewlett_Packard/comments/syhpxv/no_vtd_in_bios_for_prodesk_600_g1_sff/

1 Like

I ran into the same issue and while you certainly solved the problem by now, others may run into it too: when you follow the guide to convert the qcow2 file, you are overriding an existing zvol. You then have to use that existing zvol during the VM creation and you DONT use any installation medium. The qcow2 you download is a VM disk image, not an installation image. My mistake was selecting the extracted image as an installation image and then I was stuck at the shell as in the screenshot.

1 Like