Hello dear RC testers! We are releasing 7.5.0 final today, so here's how to go from 7.5.0RC to 7.5.0. Warning: this is only for people who installed the RC. Detailed procedure will be given in the release announcement for upgrading an XCP-ng 7.4 server Option 1, upgrade using the installation ISO Will work, although may be a little overkill since you already have a nearly-final 7.5.0. Option 2, update yum repository files and update the system # remove the RC-specific repository file if present rm /etc/yum.repos.d/xcp-ng-7.5.repo -f # install the 7.5 official repository file wget https://updates.xcp-ng.org/7/xcp-ng-7.5.repo -O /etc/yum.repos.d/xcp-ng.repo # update. If you had updated your RC regularly, this will install nothing, else you'll get a few packages yum update # if the kernel or xen-* packages got updated, reboot your server # that's it, you've got 7.5.0 final!

@maxcuttins There are two packages. User level blktap driver that you referred blktap and a builtin kernel driver blktap2. Said patch is against mainline kernel as additional driver. You still need to have user land blktap from https://github.com/xapi-project/blktap There are instructions lying around https://xcp-ng.org/forum/topic/122/how-to-build-blktap-from-sources/ to build user land blktap (its without patch).

@olivierlambert Okej, its that part that's tricky Yea maybe so, but it's cool. And makes the uptime better even if it's just a lab. I've been using vmware for a while at my last work. But the licensing is not nice for a homelab. So this is my first time with xcp-ng (xenserver). I'll try updating tomorrow. Thanks.

First off, thanks to @Aimdev and @fjen for providing a good write up of the steps taken to get USB passthrough to work. I followed them all pretty much with out any difficulty and with no errors on anything for a Broadcom Bluetooth USB card (Broadcom Corp._BCM2045B) that's built into my laptop I'd like to pass through to a Linux VM. And I get all the way up to where the USB device is correctly presented in the XCP-ng Centre application, but the device doesn't [seem to] appear at the OS level in dmesg | grep usbcore or lusb outputs in my guest OS VM. However, since I didn't any failure to start the vm or other errors, I had not executed the final command: xe vm-param-set uuid=<VM UUID> platform:device-model=qemu-upstream-compat But since the Broadcom chip still didn't appear in the guest Linux VM, I shutdown the VM and then executed the above command with the VM UUID. But after a restart, the VM still doesn't see the Broadcom USB device. Any idea what could be up or suggestions where I need to dig?

If someone fails to build, maybe the git-lfs in not properly initialised. To fetch the lfs-files after git clone you can do a git lfs fetch. weird ... after the second time installing git-lfs and again cloning the repo, it worked...

Okay good to know I had the hope that a serial console would be enough. I'll take a look if I can have any luck.

I'm not sure to understand your question. What do you mean?

7.5 release candidate released: https://xcp-ng.org/forum/topic/241/xcp-ng-7-5-0-release-candidate

@r1 Quick note to say thanks for your earlier input but don't worry about this. We've abandoned trying to get the Broadcom 57800 cards to run under XCP-NG or Xen 7.5; replaced them with Dell Intel i350&X540 Quad Port cards. As a quick recap for anyone else with this issue, we had a set of 3 Dell R630 servers fitted with Dell's Qlogic/Broadcom 57800 based quad-port daughter network cards (2 x 10GBe RJ45's with 2 x 1GBe RJ45s). Hardware is rev 10 apparently and they identify within the OS as Ethernet controller: Broadcom Limited NetXtreme II BCM57800 1/10 Gigabit Ethernet (rev 10) filename: /lib/modules/4.4.0+2/updates/bnx2x.ko version: 1.714.1 Under Xen 7.1 and earlier these ran perfectly, using the BNX2X driver v 1.714.1 along with the latest firmware from Dell. Oddly most of the reported issues seem to concern this version ? The Broadcom/QLogic 57800 doesn't seem to be on Citrix's HCL any longer for newer releases so presumably someone's decided that the year old NICs are now obsolete? Attempting to upgrade to Xen 7.2 or indeed XCP-NG 7.5 resulted in installation of a newer BNX2X driver (1.714.6 if memory serves), which for whatever reason was unable to bring the 10GBe links up or detect connected cables. We attempted to update the driver further using the appropriate Citrix driver disks along with attempting firmware rollbacks to see if that was the problem. I had been hoping to try a fresh build of the driver as above, but have neither the build environment nor knowledge to do that! After burning through 3-4 days troubleshooting this, we've given up on the Broadcom cards and bought replacement Intel NICs - Dell i350&X540 quad port daughter cards, again offering 2 x 10GBe & 2 x 1GBe RJ45 ports. Swapped the cards over, booted the machines and upgraded successfully to XCP-NG on first attempt. Zero hassle; zero issues. I can only assume there's a fix to be had somewhere but we've not got the time to keep experimenting in the hope something eventually results in a previously working system resuming working! If it helps anyone else, we bought the Intel cards from here: https://www.etb-tech.com/dell-intel-i350-x540-1-10gb-rj-45-sfp-quad-port-rndc-98493.html#.W5Dt5-hKi70

@alphastarr128 glad I could help. @olivierlambert @stormi Looking forward to it! Cheers.

PVH mode is not support yet in XenServer/XCP-ng anyway. It's like a HVM but lighter (better name is "HVM-lite"). Basically (and in very short, so it's not a perfectly accurate description), it removes some bits of emulation to get rid of qemu in the middle, thanks to latest hardware improvements (in virt support). Anyway, PVHVM is still far better than PV for a lot of various loads.

The Citrix one, if you have it...

https://developer-docs.citrix.com/projects/xenserver-ddk/en/latest/ Built iso from this guide and extracted rpm from iso.

Updated: main renamed to base.

That's a possibility yes. I don't think it could happen fast however. And you can't close existing opened code, so it will be more proprietary additions in the end. That's why we are innovating directly in XCP-ng, and we'll continue that way!

@olivierlambert said in Github alternative: technical tools are a small part of the work I have to agree