Hi there,

You probably heard about XenServer 7.3 release and some of its features removed.

So, I started a GitHub organization called "xcp-ng", hosting all the repo needed to make a XenServer OS from the sources. It's 100% community backed.

I actually hired (part time but still) an former XAPI developer, so it will accelerate the pace soon. I think we'll be able to release something in Q1, without any feature restriction (think vGPU + everything) and turnkey as XenServer itself.

If it works well, the door for including directly extra stuff in the project is opened: our Gluster driver for example (and a Ceph driver too), better compression algorithm, CentOS packages available, community contribution etc.

Obviously, we'll start small (probably re-using bunch of existing RPMs), but then we'll try to build more and more from the sources. But the ultimate goal is to have just a RPM repo to install from a CentOS and then use yum upgrade to stay up-to-date!

All contributions are welcome, if you want to join the GitHub org, feel free to ask!

Hi there,

Just to let you know I recently made initial tests to put XenServer in another level. I know it seems really important for some of you here to have an hyperconverged solution for XenServer (@scottalanmiller :) )

I got initial successful test, in a very minimal scenario, so it's just a start.

Context

• a pool of only XenServer 2 nodes (nothing else, no NAS/SAN)
• only using local storage

Objectives

• a loss of one host won't affect storage for any running VM on the other host
• allow live migration between two host without disk transfer
• no split-brain scenario even in 2 nodes context
• no SPOF
• no XenServer system modification

Results

Worked as expected in first tests.

Limitations

• a bit of RAM and storage will be needed to provide this
• it relies on dedicated VMs (one per host) to expose it
• it uses a iSCSI SR in multipath

Ideal objective

XOA would be able to download and deploy all the needed stuff inside an existing infrastructure (depending if there is enough resources obviously). So a "one click to install my virtual SAN" would be totally possible.

Also, there is very interesting possibilities for more nodes scenario (not just replicating, but distributing the content AND duplicate it to allow correct performances).

I think it's better to regroup a little bit all the recent conversations around XO in this topic (if it's fine?). It will be better for me to have one place to follow here than checking for new topics about it ;)

Documentation

The first place to go before asking questions! https://xen-orchestra.com/docs/

Quick links:

• General architecture
• Install
• Main features
• Contributing

Quick intro

XO is a kind of middle-ware between you and multiple XenServer hosts. It doesn't require any XenServer setup: it works out of the box.

With XO, you can manage, backup, delegate your XenServer infrastructure.

Business model

If you are a company and you want a turnkey solution with support: XOA which contains:

• a virtual appliance with XO installed (nothing to do)
• an automatic updater (one click to upgrade)
• corporate support and full priority to fix any issue
• QA is done on XOAs, code/dependencies are "frozen" between releases

If you are not interested by the turnkey solution, you can install it from the sources, you'll have ALL XO features, but no XOA features (the previous given list). If the solution begin to go in production in your company, we strongly suggest to get a XOA to avoid any source problem. It's also paid customers which help to continue to work full time on this ;)

Things to know

• You can complain about the UI, it's already planned to rewrite it from scratch in the next months ;)
• I'm the project leader (and CEO of the company selling it), feel free to ask me anything
• We like to be transparent about how it works to build a project like this. Sharing thoughts is always positive.
• I'm personally convince that more brains are working on a topic, better it is: tell me your needs or ideas, it's always a good thing!
• I've got no problem with critics, go ahead :D
• We are a very small company, 100% dedicated on XO. We don't have 100 engineer working on it (not even 10)

I'll keep to update this post.

Custom builds

Here, I'll post link to scripts/stuff from people here to create a functional XO installation quickly.

Keep in touch

We try to release every 15 days. I'll write at least one or two blog post per week here: https://xen-orchestra.com/blog/

I put the new articles on Twitter if you want to follow: https://twitter.com/xenorchestra

If you are a XO user, reading the blog is really helpful to catch last features and how to's

Hey there! I'm seriously thinking about hiring a tech for doing XO support, ideally based in the US (where most of our users are). We are reaching a "critical mass" of users, and I would like to delegate level 1 issues (at the start) to someone external (not my devs or myself).

Do you have any tips on where should I look? Obviously, it's remote work at 100%.

I said Q1 for the first release. On schedule. https://xcp-ng.github.io/news/2018/03/31/first-xcp-ng-release.html

First PoC is here: https://xcp-ng.github.io/news/2018/01/22/xcp-ng-on-tracks.html

:)

Have 7 min to read something?

Here is some bits about Vates, the startup behind Xen Orchestra: https://medium.com/@olivier.lambert/building-a-tech-startup-in-france-cc369c0865db#.wpayxisd7

Sorry about my English in this article, but I wanted to share this story here :)

@scottalanmiller It's planned to release file level restore in next release (~15 days) if everything go smooth.

Hi lads!

I'm XO's project leader :)

• @scottalanmiller XO does provide DR features, see https://xen-orchestra.com/docs/disaster_recovery.html
• @johnhooks it's all Open Source (aGPLv3). If you don't want the turnkey solution (appliance and pro support), "use the sources Luke" ;)
• about the price itself, please consider you'll have an appliance with support working out of the box (plus the web updater). And price is flat.
• complete features list is here: https://xen-orchestra.com/docs/features.html

