Hyper Threading shown as Disabled in XO interface even though it's supported and enabled BIOS side.
Hyper Threading (STM) is shown as disabled on the Xen Orchestra Community Edition interface even though my processors ( Dual Xeon 5660) support STM ane have it enabled, CPU information not being gathered either.
Any idea why this is happening?
This is very old hardware. HT or not, the amount of compute power will be very limited, even a recent Celeron will perform better
@olivierlambert Not gonna stop me from trying haha
But true it's definitely old equipment..
/opt/xensource/libexec/xen-cmdline --set-xen smt=enable
@Andrew Still showing as disabled via XO after reboot.
@MrXeon You can use
xl dmesgto see if Xen reports any CPU issues.
@Andrew Gave that a shot and got the following error.
["xl dmesg" output from XCP-ng Host] Xencall: error: could nor obtain handle on privileged command interface: No such file or directory. Libxl: error: libel.c:libxl_ctx_alloc: cannot open libxc handle: no such file or directory. Cannot init xl context
@MrXeon Did you run that from the XCP-ng host console (Dom0)?
If so it looks like you may have a corrupt install... Or you are running the command from another VM?
@Andrew I'm running it directly on the local command shell, My XCP-ng disk image passed a signature verification and passed the media check during installation.
First install had a corrupted backup partition however (which I ended up deleting and repurposing out of inexperience thus this is my second fresh installation).
This time the backup partition wasn't corrupted.
What would you suggest I do?
@Andrew OH it's important to note that I've moved the boot directory over to a flash drive prior to first boot (changes applied to fstab)
The reason for this is because I've got a BIOS Based Server which doesnt support NVMe, however I wanted to boot from a NVMe or at least keep the Host and Guest Filesystems stored there, so moving the Boot directory (Grub and the Kernel) over to a flash drive seemed like the best work around since I wasn't able to get Clover or similar bootloaders with "UEFI emulation" support to boot on my system.
The original boot partition is still intact just being ignored, the original boot directory was renamed to boot_old for safe keeping and those files were copied over to a ext4 mbr based flash drive mounted to the new "boot" directory.
I don't think that should cause these problems, but just in case that caused something unpredictable I thought I would mention it.
@MrXeon Missing files looks like an install issue.... or migration/mounting problem of file systems.
You can always install and boot from a normal disk and use a NVMe device for guest storage. I have not used Clover to try booting a NVMe device from a BIOS only system.
@Andrew I'm not using Clover it didn't work for me, I simply moved the boot directory to a flashdrive after installing XCP-ng to my NVMe.
My Supermicro Server only has 3 sata drives per node, which I want to dedicate to my Software Raid/File Server which will be running as a VM (TrueNasCore) hopefully under XCP-ng.
Thus why I'm using my PCie 2.0 slot for NVMe, the only other option would be to use the 3 drive bays as a hardware raid 5 of some smaller sata SSD's and use that for my SR and Host, then repurposing the PCie 2.0 slot for some sorta controller or high speed nic to communicate with a separate NAS Box of sorts.
Least that's the only work around I've thought of, otherwise I would have to use USB 2.0 for the Host and Guest Systems which isn't very ideal.
@Andrew I just reinstalled for the third time.
Fresh downloaded ISO, passed signature check, flashed via dd on Arch Linux to a 3.1 USB Flash Drive fresh out of the package.
XCP-ng Installer Live Booted successfully and passed it's medium check.
Installed to my NVMe and then Booted into a Debian Based Live os (Sparky Linux) and moved my boot directory over to a flash drive and installed Grub to it's MBR...
Shutdown, powered back up, XCP-ng networking wasn't working so I did a emergency reset (This seems to happen every fresh install) and then did a "yum upgrade" before trying to run xl dmesg again.
Unfortunately it gave the same error
@Andrew Did some further testing as you suggested and your definitely bang on, it's a migration/mounting problem most likely caused by moving Grub and the Kernel to my Flash Drive.
When booting from a SATA SSD I've noticed some interesting changes which I've noted below.
XCP-ng loading screen.
ACPI Error during boot (could you help me troubleshoot this?)
Text is white and not bold with colorful font like the previous setup.
Configuration Screen has changed Resolution/aspect ratio, now it's 4:3 while before it was 16:9.
Networking works out of the gate.
Dual Xeons are detected
My first question is regarding the slight changes... why?
Do you have any suggestions on how I might be able to work around this? Are there any configuration files I can change to correct the mounts or am I stuck with having to reconfigure my drive setup?
The only other thing I can think of is to continue attempting to get Clover to boot, if I can do that I can keep everything on the NVMe but it's questionable if that's worth my time.
@MrXeon You have a one off setup with a problem, so I don't know exactly how to fix it. There are many ways of moving data and booting systems...
With a machine this old (I have an HP DL360 G5 for testing, so I do play with old stuff) it may not be worth doing too much to improve your setup. For testing stuff and leaning, it would be worth sticking with a more normal setup.
Keep BIOS boot and use the system boot drive (or two for mirror) to store the XCP host setup and the default storage repository (use EXT). Setup your fast NVMe for a second storage repository (use EXT also). Use the NVMe for guest storage and testing.
I would think that, at least to start, you would rather have a stable system so you can work with XCP and not fight it. If you want to use it for production systems then a newer server would work much better.
@Andrew That sounds like a reasonable plan, but won't TrueNasCore need complete access to all 3 sata drives at least in order to do software raid?
I don't think it'll like having a partial compacity of the drive.
Pretty certain I have to do sata pass-through.
@MrXeon I think so... I run TrueNAS as a stand alone machine not a VM so I don't know the details of what you need. If you are trying to run TrueNAS to provide storage for that XCP server then you can just run ZFS in DOM0 and setup a SR on it for VM storage.
Do you have room for a 4th hard disk? You could give XCP 1 drive and TrueNAS 3 drives. Maybe you could try Clover on a USB stick to boot your NVMe and leave the HDD alone. Once again, something I have not tried. I have used SATA M.2 on PCIe card for BIOS bootable M.2 SATA sticks in non-UEFI non-bootable-NVMe machines. They are not that much and allow internal use of SATA-3 M.2 flash sticks as additional drives.
I have the hardware to try it (non-uefi HP G8, internal USB flash drive, NVMe drive on PCIe card).... but not right now. I guess you need to use USB clover boot to start XCP install from ISO, install XCP on NVMe drive, then use USB clover boot to boot XCP from the NVMe drive.
@Andrew I'm planing to use the TrueNasCore Instance as a file host unrelated to my XCP-ng infrastructure, however I might consider using it as a ISO SR as well, otherwise using zfs on dom0 is a great idea, just isn't preferable for my use case.
Unfortunately I don't have access to a 4th sata drive, I've got 3 sata bays going to a raid controller/backplane, 2 USB 2.0 Ports, 1 USB 2.0 Header, and 1 PCie 2.0 Slot.
I didn't consider sata type b ssd's when planing the setup, now I kinda wish I did, I could switch gears if Clover doesn't work out. Do such cards provide power and data transfer through the PCie lane?
Regarding Clover, I've been experimenting with it for a bit before I tried moving the Boot directory to a Separate flash drive... When using the latest version and flashing it via Rufus on a separate Windows 10 Machine, I couldn't get the Clover key to boot on my target machine, it kept leaving me at a white blinking cursor which is usually a sign that I either incorrectly flashed it or it's corrupted in some way maybe even not compatible with my system.
This seems to be an issue with the latest versions of Clover when attempting to boot on Legacy BIOS systems acording to one Clover user.
So I attempted to use a much older version that supposedly works better on older systems, this time I actually reached a number 6 with a white blinking cursor, which is a sign that it's compatible however it never reached the Clover Menu which means I incorrectly flashed it.
I've been told that the recommended flashing utility is BDU "Boot Disk Utility" created to make Clover installations easier, however do be warned that many copies of BDU and other Clover Flashing utilities floating around the Internet unfortunately contain Malware, so it's best to attempt to find clean copies amongst popular bios modding community members.
I'm not sure if the initial developer intended for BDU to be malicious or if it just kinda became abandoned ware and malicious actors have taken it over, a good example being the AIO Boot Tutorial you shared, Who knows why but the creator actually infested their utility with Malware and once people complained they took it down silently.
I was able to get my hands on a working safe version of BDU from a forum user so I'm currently testing that, I've been told I'll have better luck if I flash it on the Target system itself, so I'm setting up a Windows 2 Go live bootable as I write this, So wish me Luck.
It would be nice to know if someone with a similar but slightly different setup runs into the same issues or not with Clover, so if you get the chance please do let me know how it works out for ya.
If I can't get Clover working then I think my best bet might be to start looking into those Type B Sata SSD Adapters you mentioned, could you recommend any particular one from experience?
@MrXeon I did get Clover v5150 to work. It's ugly to get setup from Windows (this helped). I got it to BIOS boot from USB and manually start the EFI XCP install process. From there it did a EFI install of XCP. I was able to reboot from the Clover USB drive and EFI boot XCP. It's not exactly your setup but it's a reasonable quick test. I still have to try using a PCIe NVMe card for storage.
The QNAP QM2-2S-220A and Ableconn PEXM2-122 support dual B-key M.2 SATA SSD sticks. It shows up to the system as a normal dual AHCI SATA-3 controller with the ASMedia ASM1062 chip (use only firmware 201105_00_76_00) on a PCIe 2.0 x2 connection. I have several of them but NVMe is much faster than SATA.
@Andrew wow you honestly got further then me and I've been trying for a while haha, way to go!
What utility did you use to flash the Clover image to your USB stick?
Here's my most recent Clover Attempt Story, I went through the trouble of running Windows on my target machine because a few forum users mentioned that it works best if you flash it on your target system, to be honest I'm not sure how that would really make a difference but I tried it anyway.
First off downloaded a Windows 10 Home ISO from Microsoft using a Browser with a spoofed User Agent, Flashed it to a Sata SSD via a USB 3.0 Encloser/Adapter in around 3 Minutes using the Freeware utility Win 2 Go, and finally connected that SSD to my Target Systems SATA Port.
That method allowed me to skip the Windows Media Creation Tool and The Windows 10 Installer, I was booting straight to Windows with a few basic system setup steps.
For anyone trying to reattempt that, I would suggest you try self customizing the Windows 10 ISO to not include all the extra bloatware and unnecessary setup features… it’ll save a little extra time. (However I didn’t end up doing that part)…
So after one blue screen of death… lets just say Windows got a little overwhelmed, I was able to Run the Boot Disk Utility and flash Clover to a USB key.
After ejecting the flash drive and waiting for Windows 10 to shutdown, I disconnected my SSD and Inserted the Clover Key… unfortunately it still Boots to a 6 with a Blinking White Cursor and stays there.
I'll add that I was trying to boot into a very old version of Clover v4961 using BDU (v2.1.2018.023b)... however I've tried just flashing the latest version via Rufus with similar end results.
Unless it's being picky about my system in particular I would guess you did something different that I'm missing during the early steps.