Okay. Let’s see the patch list and reboot requirements for vmware in comparison. I like to see the big picture

and

We’ve been patching ESX 4 and ESXi 4 roughly once a month. Because each ESXi patch is distributed as a full installer image, a reboot is required each time

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?

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

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?

However, neither the free Hyper-V Server nor the (recommended) Server Core + Hyper-V have GUIs.

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:

remotely with RDP

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

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.

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

Avoid frequent memory reclamation.

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.

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:

Avoid frequent memory reclamation. Make sure the host has more physical memory than the total amount of memory that will be used by ESX plus the sum of the working set sizes that will be used by all the virtual machines running at any one time.

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?

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.

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:

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.

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.

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.

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.

Let’s look at some things you say:

You do know that ESX3.0 has been end of general support for over a year, right?

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.

You do know that the “work around” for Windows 7 takes 30 seconds to implement, right?

My point exactly…there shouldn’t need to be a “workaround”

You do know that the vSphere Client no longer needs the “work around” to install under Windows 7, right?

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

You do know that you could have RDP’d to the Virtual Center Server to run the VI Client, right?

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.

You do know that the VI Client (the old one that goes with ESX 3.0) runs in “XP Mode” under Windows 7, right?

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.

You know it was Microsoft that chose NOT to support legacy 32-bit applications on Windows 7, right?

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

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.

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:

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.

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.

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.

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.

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.

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

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

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