@danp said in XCP-ng 7.5.0 final is here:

@dblogic said in XCP-ng 7.5.0 final is here:

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.

Beta is out: https://xcp-ng.org/forum/topic/454/xcp-ng-7-6-beta

@borzel well I agree more details would be useful, I think the larger concern is that a VM is effecting the hypervisor is a negative way.

Can you post the logs for your hypervisor?

It's mainly marketing plus lack of knowledge of "the masses" regarding purely software solution (targeting Windows users in general).

@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

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.

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!

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!

@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.

Thanks for the tests. I have now moved the updates candidates to the updates repository, so everybody who installed 7.5RC1 should see the updates soon.

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... 😮

Hi,

Since we do NOT use supplemental packs but directly RPMs, it's a bit different. We got a build env dedicated to that: https://github.com/xcp-ng/xcp-ng-build-env

If you have questions, please ask @stormi 🙂

Updated: main renamed to base.

Document updated: new, simpler, branch structure for the repositories + section added to detail how we handle experimental changes to existing packages.

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

@borzel The button seems like it was just randomly dropped on the page. I would suggest moving it directly below the checkbox group and the boot parameters entry field.

My 2cts...