<div dir="ltr">True indeed. <div>XenCommunity is a fine option, which I have found to be good. I have been running a bunch of servers on it, from a single VM on a physical server (to achieve the management benefits with the very minimalistic loss of Xen) to several tenths of VMs on a server in several farms abroad. I have there about 16 servers in each farm, running several tenths of mission critical VMs. The setup is elegant - any new physical server added to the farm is being automatically installed and defined to be able to run VMs, hands-free. This is something easier to manage when using RHEL/Centos, compared to other products, indeed.</div>
<div><br></div><div>Still - the mass use one of the three leading solutions. You would see them in the fortune500, and on many other sites.</div><div><br></div><div>Notice, again, that KVM is VDI-focused, and as the battle in the server virtualization rages between the leading commercial vendors, the VDI market is somewhat quieter. It's about prestige and ego, but everyone wants to virtualize servers, as desktops are less glorious and require harder work, on most cases.</div>
<div>RHEL has made a step towards VDI, with a very clear view of the future, and KVM is their tool.</div><div><br></div><div>Ez<br><br><div class="gmail_quote">On Wed, Jan 20, 2010 at 3:46 AM, Amos Shapira <span dir="ltr"><<a href="mailto:amos.shapira@gmail.com">amos.shapira@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2010/1/20 Etzion Bar-Noy <<a href="mailto:ezaton@tournament.org.il">ezaton@tournament.org.il</a>>:<br>
<div class="im">> PV drivers were released by Oracle, who run their own virtualization<br>
> platform based on XenCommunity.<br>
<br>
</div>Just wondering - are these required to be installed separately when<br>
trying to run Windows on CentOS?<br>
We generally managed to do that when we tried (got stuck on none of<br>
our licenses being accepted).<br>
<div class="im"><br>
> KVM is wasteful and requires VT support even for Linux machines. Not only<br>
> that, but its virtualized hardware is legacy old hardware supplied by QEMU.<br>
> The leading virtualization solutions currently in the market are Vmware<br>
> ESXi, which, for a single server is free and very nice (although you better<br>
> make sure your hardware is in their support matrix), Microsoft Hyper-V,<br>
> which is not Linux-friendly, if you care about it, and Citrix XenServer.<br>
> You can compare these three on the internet.<br>
> Less common, but aggressively in use (with the same performance profile) are<br>
> OracleVM, RHEL Xen platform (with Oracle PV drivers for Windows) - Xen<br>
> Community based.<br>
> On the level of the "low performance" you would find Vmware Server, and Sun<br>
> VirtualBox.<br>
> KVM was designed, and is focused on VDI - desktop virtualization, being the<br>
> focus of Kumranet in the past. RedHat cannot maintain two virtualization<br>
> platforms.<br>
<br>
</div>I expect this targeting will change quickly since RH plan to replace<br>
replace Xen by KVM (in 5.5 or 6.0?)<br>
<div class="im"><br>
> Assuming you aim at Windows virtualization, and assuming you want the<br>
> assurance of enterprise-class solution, I would recommend any of the top<br>
> three, with my favorite Citrix XenServer (check the pros and cons of each<br>
> and make your own decisions in that matter). Other solutions are not<br>
> complete, or will have near-zero support or knowledge base on the net.<br>
> To make things clear - I earn my keep by performing various system and IT<br>
> architecture-related integration operations, amongst are virtualization<br>
> design and implementations.<br>
> I have several customers with large XenServer farms, running<br>
> mission-critical, 24/7/365. The longer one has his farm running since about<br>
> March, containing about 40-50 VMs, including the company's Exchange server<br>
> (~400 users), several Oracle DB environments, MSSQL, ADS, TS and more. These<br>
> are memory-hungry applications, and the total memory allocated there<br>
> (usually memory is the immediate bottleneck, followed by disk IO<br>
> performance) is about 150GB ram, in total, with shared storage and the<br>
> entire shabang.<br>
<br>
</div>I do not have the tools (or wish) to dispute your recommendations<br>
above, they sound reasonable and well baked, but if we are about to<br>
demonstrate what can be achieved with the options then let me describe<br>
what I got running on CentOS 5 (and the old Xen 3.0 which comes with<br>
it):<br>
<br>
18 physical 2xQuad-core servers with at least 64Gb RAM (some have 80Gb<br>
but we decided to stay clear form 8Gb DIMM's) in production.<br>
4 more servers in test env, also with 64Gb RAM each.<br>
<br>
To do the calculation for you - this is upwards of 1408 Gb of RAM.<br>
<br>
A total of 70+ virtual guests.<br>
~1.5Tb disk space, on 12 spindles, in each server.<br>
<br>
That system have been up for over two years now. Only unplanned down<br>
time we had were either due to hardware issues or our own mistakes,<br>
not the platform's fault.<br>
We use DRBD to replicate disks, linux-ha for heartbeat and fail-over,<br>
LVS for Virtual IP load balancing.<br>
<br>
Our up time on the worst part of the system (an old customer portal we<br>
are about to replace) is %99.93 in 11 months (5:20 hours of down time<br>
since February 2009, that's the beginning of the monitoring data of<br>
the current monitoring tools), up time on better parts (properly load<br>
balanced) is up to %99.98 since around the same time (1:25 hours down<br>
since March 2009). These include system upgrades and migration to new<br>
servers.<br>
<br>
There is a lot to improve but I think it's not bad, considering that<br>
our company's entire income depend on these servers staying up.<br>
<br>
BTW - I just google'd a bit about "XenServer centos" and found two blog posts:<br>
<br>
1. One saying that XenServer actually is a modified CentOS, based on<br>
the "Vendor: CentOS" field in most packages.<br>
2. You must have Windows for the graphic management console, which uses .net.<br>
<br>
Cheers,<br>
<font color="#888888"><br>
--Amos<br>
</font><div><div></div><div class="h5"><br>
> Other customers of mine use smaller environments, running one or two<br>
> servers, with several tenths of vms on them. They were unable to reach<br>
> anywhere near this capacity (amount of VMs, performance of every single VM)<br>
> using VMware Server, of course.<br>
> Make your own pick. I can only recommend to use the enterprise class tools,<br>
> especially if they can come for free, and/or you could buy support.<br>
> Ez<br>
><br>
> On Tue, Jan 19, 2010 at 10:11 PM, Oleg Goldshmidt <<a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a>><br>
> wrote:<br>
>><br>
>> Jonathan Ben Avraham <<a href="mailto:yba@tkos.co.il">yba@tkos.co.il</a>> writes:<br>
>><br>
>> > Hi Gilad,<br>
>> > Why do you recommend KVM over XEN? Have you fiddled with both? Are<br>
>> > there particular problems with XEN?<br>
>><br>
>> Apart from the fact that XEN is paravirtualization technology and<br>
>> running a mission-critical Windows DomU is possible mostly in theory?<br>
>><br>
>> Disclaimer: I have not touched Xen over a couple of years (when<br>
>> Windows guests were possible on KVM, at least in principle, and not<br>
>> possible on Xen). I checked the current docs out of curiousity and<br>
>> phrases like "PV drivers are being developed" and "you need to disable<br>
>> driver signature checking on (every!) reboot" [original emphasis]<br>
>> don't inspire much confidence.<br>
>><br>
>> Other points Gilad made (KVM being much less intrusive and already in<br>
>> the vanilla kernel and provided by RedHat) are very much valid.<br>
>><br>
>> To the OP: Xen is not for you. I have no first-hand experience (beyond<br>
>> a tiny bit of tinkering) with KVM. I have quite a bit of production<br>
>> experience with VMware. I am surprised that most of the postings focus<br>
>> on the VMware Server (previously known as GSX). IIRC the OP mentioned<br>
>> "crucial" servers but did *not* say $0 was a requirement. I'd go with<br>
>> ESX for mission-crtical stuff.<br>
>><br>
>> For a serious installation I would not keep data (or system images,<br>
>> for that matter, but YMMV) on directly attached disks.<br>
>><br>
>> --<br>
>> Oleg Goldshmidt | <a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a><br>
>><br>
>> _______________________________________________<br>
>> Linux-il mailing list<br>
>> <a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
>> <a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" target="_blank">http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il</a><br>
><br>
><br>
> _______________________________________________<br>
> Linux-il mailing list<br>
> <a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
> <a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" target="_blank">http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>