XenServer 8.0 - Major update due Q1 2019
In your opinion, can we expect the arrival of PVH mode or is too early (need Xen 4.10 and kernel 4.11 ) ? This could be game changer for Xen imo
The kernel will be indeed more recent, but I'm not sure about Xen version. So I can't tell. However, the Citrix release cycle is relatively fast since a release each Qx (Q1,Q2…) so I think we may expect some experimental PVH support in 2019. But that's just my feeling based on nothing "concrete".
That what I thought in some way too. Wait and see
Latest dev build from XCP-ng Center in preparing of XCP-ng 8.0:
Apologies for resurrecting this old post but there was some very minor XS 8.0 news from a Citrix rep on a very recent Citrix Virt Apps n Desktop (XenApp/XenDesktop) webinar. Not much info on XS was mentioned other than:
New Kernel and New Xen
architectural changes inc. more Ram to Dom0
Snapshots for vGPU VMs
Win 2019 support
2TB+ disk support
Improved GPU acceleration
So nothing that we didn't already know.
A couple of things:
- Citrix are effectively shuttering the "Xenserver.org" website. All downloads now are redirected back to Citrix.com
- In the old days for a major release like 8.0 we would have seen a tech preview of XS 8.0 in Q1 2019 but there's no sign of that at all.
My hunch is that there'll be no news until Citrix Synergy 2019 in May.
We have some sources regarding what will come and it will be likely: updated CentOS in dom0, small Xen increment, kernel 4.19 (or 4.14 but likely 4.19). No public tech preview planned at all.
It should be out in the next days if our sources are correct (before April 1st)
Correction: maybe few days after April the 1st, but around there
@olivierlambert It'll be good if it does show in April as I had thought it would be @Synergy 2019 in mid May. I'm hoping they don't drop support for the older Xeon's using the LGA1366 socket.
Any thought on how much of it Citrix may be trying to make closed-source to throw a wrench in the spokes for XCP-ng?
I know they've announced a session at Synergy just to talk about it so I'm pretty sure it'll be out before then but I hadn't heard anything about sometime in the next couple of weeks.
@JeffBerntsen they already threw a lot of wrenches toward XCP-ng. It started since 7.5, with some packages becoming closed sources, or even funnier: RPM packages embedding Citrix logo so you can't redistribute them directly "EMU manager"-gate is also a good example on how XS management try to fight us beyond any reason and cooperation (which would be mutually beneficial). Finally, new features are closed sources too (eg the unfinished but declared production ready GFS2 feature).
But in the end of the day: Xen and XAPI are Linux Foundation project. This is a strong working base to make XCP-ng without bothering about Citrix. So I'm not worried.
Regarding the release date of 8.0, expect next week.
@olivierlambert How silly on the Citrix side, is not it?
XCP-ng could be the same for XenServer as Fedora is for Red Hat Enterprise Linux.
Or at least the same relationship between CentOS and RHEL.
We can think of other successful relationships too, OKD and OpenShift and oVirt and Red Hat Enterprise Virtualization.
Interesting, everyone I mentioned has a Red Hat finger.
About Fedora/CentOS: it's exactly the message I passed to the management team: we are not an enemy but in the opposite, we can bring more people in the Xen world (also we aren't focusing on desktop virt, which is the margin in big and where Citrix is).
It seems they are a bit "against" the Open Source itself, and IMHO they see it as a threat for their business.
Luckily, Xen/XAPI are Linux Foundation projects, so it's a good protection from big dick moves.
@AllooTikeeChaat I would like hotplug to add and remove CPU (Sockets / Cores) and RAM to be supported with guest VM started.
@olivierlambert Its seriously disappointing that Citrix see XCP-NG as a "threat" and not as a companion that can help them too. It doesn't have to be that way and I'm shocked that they were "embedding Citrix logo" into rpms. I hope that they appreciate the work (bugfixes, enhanacements, etc) that the XCP-NG team and community has been doing to help improve XS.
Do you think they will go with Xen 4.11 as that is EOL 2020 and EOS 2021 as all the other Xen releases are EOS 2020?
The thing is "Citrix" is a bit vague. Citrix on the "top" doesn't really care about XS, so it's more a product managers decision (to throw wrenches against us). It's also NOT something done by the dev team (because there is a lot of people working on Open Source there).
So yeah, basically, XS product management tried to "weaponize" their binary RPMs, plus the story of breaking migrations with using proprietary EMU manager. Note those attempts failed miserably, and now we are building all of our packages ourselves.
However, I recently (last months) saw some change in how they deal with our contributions, it's like they started to understand we can bring improvements (and QA). Which is our goal from the start.
Frankly, I never wanted to be considered a threat by them, I'm still thinking why they were so afraid about us doing XCP-ng (and pro support).
Regarding Xen version, we'll see the truth soon enough
@olivierlambert How is this done?
I'm not talking about dynamic memory or Maximum vCPU when starting a virtual server.
I'm talking about hotplug, add CPU / Memory even though the values are higher than configured in the VM. Hyper-V 2016 Generation 2 has already held this and VMWare a long time with Hotplug.
How is this done? Just give a bigger vCPU max than current vCPU while the VM is off, same for static MAX for RAM. Xen and XenServer support this for a while and it works well. So I don't understand why you can't achieve it?
@olivierlambert I think you missed the point that he wants the ability to do this while the VM is running
And? Sure, you can do that, as long the VM is within the static min/max and under vCPU max settings. I'm using these features since I use Xen.
I'd really like to understand what's the limitation here. The only "recent" limit is the number of max vCPU can't be larger than total number of cores on the system, to avoid side channel attacks.