XO to manage KVM?
-
Hi,
I guess this is a bit of philosophical question but are there plans to extend Xen Orchestra to manage KVM as well?
I'm looking for a 1 server solution for SMEs where file storage and VMs can be managed on the same server but XCP-ng doesn't seem to be a good fit. Although it's possible to create a VM to work as a file server (SMB/NFS) the VDI has a 2TB limit and the storage would be file based which would affect its performance. Using disk passthrough is another alternative but it brings another set of complications (e.g. backups, etc)
In a KVM solution, there would be a base system running SMB/NFS and KVM, and XO would be managing the VMs (i.e. network, backups, etc).
FreeNAS may be an alternative in the future but it's virtualisation platform Behyve is not as mature as Xen and KVM.
Someone may mention Proxmox but it is not as polished as a solution as XO.
Apologies if this subject was discussed in the past, but I couldn't find anything in my searches.
-
Hi,
I would say you are "inverting" the issue. XCP-ng might be a workable solution for you. If the disk size is the only issue, there is some workarounds. Eg using SMAPIv3 were disk size won't be limited. We are actively working on it, and if you want to play with it, let us know
-
@olivierlambert said in XO to manage KVM?:
If the disk size is the only issue, there is some workarounds. Eg using SMAPIv3 were disk size won't be limited.
As I mentioned above indeed there are workarounds (e.g. disk passthrough) but it has its drawbacks.
I imagine SMAPIv3 won't have the VDI file size limitations giving it supports QCOW2, but it would still be a file based storage. I don't know all SMAPIv3 features, so please feel free to correct me if I'm wrong.
The issue is finding a solution to run a file server alongside other VMs without affecting its performance and I'm more than happy to hear your suggestions.
-
I don't really understand what you meant with file based storage and why it's not usable in your case.
Why using a file server alongside other VMs will be different in Xen or KVM?
-
@olivierlambert said in XO to manage KVM?:
I don't really understand what you meant with file based storage
I mean files are stored in VDI files on top of the filesystem.
On a KVM installation, you may have NFS/SMB installed directly on the host OS and storing files directly on the filesystem whilst VM disks may be stored as files (i.e. raw, VDI, QCOW2, etc) or LVM.
Please correct me if I'm wrong but on Xen you cannot install anything directly on the host and serve the files directly from the file system because everything run on VMs including DOM0. You need to store them in disks plugged into VMs and those disks are stored as files in the filesystem (VDI, QCOW2). So it means you have an additional layer that would affect your performance.
-
On a local storage, you have the exact same way than KVM: your VM disk is stored in a file (VHD or Qcow2). It's exactly the same principle.
Again, I don't really understand what you want to achieve, functionally speaking. Before talking about performances, what do you need? In simple words.
-
@olivierlambert said in XO to manage KVM?:
what do you need? In simple words.
As I said above:
@beagle said in XO to manage KVM?:
I'm looking for a 1 server solution for SMEs where file storage and VMs can be managed on the same server
-
I don't see the problem to achieve that with XCP-ng. I think we even have people here doing that.
-
I can't see other solution than setup NFS/SMB on a VM and attach a disk for storage, but as discussed above this solution has 2 issues: (1) the 2TB limit on VDIs and (2) serving the files stored in a file (VDI) instead of directly from the filesystem would give you poor performance.
These problems could probably be overcome by using disk passthrough but this solution has other implications. For instance, backups.
I would appreciate if you have another solution that I may be missing.
-
I still don't get what you want to do. I understand the part where you want to have eg a FreeNas as a VM and share files inside it. But why on earth use this VM to store other VM disk? This is a completely different usage, almost orthogonal.
You need a space to store your VMs, and you need another space to store your "shared files" (eg SMB/NFS) between your VMs. It's NOT the same thing and has vastly different requirements (eg you use hypervisor backup aware system for your VMs, and file level backup for your NAS).
Again, the "global" use case is unclear to me. Why not having your NAS VM on some disk space and keep the rest to store your VM disks?
-
Apologies if I was not clear, but you misunderstood what I said.
Let me try to put as a simple question. How would you setup a 20TB fileserver on XCP-ng?
-
My first answer is "I wouldn't" because it's not meant for that. However, if you have a good use case, then, second answer is "disk passthrough".
I wouldn't never backup nor migrate a 20TiB VM anyway. At least not with a backup that's hypervisor aware. Rsync would make a better job (inside the VM).
By having a very large VM, you'll lose all the flexibility of virtualization. So it's not "bad" if you want to avoid a second physical host for your file storage, because then VM flexibility is already annihilated by the VM disk size itself.
-
@olivierlambert said in XO to manage KVM?:
My first answer is "I wouldn't" because it's not meant for that
And that brings me back to my OP where I said XCP-ng was not a good fit for that use case.
On the other hand, you can install the file server on bare metal and have KVM handling the virtualisation side. Two complete different solutions working side-by-side. The piece missing in that overall solution is XO to manage the virtualisation.
Another upside of having XO extended to manage KVM hosts is the possibility of having XO managing a heterogeneous datacentre with both Xen and KVM hosts, similarly to CloudStack and oVirt.
-
It's the exact same thing for KVM. Any virtualization platform is not "meant" to be a big filer. Period.
Using passthrough you can partially solve the issue, I don't see why you aren't considering this.
-
Note about technical feasability: XO uses the high level XAPI to manage pools and VMs and is tightly coupled to that XAPI and all the concepts it defines (VDI, PIF, VIF, SR, etc.). Changing it to make it manage other virtualization solutions would require a total overhaul, lots of "if XAPI else...", UI headaches when the concepts are too different. That would be a completely different tool in the end. I'm not a XO dev myself but I can see that it's a huge project that you are suggesting us to develop, for benefits that are not so obvious.
About your use case, I don't understand why you can't store your VMs on local storage. Why do you need them to be in local NFS share?
-
@olivierlambert said in XO to manage KVM?:
It's the exact same thing for KVM. Any virtualization platform is not "meant" to be a big filer. Period.
I don't know why, but it seems I'm not being able to get my message across. I don't want to run the file server "inside" the virtualisation solution. For my use case the main difference between KVM and Xen is that I can run the file server and KVM side-by-side both using separate local storage. Whilst on Xen I can't do that because I can't install the file server on bare metal.
Thank you @stormi for raising the technical challenges of that implementation and I would say that the main benefit is extending the excellent tool that is XO to the expanding user base of KVM. Just think about all the KVM shops or heterogeneous datacentres that would be able to use XO.
Yes, indeed it's a big strategical change with technical and financial implications, but XO could be an alternative to CloudStack or oVirt.
-
The message isn't clear because I think we are fundamentally seeing virtualization differently
As long as you are using a host for virtualization, there's no "outside". The host of KVM will also act as a "driver" domain/host for the VMs, a bit differently but still with the same general principle than Xen.
You can always install NFS inside the dom0, but that would the same weirdness level that doing that in KVM host too.
If you want a filer outside your virtualization, use another physical host. And again, passthrough is OK, there's various users here doing that with FreeNAS for example.
-
Sounds like KVM would be a better solution for you since you want a file server bare metal AND a hypervisor solution wrapped into one.
-
@olivierlambert said in XO to manage KVM?:
The message isn't clear because I think we are fundamentally seeing virtualization differently
I guess so.
I understand when you look purely on virtualisation Xen and KVM will be similar in a sense. You have a host for the VMs and that's it. There is no "outside". The whole purpose of that physical server is hosting VMs.I'm having a physical view of a server where a SME can only afford a single server. In that scenario, you are installing softwares to address different necessities. In that scenario, KVM is "just another software" that is addressing the need to host a few VMs whilst NFS/SMB will be serving files, and a webserver will be running webapps, etc. Think on the lines of ClearOS or UnRAID.
@Biggen said in XO to manage KVM?:
Sounds like KVM would be a better solution for you since you want a file server bare metal AND a hypervisor solution wrapped into one.
Indeed, that's why I said XCP-ng wouldn't be a good fit, but XO would be a great addition to manage the virtualisation side of this solution.
And the use case is much wider if you think about larger companies and hosting providers running heterogeneous hosts with both Xen and KVM. I'm pretty sure there are plenty of hosting companies running both Xen and KVM on their DCs.
-
I disagree regarding KVM vs XCP-ng in this case. The result, system wide, is pretty similar. You can create a file server in the "host" with both solutions.
Again, I don't see any problem to use disk controller passthrough for your filer, you won't lose any perfs and you'll have a good isolation.
The rest of the available disks will be used as local storage for the other VMs.
Using this setup, you have your "one machine" setup.
