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