@olivierlambert thanks for confirming!

Thanks for your feedback @loopway ! Happy to make your home lab running

@bigdweeb Yes.

We just released XCP-ng 8.3 beta 1 ! I opened a new thread for us to discuss it and for you to provide feedback: https://xcp-ng.org/forum/topic/7464/xcp-ng-8-3-beta Thanks for all the feedback already provided here, and see you on this new thread! In order not to miss anything (and, let's be honest, for me to be sure that messages on the new thread reach you all), the best course of action is: open the new thread right now and use the "watch" button. [image: 1687457779384-53fac025-6e0c-465b-97ab-5ca73a97bd93-image.png] And let's answer this common and legitimate question: how to upgrade from alpha to beta ? Well, there's nothing to do, just update as usual. In fact, you might already be in beta state. However, as indicated in the blog post, we need a lot of testing of the installer, so it's also an option to start from the installation ISO again.

@KPS Hi. This thread is now inactive sop please open a new thread dedicated to your issue.

@stormi Nope.... my mistake. Now ubuntu 20.04 and Windows 2016 boot with UEFI Secure Boot enabled. # secureboot-certs install No arguments provided to command install, default arguments will be used: - PK: default - KEK: default - db: default - dbx: latest Downloading https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt... Downloading https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt... Downloading https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt... Downloading https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin... Successfully installed certificates to the XAPI DB for pool.

@andrew Yes indeed, those are known shortcomings: The installer does not wipe previous RAID setups. It does not offer to create another RAID for data storage. There's an extensive guide about this at https://xcp-ng.org/docs/guides.html#software-raid-storage-repository

@Pierre-Briec , @stormi I had a look at getting the xe-guest-utilities working on Ipfire v2 now (core 173, the latest version). Using a new /usr/sbin/xe-linux-distribution script, like suggested here, allows it to detect the ipfire. I then manually copied the binaries and scripts from the linux tar file, into the folders in Ipfire, since the install script did not seem to handle Ipfire properly. When starting the daemon using /etc/init.d/xe-linux-distribution, the next problem was that the "action" function does not exist in the /etc/init.d/functions file in Ipfire. So I just edited the script, replacing the "else" with an "fi" in the if testing where the functions file is sources, so that the locally defined action method is used. Then the agent started fine. Then I also saw the issue of the IP address not being reported. In my setup, there are two reasons for this. One is that Ipfire uses "red0", "green0", "blue0" etc as interface names, which the xe-guest-utilities will not consider. The other reason is that I do PCI passthrough of 3 network cards to the Ipfire, and hence does not use the "vif" interface/network that XCP-ng makes available to the Ipfire. Althought the "green0" is really on the same network as the "vif" in my setup. This was using the 7.30 tar file from the XCP ISO, I think. I then cloned the 7.33 / master version of xe-guest-utilities from github, and used that thereafter. I manually changed and built the xe-guest-utilities, adding "red", "green", "blue" to the list of interface prefixes that got considered, but it did not help. I suspect the reason is that these interfaces does not have a /sys/class/net/eth0/device/nodename entry, which contains a reference to the "vif" that XCP-ng knows about, as I understand it. So /sys/class/net/eth0/device/nodename exists, but the eth0 is not assigned any IP address, since it is not used by IPfire. While there is no /sys/class/net/green0/device/nodename entry. I am not sure who is "creating" this "nodename" entry, but I suspect is it Xen. And I suspect it is missing, since the green0 interface has no relationsship with the dom0 really. But then I also got more questions around what is actually meant to be displayed of "network" info in the XOA web UI. Is it only the network between dom0 and domU ? Or ideally all networks defined on domU ? (i.e. red0 and blue0 and orange0 ) ? And I also think I spotted a bug on the "Stats" page of XOA, since under "Disk throughput", it seems like always "xvda" and "xvdd" is displayed, even if the host only has one disk, "xvda". But that I should report as a bug, if I do not find it as already reported / known. While playing with this, I also noticed that the management agent version was not properly displayed, i.e. not at all. And this seems to be caused by the the version constants not being replaced while building the daemon. I am not a go build expert, so I'll investigate it a bit more. But it seems like I'm not the only one with that issue, because the same problem seems to exist with the xe-guest-utilities that are part of Alpine Linux 3.17 distribution. I do not think that there are that many running Ipfire on XCP-ng/Xen. I've been briefly involved in some pull requests against Ipfire, so I might look at making one for getting the xe-guest-utilities into Ipfire itself, but since the use is not high, I have a doubt it makes much sense. Thanks for a great tool in XCP-ng, I enjoy using it in my home setup. Regards Alf Høgemark

The update is now available for everyone https://xcp-ng.org/blog/2021/01/28/security-issue-in-sudo/

Great news! Thanks for the feedback

Initial brief test seems ok Will see if i can do more of the tests later... Updated from 8.1 via yum which caused windows 10 & windows 2019 server to hang on the tiano logo. Interestingly a debian 10 uefi vm worked fine... After the update to uefistored both windows VMs started in recovery and did whatever it is windows does besides spin dots on your screen After a reboot both Windows 10 2004 and windows 2019 server booted just fine

@hoerup Hi, I can't remember too much to be honest. I created a Debian 10 VM with 20GB disk, set up all the stuff that needed to be common for the Ceph pool pretty much following the Ceph documentation using the cephadm method - so Docker etc. This would be my 'Ceph admin VM' Once that was all sorted I cloned the VM 3 times, for my actual Ceph pool and changed the hostname and static IP etc. I've got 3 hosts with Supermicro boards that have two SATA controllers on board, so on each one I passed though one of the controllers to the Ceph VM and then just deployed Ceph and followed the documentation. The only issues I ran into and any other tips are in the other post I linked to. Now Ceph is all containerised it all seams a bit too easy! Hope they're not my famous last words!! It does like a lot of RAM, so I've reduced the OSD limits down a bit and its fine for me. Cheers.

@stormi said in Looking for a temporary test host with a nVIDIA GPU: For the tests we had a need for 1 week ago, it's now fine, however I'll probably update this thread once we have an ISO image that can be tested by users that have such hardware. Note: it's not about using the GPU itself, but simply about making sure that the hypervisor works well with the changes we made to replace the not-built-by-us gpumon tool whose absence would make XCP-ng 8.1 unbootable (as we sadly found out after the release) with a dummy one built by us. Now is time for the tests I was talking about earlier. XCP-ng 8.2 beta is now available with our dummy gpumon and we need users who have nVIDIA GPUs to test it and give us feedback. There may be situations we have not tested where our dummy gpumon is not enough to make the XAPI happy, despite the fact that we don't support nVIDIA vGPUs (proprietary software from Citrix required for that feature).

@stormi Exactly. Must've been related to something other than just the latest packages.

I'm not sure Unitrends is supporting XCP-ng. Please refer to your backup vendor. Current backup solutions claming to support XCP-ng: https://xcp-ng.org/docs/backup.html