XenServer 8.0 - Major update due Q1 2019
-
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 HCL
New Kernel and New Xen
architectural changes inc. more Ram to Dom0
Snapshots for vGPU VMs
Win 2019 support
2TB+ disk support
Improved GPU accelerationSo 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.
-
@_danielgurgel said in XenServer 8.0 - Major update due Q1 2019:
@AllooTikeeChaat I would like hotplug to add and remove CPU (Sockets / Cores) and RAM to be supported with guest VM started.
This is already the case.
-
@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.
-
Not using the latest XS/XCP-ng but at least until 7.1 LTSR it was impossible to change the values for a running VM (by GUI). They are disabled/greyed out.
-
We had this feature exposed in Xen Orchestra since the start (or so). It's just that Citrix only added this in XenCenter recently. So it's more a client limitation done by Citrix than a real modification.
-
Even with XOA, we have the same problem with XCenter. With vCPU the rule works because you set a usage limit and can increase to the maximum that the host supports.
But for memory, we have only the minimum and maximum and the dynamic memory feature, which allows only a better allocation of the entire host.
But imagine the situation where a customer hires an 8GB VM and then wants a feature upgrade, to 16GB, the increase can not be done "hot," with the server on, requiring a schedule to perform the upgrade.
In the case of VMWare, HOTPLUG is supported, that is, I can upgrade to 16GB without turning off the VM. I believe this is a limit on qemu, since all versions of Xen (Source) support hotplug for vCPU, RAM, Disk and Network,
In XOA:
VM_BAD_POWER_STATE(OpaqueRef:8727f5ec-37ad-4273-8130-a1c0df0ed96b, halted, running)
MEMORY_CONSTRAINT_VIOLATION(Memory limits must satisfy: static_min ≤ dynamic_min ≤ dynamic_max ≤ static_max) -
I don't see the problem: just extend the static memory to the max of the host capacity and with a dynamic max to the amount you need right now.
After a while, if you need more RAM, just raise dynamic max up to static max.
Am I missing something here?
