The Citrix one, if you have it...

I have no idea, ask Citrix: https://bugs.xenserver.org Well, Xen isn't Linux. It's a micro kernel booting first then having a privileged domain to administrate VMs. So there is still some CPU/memory isolation on Xen level that isn't required in the dom0 itself. But I can't tell more if there is specific reasons, Citrix has the answer.

@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

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?

This is in theory possible, but not trivial. Usually @r1 or @stormi can give you good advice on how to try to do it yourself (unlike XS, we are open to "do it yourself, here is some tools" philosophy). Also in theory, XS 7.6 should be out in weeks (4 or 5 max? if they stick to their plan), with probably a more recent kernel. IDK which option will be faster.

Thanks stormi. Still no testers thou. I found one critical bug that effectively prevents deployment . Reconfiguration of existing VMs works as expected . I have prepared a commit to fix a bunch of bugs I found in the mean time but I haven't pushed it to GitHub repo yet. To lazy I guess . If someone is eager to test, I'll push it right away.

@r1 Any Kernel upgrade is a pain, regardless how seamless some distros try to make it. I've been using XS for years and it's always been rock-solid in my production environment. This is the first time I've ever experienced a critical issue. Unfortunately it translates to an unstable system, so there is no telling when the machine is going to suffer a "critical-error" and hang at reboot. My low-level familiarity win XS/XCP-ng does not extend to the depth where I would attempt a self-guided kernel upgrade, however if there is a development fork where they are testing the 4.14 or 4.15 kernel, I would be inclined to evaluate it.

Hi, Yes, it's likely you would have run the same issue with XenServer. Those latest security patches are doing strong side effects and I think the priority was to fix the issue rather than keeping "agile" with the VMs. We discovered that later too. Anyway, due to those patches, it's likely you'll have to reboot your VMs to get the own kernel updates working.

@olivierlambert said in XCP-ng 7.5 net-install ISO: Sounds like something you wanted @maxcuttins You know already... to me what's matter is the level of engagement in the project. At the beginning is always everything awesome but in the long terms most of the project get low level of attention. So I need to be very very very very prudent in order to use something in production on my customers. But in this case I have to say: there is something new everyday. I'm exicted!

Note: even on XenServer, VSS still require to be enabled manually I'm so happy to NOT have Windows VMs into production… Far easier on Linux…

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!

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.