Last thing, about using it inside or outside your infrastructure: because it's agent-less, you can use it everywhere. You can even imagine a small host with only XOA inside, the thing needed to "talk" to your others XenServer host is only a TCP connection to port 443. VPN connection to multiple datacenter is fairly possible (or other tunnels).

Next release (4.11) will be awesome!

• Incremental backup
• Cloud Init support
• SMB remote for backup (only NFS until now)
• Improved search bar
• XMPP alert plugin
• A lot of small but useful things
• And a far better support of older XS version (6.1 and 6.2)
• ~40 issues closed

Hope to deliver this Monday or Tuesday at worst :)

I think the VM could still be migrated so long as I detach the passthrough disks first, move those disks to a new host, migrate the VM to the new host, and then re-attach/passthrough the disks on the new host.

You can indeed. Not very practical but no technical barrier.

I wonder - can you create an NFS mount point in XenServer or XCP-NG? then just share that via loopback?

I don't really see the point of doing that? I had in mind an NFS share mounted directly in the VM. Simple, efficient (if you already have a NAS obviously)

You can attach more than 7 disks when you have tools in the VM. In your case, you don't need a VM in the traditional way, ie something flexible that you can migrate etc. So you can indeed attach your disks directly, regardless the hypervisor you choose.

Another more flexible alternative would be to have a "normal" VM, but attach a NFS share on it to store your data. This way you keep the flexibility of the VM and the large storage you need. The extra requirement is any NFS capable machine (even a very cheap NAS)

Thanks for correcting the sentence @travisdh1 ;) Indeed, SMAPIv1 is using VHD format everywhere. This format is limited at 2TiB by "design" [1] . This has nothing to do with XO or even XCP-ng because it's a fork of XenServer, ie a copy with new or improved code. So remember that regardless which filesystem you use, as long as you are using VHD format to store virtual disk, you are limited to 2TiB.

However, SMAPIv3 is using qcow2 format instead, "solving" this limitation. We (XCP-ng team) are currently working on improving SMAPIv3 to support disk import/export in qcow2 (which isn't even done by Citrix people themselves :laughing: ). As soon we got that, the next step is to write drivers for ext4 for example, which is doable relatively easily.

One of main issue with SMAPIv3 (there's others) is the fact a part of the development is done privately by Citrix instead of collaborating (see this conversation on GitHub), so the goal is to catching up on our side to be able to get an upstream public faster and become the de facto upstream standard. We are working toward that but it's not something you solve in one week (you need to go deep in qemu-dp/xen blktap, see our efforts here etc.)

[1]: The VHD format has a built-in limitation of just under 2 TiB (2040 GiB) for the size of any dynamic or differencing VHDs. This is due to a sector offset table that only allows for the maximum of a 32-bit quantity. It is calculated by multiplying 232 by 512 bytes for each sector.

edit: also, as soon we got qcow2 import/export support in XCP-ng, we could use that format in XO to store backup. So far, there's only 2 options to get disk data from XS/XCP-ng: raw or vhd (that's why XO is storing VHD files, because… that's what we got from the hypervisor!)

Also we could achieve hyperconvergence "the other way" (unlike having a global shared filesystem like Gluster or Ceph) but use fine grained replication (per VM/VM disk). That's really interesting (data locality, tiering, thin pro etc.). Obviously, we'll collaborate to see how to integrate this in our stack :)

FYI we started very interesting discussions with Linbits guys (we could achieve something really powerful by integrating Linstore inside XCP-ng as a new hyperconverged solution). It means really decent perfs (almost same as local storage) and keep it robust and simple.

I said Q1 for the first release. On schedule. https://xcp-ng.github.io/news/2018/03/31/first-xcp-ng-release.html

@scottalanmiller You should have mixed some stuff. PV mode doesn't need PV drivers by definition. You meant HVM? (to be in PVHVM then?)

@scottalanmiller Citrix doesn't care anymore on server virt market, since a while now.

@scottalanmiller I don't see exactly what are you talking about. What's PV driver feature?

@tim_g said in If all hypervisors were priced the same...:

@olivier said in If all hypervisors were priced the same...:

@tim_g said in If all hypervisors were priced the same...:

If features and costs (free) were identical across the board, I would choose KVM hands down.

I love being able to run off Fedora Server, plus all the doors that open up by doing that... which you can't get from Hyper-V or VMWare.

Sure Xen can be installed on there too, but it's dieing and I'm less familiar with it.

Can you stop with that FUD? Thanks. It's not dying at all. I hear this since 2006. It's like saying Linux is not secure because Open Source.

No fear or doubt, just uncertainty. But this is only because of how Citrix is treating Xen Server, and how Amazon is moving from Xen to KVM.

I feel the only thing that can save Xen is XCP-ng. I'm really hoping for it's success and have high hopes for it.

That's because you have a very partial view of Xen project. Xen project is far more than XenServer/XCP. Xen is the core hypervisor, used by a LOT of companies (from automotive to the Cloud).

A lot of companies are using it Xen + their own toolstack without making publicity around it (like AWS, which is NOT leaving Xen, just adding some instance on another HV to get some specific features not in Xen yet). Some companies (Gandi) even switch from KVM to Xen:

https://news.gandi.net/en/2017/07/a-more-xen-future/

So your opinion is mainly forged by limited number of sources, in a loop of telling "Xen is dying" since 10 years. The main reason is that because Xen is far less "segmented" than KVM (eg: easier to make clickbait articles on Xen security issues than KVM, despite KVM sec process is almost catastrophic/non-transparent)