Today I got called to a client’s site who recently moved from premises A to premises B. This meant they turned off their VMware ESX 3.0 server for the first time in a while. When they relocated they couldn’t authenticate nor could they get to their file/print server. A quick analysis showed a few things:
- New building = New IP scheme (ugh)
- Upon logging in to the ESX web portal, the two servers were still off
Noting this, no worries, in the web portal, lets start them up. Easy and straightforward. Now, here’s the kicker. I wanted to remote control the servers via the console or via the VI client (to look at potentially changing IP addresses or find out what the old scheme was and change it to match/overllap the new scheme)…Wrong move.
The server first told me I had a non-supported browser. I was using IE 8 (as it is standard with Windows 7). Ok, no problem, as an IT Pro, I’ve also got other options…Firefox 3.5.7…nope not supported either. Opera? Guess what, no go. Ok, so let’s download the VI Client and do it that way. Downloaded no problem but when starting it, the woes began again:
Thanks VMware. Your client only works on 32 bit architectures. So that means most IT professionals who have more than 3 GB of memory can’t use your client? Oh, one other thing, nice UAC prompt:
Program name: Contact: Your local administrator
OK, so my rant now done, why does this upset me? Well, Hyper-V can be managed:
- locally on 32 or 64 bit with RSAT
- remotely with RDP
- in just about any browser using SCVMM
Yet another reason why I think I’m going to be sticking with Hyper-V.
NOTE: Yes, I know there are ways around installing the 32 bit client on a 64 bit OS, but I didn’t want to, nor did I have the time, to pull apart the installer with an MSI builder and have it bypass the OS checks. That’s not my job and that’s not why customers pay VMware loads of money for their software – OH, payment…that’s right Hyper-V is FREE too and it has this functionality in built 
Possibly related:
[
#1 by Eric Gray on Tuesday, January 19, 2010 - 14:24
Quote
In summary, you are upset because ESX 3.0 is not compatible with the latest Windows client OS — the one that just launched a couple of months ago.
The fact is that while thousands of customers were using ESX 3.0 to virtualize production workloads, Hyper-V was just a glimmer in Bill Gates’ eye, Windows Vista was a baby, and 64-bit clients were essentially unheard of.
But I do agree with your conclusion — sounds like you should stick with Hyper-V.
Best regards,
Eric
#2 by Justin on Tuesday, January 19, 2010 - 14:55
Quote
Hi Eric,
I wouldn’t necessarily say that 64 bit clients were essentially unheard of, as I’ve been using a 64 bit OS for some time and this install I did for the client was less than two years ago…Reality really is, if VMware (the company you work for) can install their server software on an x64 platform and support x64 virtual images, why can’t the management software do the same?
And yes, while thousands have Virtualilsed with ESX 3.x, that is because VMware was the only “big player” in the virtualisation market…Now that there is competition though, it makes the playing field that little bit different and gives people like myself the reason to write why I feel the management tools of Hyper-V are better than VMware.
Is there even an x64 client available today?
-Justin
#3 by Gabrie on Tuesday, January 19, 2010 - 15:44
Quote
Hi
Your conclusion of hyper-v being better than VMware ESX based on the fact that you couldn’t access the webinterface, nor had the correct client is a little thin don’t you think so too?
I can just imagine you delivering a report to management in which you justify running the datacenter on product A instead of product B, because their management client doesn’t run 64bit.
Current VI Client does run on 64bit Win7 by the way, just not as 64bit app but 32bit app.
Gabrie
#4 by Collin C. MacMillan on Tuesday, January 19, 2010 - 15:51
Quote
You do know that ESX3.0 has been end of general support for over a year, right?
You do know that the “work around” for Windows 7 takes 30 seconds to implement, right?
You do know that the vSphere Client no longer needs the “work around” to install under Windows 7, right?
You do know that you could have RDP’d to the Virtual Center Server to run the VI Client, right?
You do know that the VI Client (the old one that goes with ESX 3.0) runs in “XP Mode” under Windows 7, right?
You know it was Microsoft that chose NOT to support legacy 32-bit applications on Windows 7, right?
As I see it, none of your pretences are valid reasons to discard choose Hyper-V over VMware, but let me give you one simple reason – no, two – to keep VMware over Hyper-V: VMFS (over FC, iSCSI – take your pick) and NFS. These two “technologies” provide something elegant that Hyper-V has yet to accomplish: simple, reliable, easy to configure and manage shared storage for live migration. Are there others? Sure, memory management, footprint, ease of install and deployment, performance, vast numbers of enterprise references and proven deployments…
As an “IT Pro” you should be prepared to work in your client’s environment, not expect their environment to work around your tools (or, as in this case, your lack of the proper tools.) Certainly, lack of preparedness is no cause for such acrimony, and these obstacles are NOT uncommon to MOST EOL technologies.
Lest your “free” comment go unchallenged, Scott Lowe had a great – and well commented – discussion about enterprise use of Hyper-V versus VMware on TechRepuplic:
http://blogs.techrepublic.com.com/datacenter/?p=1851
Conclusion: it ain’t “free as in beer…” My advice: rank tools according to their VALUE not COST. Advocacy for FREE software is based on FREEDOM, not zero cost. The intrinsic VALUE that the F-OSS community brings to the table is the ability to open the code to application specific change. Microsoft puts no such FREEDOM into Hyper-V. Further analysis of the “freeness” of Hyper-V leads to a more costly conclusion.
Does Hyper-V (free) have a VALUE proposition? Sure, just like ESXi “Free” and vSphere’s Essentials line-up (not “free”). “IT Pros” can evangelize one technology over another, but we do our clients a disservice promoting one over the other over a personal bias. Would I deploy Hyper-V for a client? Never, but I would refer the client to a Hyper-V shop (and have many times) if I thought it was a better fit for the client’s needs.
#5 by Justin on Tuesday, January 19, 2010 - 16:17
Quote
Hi Gabrie,
Management are all about uptime and if you can’t properly manage your infrastructure with just about any client, depending on situational aspects (browser version, OS version), then yes it is a compelling reason to put forth.
#6 by Justin on Tuesday, January 19, 2010 - 16:26
Quote
Colin,
Let’s look at some things you say:
You know people still use XP right? Not every IT department can upgrade the infrastructure just because EOL comes around. Out of support isn’t an argument. Technically it is still supported though, just in extended mode.
My point exactly…there shouldn’t need to be a “workaround”
Right, so lets sell the SME’s more stuff, like vSphere. More stuff they don’t need nor do they want. One other thing, it didn’t work right away, it had to be fixed/resolved in VMware ESX/ESXi 4.0 Update 1 (U1).
Again, you’re assuming they have a Virtual Centre Server. Not all IT companies implement all of the bells and whistles due to cost. So, therefore no Virtual Centre server to RDP to.
XP Mode, right. You have to have hardware virtualisation for that to work. Not all 64 bit OS’s have that capability in the BIOS and even if they do, you’re still creating a “workaround” for something that should work WOW.
No, I’ve never heard about that. Can you supply me a source/URL for this?
As for storage, there are other ways around it. Sure VMware has VMFS, but it’s not fool proof either.
With regards to footprint and memory management, those are two big misconceptions about VMware. Sure there is a smaller footprint, but much, much more vulnerabilities per MB. Also, memory management, if you are referring to overcommit, that’s a technology that no IT Professional in his right mind would use in production. Surely in testing, but if you’re thinking of overcommitting memory in a production environment, you ought to first know what’s happening behind the scenes and the true impact – definitely not worth it.
As for being ill prepared when arriving at the client site, I nowhere mentioned I didn’t sort the problem. I wasn’t ill prepared, just again, making a point in case that I had to have numerous bespoke tools as an IT Pro, rather than just a swiss army knife with numerous options.
Deployments, sure there are going to be more VMware deployments than Microsoft. It’s been in the field longer, given. As for the comments over at TechRepublic, they are basic and not real world. You can easily manipulate the numbers in either’s favour. The thing about it is though for SME organisations (not all IT organisations are enterprises), if you buy Windows Server, you get Hyper-V. If you buy Windows Server Enterprise, you get four free licenses. With that comes the functionality which you have to pay VMware for – not free. You do make a point about value and cost and I will agree, VMware has been around longer than Hyper-V and is a more mature product. However, that doesn’t mean that Hyper-V isn’t making in roads on it. In the same way Firefox fans are saying use FF and not Internet Explorer and angering people along the way, Hyper-V advocates are saying use Hyper-V in lieu of VMware and it’s upsetting the masses. That’s the IT world. Choice and opinion.
All Hyper-V is free, whether you use the Server 2008 Hyper-V incarnation or use it on Standard, Enterprise or DC edition. Also, all features are included in all versions. As for a dissservice to my client, if I solely evangelised Hyper-V, why did they have VMware? It’s not a personal bias by any means, however VMware advocates are seeing that Hyper-V is an alternative in some cases and the Virtualisation world isn’t soley run by VMware anymore…
I’m not saying by any means that Hyper-V is better soley due to the fact you can manage Hyper-V and you can’t manage VMware with the VI client. What I am saying though is that the tools on offer vary as your mileage might and every infrastructure and installation is going to be different…some large, some small and flexibility is key, and unfortunately flexibility wasn’t there with the VI client in the 3.x incarnation.
#7 by Duncan on Tuesday, January 19, 2010 - 22:12
Quote
Pfffff, here we go again. No one in his right mind? I work for Enterprise Customers only. We are talking large financial institutions and telco’s. All of these benefit from TPS. That MS doesn’t have TPS yet does not mean it is not useful. It means MS just needs to catch up, and when they do they will tell the world how awesome it is and so will you probably.
The rest is your opinion. Might want to ask yourself though how you ended up in this situation as any environment needs to be monitored / managed and clearly no one bothered to over the last months.
#8 by Justin on Tuesday, January 19, 2010 - 22:47
Quote
Duncan,
I appreciate everyone that has come here has been from a major VMware background, or even from VMware themselves and are obviously soured by the fact that the competition might have something you don’t. Nowhere do I say Microsoft *must* be used or that VMware is absolute rubbish, I’m simply making a statement that Hyper-V caters for easier managability in this instance than does VMware, fact – otherwise it wouldn’t have caused such a stir.
When you say you work for Enterprise Customers, I don’t deny that, nor do I question it. I come from a major enterprise background myself, and have implemented numerous systems all over the world for major corporates. Now, TPS, memory overcommit or ballooning, no matter how you want to look at it, opens a potential can of worms when it comes to security. By finding commonalities and streamlining them in to one, essentially what TPS is doing, allows for a virus or root kit potentially to find its way in to one of the “commonalities” and then propogate itself amongst all of the servers in question. Furthermore, when you overcommit memory, you’re doing it on the hopes and pretenses that all of the servers you’ve got in the infrastructure (obviously on any given host) aren’t ever going to be fully utilised at any given time, because if they are and you don’t have enough memory, or you’ve over committed it in the wrong ways, your infrastructure comes to a grinding halt as that is the way RAM works. Interestingly enough, in a white paper from your company’s website, the following is verbatim re memory:
Which actually negates memory overcomitt altogether, because if you want more physical memory than the total amount of memory that will be used by ESX plus the sum of the working sets, why overcommit?
When a client is using their infrastructure on a Friday and turns the servers off to move to a new environment on a Monday, they’re obviously being monitored, else they would have called myself or another IT provider prior to the move. I’d think of rephrasing your question as it really doesn’t seem to make much sense…No where did I ever mention the system was offline for months or that it was unresponsive for an extended period of time. The article reads:
They moved site, hence all of the physical hardware was moved. It worked when they turned it off last week before moving and this week, it didn’t. That isn’t monitoring/management.
#9 by Duncan on Wednesday, January 20, 2010 - 09:45
Quote
TPS –> COW –> Copy on Write –> Single Block?!
How would a virus propagate itself?
There’s a difference between swapping / ballooning and TPS. I recommend you start reading the Resource Management Guide before trying to spread FUD. If you do want to open a can of worms, please cough up the facts.
I guess you misunderstood what I was trying to get at. How did they monitor / manage their environment if and when they had no workstation which was able to do so?
Like I said to each its own, there’s a place and time for everything. I will leave it at that.
#10 by Justin on Wednesday, January 20, 2010 - 09:51
Quote
Again, I’m perplexed by you’re going on about the monitoring thing, but as your rightly state at the end, it’s best left…as the original point of my posting was that since day 1 of Hyper-V (even back in V1) and SCVMM you can manage it with various browsers and various architectures, whereas with ESX, black and white, you can’t.
#11 by Michael on Wednesday, January 20, 2010 - 10:08
Quote
Before reading the comments (which are highly entertaining by the way) my take on the post was that this comes across as a migration gone bad. With proper planning and preparation, most issues can be avoided. The choice of hypervisor was not the problem here in my opinion.
#12 by Justin on Wednesday, January 20, 2010 - 10:56
Quote
Michael,
That’s correct. It was a migration gone wrong, and thankfully there are loads of them out there, which keeps consultants like all of us in business
Pingback: Yet another reason why Hyper-V (or SCVMM) is better than VMware (huh?) « UP2V
Pingback: Opinions in IT « 227 Volts
#13 by Eric Gray on Friday, January 22, 2010 - 18:17
Quote
Justin,
Hyper-V cannot be managed with “various browsers and architectures” as you say, and this is the whole point of your article.
In fact, clients running Windows XP — the vast majority of businesses did not upgrade to Vista — have essentially no options for Hyper-V management.
Yes, it’s true. http://bit.ly/6Ur91s
Ouch.
#14 by Justin on Friday, January 22, 2010 - 19:07
Quote
Eric,
It actually can. My point was that with Hyper-V you can manage it regardless of your Operating System. EVEN with XP. If you read my entire post, you’ll see:
In Windows XP there is a program called Remote Desktop Connection (mstsc.exe). This lets you remote control a Hyper-V server…This dates back to Hyper-V’s first incarnation. You can mstsc to any Hyper-V server, be it Hyper-V on Server 2008 or Hyper-V on Server 2008 R2. Hyper-V on Server 2008 as you might or might not know came out around the same time as ESX 3.x. You can’t mstsc to an ESX 3.x installation – unless you purchase extra software. Remote Desktop Connection comes with XP, comes with Vista and comes with Windows 7 (both 32 and 64 bit).
The link you refer to simply states you can’t install RSAT on XP, which is correct. However, you still can remote desktop to a Hyper-V installation – you CAN’T do this with a VMware installation of the same age…Actually if you read the link you sent “TechTop” even points out he can still manage it with RDP.
Therefore, you’re “ouch” isn’t entirely true is it? Yep, that’s right you CAN manage Hyper-V with XP, just not using the MMC/RSAT locally, but none the less no additional costs or tools needed, unlike with VMware…
Windows XP (x86 or x64) & Hyper-V – Remotely via RDP
Windows Vista (x86 or x64) & Hyper-V – RDP or RSAT
Windows 7 (x86 or x64) & Hyper-V – RDP or RSAT
VMware 3.0 & x64 – Can’t control without additional install/tools
VMware 3.0 & IE 8 – Can’t control without additional install/tools
#15 by Eric Gray on Friday, January 22, 2010 - 20:30
Quote
You might as well just go ahead and claim you can manage Hyper-V from Linux and MacOS, too. They have RDP clients.
However, neither the free Hyper-V Server nor the (recommended) Server Core + Hyper-V have GUIs.
#16 by Justin on Friday, January 22, 2010 - 21:07
Quote
Eric,
You are correct, in that Microsoft do develop an RDP client for MacOS, as for a *nix client, I’m not to up on that technology, but as VMware is built on *nix and you work for VMware, I’ll take your word that there is an RDP client, subsequently giving you managability of a Hyper-V server from Mac, *nix an Windows. Guess that means if a consultant shows up on a Hyper-V site, regardless of their OS, they can connect to the GUI of a Hyper-V server. Is there a VMware (non web based) GUI for Mac or *nix?
As for Hyper-V on Core (by the way, can you please tell me where you find it’s “recommended” Core is used), as Core is built on Windows, you can still RDP to it and manage Hyper-V with PowerShell.
It’s actually interesting you mention Server Core. Did you know that over the last 18 months ESX 3.5 had 168 total patches (4.x has 60 patches to date), compared to 25 related to Hyper-V (that’s both V1 and V2)? And, if we talk footprint that’s 4+GB of updates compared to 73 MB…Just a few interesting facts I thought I’d share. Here are the links:
Comprehensive Hyper-V Update List
VMware 4.x product updates (60 in total – 16 considered “critical”)
VMware 3.5 patches (over 150+ patches)
VI 4 was released May 21, 2009, an average of almost 9 patches per month – a patch every 4 days. Hyper-V was released June 26, 2008 – 19 months ago – an average of just over 1 patch per month…Which seems more stable?
#17 by Eric Gray on Saturday, January 23, 2010 - 18:19
Quote
Hyper-V Best Practice:
http://technet.microsoft.com/en-us/library/dd283088%28WS.10%29.aspx
It is not feasible to separate Hyper-V patches from Windows patches. VMware published a response:
http://blogs.vmware.com/virtualreality/2009/08/our-position-on-hypervisor-footprints-patching-vulnerabilities-and-whatever-else-microsoft-wants-to-throw-into-a-blog-post.html
#18 by Justin on Saturday, January 23, 2010 - 18:41
Quote
Thanks for the reference. I’m sure as you’ll agree Core is suggested for security reasons, as stated in the TechNet article. However, with regards to your article, it’s interesting how it compares VMware’s Hypervisor and associated code with Server Core. Where is the comparison to Hyper-V Server – http://www.microsoft.com/hvs – This is simply Hyper-V. Furthermore, you’ll note that a few people have commented on that blog posting saying:
and
Subsequently meaning Eric’s reference to Patch Tuesday and his table…VMware has the same issues. I’d be interested to see the break down for the first question though…Surely that data is available?