Just tried updating our pool and after updating the master had failed migration of VM (Ubuntu) and then was unable to get VM to start (Missing VDI error). Only solution was to roll master back to 7.4 and everything working again.
I ran into a similar situation when I upgraded to 7.5 this week. Did you check to see if there was a non-existent ISO mounted in the CD rom for the VM in question?
Thank you. That was my problem. I gave cd empty. Everything works.
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
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!
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.
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.
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! 😄
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
# if the kernel or xen-* packages got updated, reboot your server
# that's it, you've got 7.5.0 final!
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.
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... 😮