Post to Twitter |
Comments (9) |
Views (64449) |
With both my Citrix XenServer and Xen community hats on at once, I have to salute another piece of creative writing from the VMware competitive misinformation department. This time it's about CPU architectures and live relocation (which we call XenMotion, just because we can). The piece states that we don't check CPU compatibility on migration of a VM between servers. This is ridiculous, because if we didn't VMs would be crashing about our ears when we do live relocations. Both in XenServer and in open source Xen, we require a match on CPU processor vendor, family and stepping before a migration can be performed.
I'm beginning to understand why the VMware blog is called "A little truth...". While I'm all for competitive intelligence in general, when the code is available in open source for everyone to review, it's just not possible to pull the wool over everyone's eyes like this.
And though I know this has hit the wires before, I keep hearing from VMware customers that are buying XenServer why they love the simplicity and robustness of our product and of Xen: The total number of patches shipped to date for XenServer: 0. Total hot fixes and patches shipped last year for VMware VI3/ESX alone: 68*!* of which 17 were critical. Silly me! Those were probably only "feature enhancements".
Comments (9)
Feb 19, 2008
Anonymous says:
you go boyyou go boy
Anonymous replies:
Feb 19, 2008
Anonymous says:
More Power to you Simon .More Power to you Simon
.
Feb 19, 2008
Anonymous says:
Simon, You may have a valid point about the post made by this Vmware guy. Howev...Simon,
You may have a valid point about the post made by this Vmware guy. However if you think this is going to sway someone from buying Xen think again.
As someone who has used and sold Vmware for many years, there are many...many reasons why Xen is not up to scratch yet. Yes you may have less patches, and perform better or pretty much the same as Vmware in terms of performance. However Xen is far from enterprise ready so I don't you should go there with this debate as you surely must know the current limitations of Xen vs Vmware.
PS:I am also a Citrix man, however providing an enterprise ready solution has to be one of the most important factors for my solutions. In previous ESX versions of yesterday, this challange was also true.
Feb 19, 2008
Anonymous says:
"...many...many reasons..." Such as?? Please be specific."...many...many reasons..." Such as?? Please be specific.
Feb 19, 2008
Anonymous says:
Simon, Being a Xen customer I totally agree with your comments of ease of use. ...Simon,
Being a Xen customer I totally agree with your comments of ease of use. I am a great user of Xen and love it. But unfortunately we could not use it for our enterprise workloads due to weird and wonderful issues that even down to this day no one could sort out. One of those issues being vm migrations. Sure it may check cpu's but the checks must not be performed at the same level as ESX. As a result, Xen migrations would only work around 50% of the time which was unacceptable to the business. So to cut a long story short, ESX VI3 is what we use for our enterprise workloads and Xen for non critical applications. ESX just works. We perform about 100+ VMotions a day thanks to DRS rules and this has been running solidly now for over 6 months with no downtime what so ever. To our business and I am sure most business's out there, UPTIME IS Critical. Xen just does not have the robustness and maturity...yet!
Hopefully with a bit of time this will change for the Xen product.
Regards.
Feb 19, 2008
Roger Klorese says:
The checks are actually done at EXACTLY the same level as VMware's. The differe...The checks are actually done at EXACTLY the same level as VMware's. The difference is that we do it at pool join time. So if you joined the pool and TOLD us to ignore the checks... well, you get what happens when you ignore the checks.
Jan 21, 2009
Anonymous says:
Where can I find a list of the checks that are made as of the Orlando release? ...Where can I find a list of the checks that are made as of the Orlando release?
Thanks!
Feb 24, 2009
Anonymous says:
I'll bite after doing benchmarks of XEN on RHEL 5.2 and ESX 3.5 and seeing some ...I'll bite after doing benchmarks of XEN on RHEL 5.2 and ESX 3.5 and seeing some interesting data come back from both the unix and windows admins. We had the unix admins setup XEN 5.2 and ESX 3.5 (default install) on exactly configured blades - same cpu's (dual quad cores), same memory configurations with 32 GB, same SAN allocations on an EMC Symmetrix 4 - in short, enterprise hardware with exact configurations between the two hypervisors. We also put up two additional blades with the exact configurations for a Windows Server 2003 and RHEL 5.2 installs for natvie comparisons.
The Unix and Windows camps did their testing independantly and came back with the same results in a simple one guest confugration against the native hardware: Native, VMware, and then XEN in order from top to bottom as the loads were increased from 0 - 80%. All in all, pretty similar performance.
Then the data got interesting as additional guests were added and then load to 80%. XEN's disk performance was only half of VMware. XEN starved guests when more guests than cores were attempted. By stave, I mean 8 VM's could have load generated and when the 9th guest was issued a command to run load, it waited until one of the first 8 had completed it's duty cycles - this was in the RHEL guests. The situation running Windows on XEN was worse as performance on the guests was extremely variable.
Both teams noted the differences between XEN and VMWare. After conducting these tests, we are in line with VMware's claims on i/o's per second as the tests clearly indicated VMware scaled well beyond XEN when the systems were pushed beyond 5 guests running at 80% workloads. This testing mirrors what we see in our enterprise implementations of VMware.
CPU performance advantage also went to VMware as workloads where increased; in fact, I would call into question the scheduling of XEN as the workloads of the guests were choppy/variable versus consistant performance on the VMware side. The testing had XEN RHEL 5.2 guests in a para-virt config versus RHEL running full-virt on ESX. Performance differences become clear as the number of guests exceeded the number of cores. Keep in mind we run production level virtualization in our data center with ratios of 20+ guests to 1 host and expect to leverage capacity on demand. XEN won't provide this for us based on what we saw in our benchmarks.
Do your own testing as we did. We leveraged tools like nbench and other commercial products on the Windows side; we clearly saw an advantage going to VMware as workloads increased. As you test, make sure you test the hypervisors with more than a single guests as I doubt anyone out there plans on having a 1-to-1 consolidation rate.
We also did live application benchmarks leveraging loadrunner against jvm based hosts - advantage, VMware.
Again, do your own testing and make sure you check scalability and benchmark a real production environment.
Feb 21, 2008
Anonymous says:
Let me clarify my points earlier and some of my many reasons. 1. No centralised...Let me clarify my points earlier and some of my many reasons.
1. No centralised logging system. I perform a Xenmotion and my co-worker is not aware I have done so
2. Limited GUI. Ok so you can perform a Xenmotion and add storage easily.
3. No granular access control
4. Limited OS support (almost all server consolidations I have done have NT4 servers in !)
5. Limited network bonding/vlans
6. Very poor templating/sysprep intergration
Yes I have read the release notesof 4.1, but I have not seen it working live yet.
What I really want to see is an honest comparison between ESX. Not of performance, or even the 'must have' features such as XXmotion but more the things people take forgranted.
Citrix can then let us know how they progress over the years
Add Comment