Hyper-V virtualization - pros and cons?

Quick note - When I posted this  originally I guess I didn't make it clear enough that I was only interested in Windows virtualization e.g. HyperV and thus was looking for  Experts who were familiar and had administered such setups so the response I got was not relevant to me.  I would appreciate this time around  only people with HyperV experience responding. Thanks.

I am familiar with administering Windows networks that have physical servers and have experience in troubleshooting server crashes in these 'real' environments and carrying out recovery in a variety of situations. As far as virtual machines with virtual hard drives - again in the Windows environment -  I have some questions:

1) The bad - what types of thing can cause a crash on a virtual machine/virtual hard drive that would never be the case on a physical machine/hard drive?

2) The good - what types of things that would crash a physical machine/ hard drive would never crash a virtual machine?

3) The bad - what new recovery techniques might be required for virtual machines/virtual hard drives that were never required on physical machines/hard drives?

4) The good - what  recovery techniques can I throw into the legacy memory pool with virtual machines/virtual hard drives that I needed for physical servers/hard drives?

A couple of qualifiers.

a) I know my questions are open-ended so I don't need an exhaustive list for each answer - top 3, top 5 type of thing is enough - not worried about totally obscure rare situations - good links to clear info is as good as an answer

b) My overall sense is that with virtual machines and virtual hard drives as opposed to their real brothers and sisters is that the rule of thumb is 1) less problems 2) easier to recover from when they do happen. Is that general idea correct?
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

Michael OrtegaConnect With a Mentor Sales & Systems EngineerCommented:
1) As I mentioned before you can backup your VHD's with a "pay-for" application or simply with Windows Server Backup. Windows Server Backup uses vss writer to backup the entire host system volume or individual files. I use Windows Server Backup as a supplemental backup. It backs up the entire physical server volume where my VM's reside. In fact, I make it an effort to keep that entire volume clean with just the VM's that way it keeps my backup image as small as possible. Windows Server Backup actually backs your entire volume up as a "VHD". You can use some free vhd mount tools to them mount the VHD and pull your individual VM vhd's out of the backup image to restore. Easy squeezy!

2) I have never had an issue with VHD corruption although I have seen others with the problem. We have several different virtual server deployments in all shapes and sizes. You troubleshoot the VHD exactly as you would a physical server implementation. I've even seen complete corruption where the VHD has been sent to a disk forensic specialist just like a physical disk is. In those cases it's actually easier to recover the data on VHD than a physical disk where RAID is involved. The processing of rebuilding a physical disk array is actually virtualizing the disks and using some crafy tools to rebuild a virtual array.

3) No snapshots, because 1. they consume too much disk space 2. the VM is now dependent not only on it's own state but the state of the snapshot as well 3. Overhead you don't need to worry about. Below is a quick read link. You suggests that snapshots might be good only the in case where you want to roll back after some bad updates are installed. I haven't really had an issue with bad updates where requiring snapshots would even be worth the management unless you use them specifically during a scheduled update and then quickly turn the integration feature off.

4) Difference disks? I'm not sure what you're asking here, but my best recommendation is plan your VHD size with your available physical server disk capacity. I know that seems obvious, but it's easy to miss during the configuration if you're using dynamic sizing disks. Again, I recommend fixed disks because there's no mistake what the total will add up to. If you do dynamic just make sure you know the max size on all your VHD's and plan for the summation of those max sizes to not be larger than your physical disk capacity.

Hope some of this input helps.


Michael OrtegaSales & Systems EngineerCommented:
You're first two questions could really be argued as that there are no real benefits in terms of exposure to crashing or failure. Your physical server hardware crashes the virtual servers on that same physical server crash as well. The operating system environment may be well in tact, but the server is definitely down for the count until the physical hardware is repaired or the virtual server is moved to different equipment. Some would argue that at least the virtual operating system environment is not exposed as much to issues related to driver corruption or failure because of the generic contruct.

People move to virtualization for different reasons:

1. Server consolidation
2. Better use of hardware resources on physical servers
3. Portability of virtual servers
4. Easier management of disaster recovery

The list goes on.

Answering question 3: All current backup solutions really cater to the virtual world. Backing up your server and preparing for disaster recovery is a forever evolving obstacle. Your needs continue to grow, applications change, etc. Virtual Server backup is easier than things were before, but can also be as complicated. It really depends on what you want to recover. If you say you just want to recover the server from yesterdays' backup and that's all you'll ever need to do then backup is easy. Simply prepare physical server for nightly backups of all VHD's. If you need something more granular, e.g. Exchange MLR recovery, then you'll need to leverage a different backup solution within the virtual operating system itself. Perhaps if you defined what kind of recovery you were looking for I could focus down on preparing your environment for that.

Answering question 4: What exactly are you asking? Can you elaborate?

Respondign to qualifies b: I wouldn't necessarily say that there are "less problems", but rather different kind of problems most of which are easy to overcome. Again, proper planning of your environment is critical to avoid major issues. Recovery is easy in some definitions of the term and just as complicated without virtualization in order definitions.

lineonecorpAuthor Commented:
Thanks for all the info but it is general info I already know. I was hoping for some very specific answers and that is why I went to the trouble of breaking everything down to points.  I would really like answers very specific to the points asked - and if there is no answer or there is no difference fine then it should be just said. So for instance the first question:

1) The bad - what types of thing can cause a crash on a virtual machine/virtual hard drive that would never be the case on a physical machine/hard drive?

What I wanted was  a situation that could cause a problem in the virtual world that wouldn't happen in the physical world?  I understand that if the physical server goes down of course the virtual servers would go down.  My question is addressing whether there are situations where there is nothing wrong with the physical hardware but the VM goes down because of some 'virtualization' glitch or perhaps there are some specific problems with VHD's that get corrupted but there is nothing wrong with the underlying hardware, the actual disk itself.  And then if that happens what would I do to fix it - run some kind of virtual version of fdisk or run fdisk itself? What happens if the VM file gets corrupted? How wold that occur and how would it be fixed? That is the flavour of answers I was looking for. And if you are sure that these kind of problems unique to virtualization don't exist then I will take that as an answer.

Hopefully this will make clearer the type of response I am looking for.
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

It seems your asking objective question and want situational (subjective) answers. A difficult tasks indeed. Lets see.
1)I would say, you have to look at the way things are used in the virtualization world, compared to the physical world. For example, physical HDs and VHDs, one instance that you cannot have in the physical world that you have in the virtual world is differencing disks. Therefore, the things that can go wrong with differencing disks, won't be present in the virtual world. Extending on the same idea, the snapshots are sorts of differencing disks, but have configuration and state information as well. Thus issues with snapshots are exclusive to VW.

Are you looking for something like that?

Michael OrtegaSales & Systems EngineerCommented:
I thought I was pretty specific with my answer to points 1 & 2 - "...there are no real benefits in terms of exposure to crashing or failure." Your updated post states - "...and if there is no answer or there is no difference fine then it should be just said." I'm pretty sure that's exactly what I did.

In fact, I went on to give you points as to why people migrate towards virtualization. Environmental stability is not really the primary focus. It's certainly not any less stable than a physical server OSE.

Point 3 asked for special recovery techniques and I was even more specific about that. First determine what you want to recover. Full server recovery, Message Level recovery for Exchange, etc. If you want just full server recovery from a previous nights backup then my answer is pretty clear.

lineonecorpAuthor Commented:
I would say that msmamji is right on track for my question with the business of differencing disks, snapshots, etc. which I read up on as a result of the hints.  There are pluses for those compared to the real world - on the other hand they can mess up your configuration in such a way that it would have been impossible to do in the 'physical' realm.  

Further examples I can think of with the additional reading I have done::

In the physical world, you OS can get corrupted in some way - e.g. bad update and ditto for the virtual world. But in the virtual world there is an actual file that doesn't exist in the physical world - the VM configuration file  nested deeply in a directory with a strange name. Well, any file can get corrupted so I am assuming that if this file somehow got corrupted - well, I would now have a problem I would never have seen on a real world and would have to put in place a recovery that I would never had to know about in the physical world.  So does this happen and if it does how is it fixed? How is it monitored for proactive prevention?

As far as VHD's goes, again it's a file and in theory a file can go bad even if there is nothing physically wrong the hard drive it's on. For instance, profile files or database/database index files get 'corrupted' and have to be rebuilt - it's a software glitch, there's nothing wrong with the underlying hardware.  So what kind of VHD errors of that 'corruption' kind could I run into and what tools are there to fix it? Some kind of special chksk/partition repair tools for VHD's whose MBR or partition table have somehow become thrashed? Again nothing wrong with the hard drive itself, just the software configuration.  So is this a possbility and if so how can I preventatively monitor and if it does happen fix?

Hopefully the above will make it clearer what types of things I am looking for and if more can be thought of I would appreciate further examples.  Note that I am 'deducing' all of the above examples - I do not have any experience with them so they may be farfetched or not even possible - I'm trying to anticipate the worst.  If in fact none of these situations can actually happen  then I would appreciate knowing that.

Michael OrtegaSales & Systems EngineerCommented:
Never have had the virtual machine configuration file corrupt on me before, so I couldn't tell you what would possible cause it except possible some event from the physical server itself. No big deal though. The file just simply holds your configuration informatin for the virtual machine. Within a few minutes you can complete reconstruct configuration within Hyper-V manager or SCVMM (whichever you use).

Just making a comment in relation to your first paragraph on the most recent post...
I mentioned that planning was important. Snapshots are never an issue in a virtual environment because they are never recommended on production machines. You should never have that integration feature enabled on your live systems. If you want information on best practices I would be happy to comment on that. You question specifically was what problems would you experience in the virtual world that you would never in the physical world. The answer really is that you wouldn't if you configuration your virtual world properly.

In terms of VHD's corrupting. It can happen just the same as it can happen on a physical volume. You would use the same tools as dealing with a physical volume, e.g. chkdsk, repair installs, etc. Like I mentioned before anything that can go wrong with your volumes on your physical configuration can also happen in a virtual configuration with the exception of issues related to an array controller, etc., because there is no such thing in the virtual world.

Another thing to avoid in your configuration is using dynamically expanding vhd's. You can use them but make sure the summation of all your expanding vhd's do not account for more than your actual physical volume capacity. I recommend using fixed size VHD's. Better performance and you don't have to worry about sizing them for more than the available physical disk capacity on the host machine.

Backing up VHD's are easy. You can use a ton of volume imaging backup solutions or even Windows Server Backup (equivalent of NTBackup in Windows Server 2008). If you need to backup moving components (Exchange, SQL, etc)of your virtual servers you'll have to approach backups as if you were backing up several physical servers, e.g. Exchange & SQL aware backup applications.

One important thing to consider with virtualization is the portability you get. I've had complete physical servers die unexpectantly that were hosting various virtual servers. Within minutes I had my virtual servers running on totally different hardware, and that's the fabulous thing about virtualization. You're totally portable because of the portable construct of the virtual hardware in the virtual machine. There are pro's and con's to everthing though. If you need high availability you are not going to accomplish that with virtualization alone. Your downtime exposure may be less because of the generic contruct of your virtual servers, but now you have 5 or more servers running on a single physical point of failure. Make sure to really beef that physical server up with plenty of redundancy, e.g. redundant power supplies, RAID, etc. You can even do failover memory on the new servers. For truly high availability applications you'll most likely have to bring in a 2nd physical server and setup your application redundancy there, e.g. SQL clustering, Exchange clustering, etc. I would recommend a SAN solution for something like that.

Tons more to discuss on this subject really, but I don't want to just keep aimlessly typing up stuff. If you need more info just ask.

One experience of mine. I had quite a few exported VM most probably from WS08 R2 Hyper-V and probably exported using SCVMM(part of  beta MOCs I was testing). When I imported them on a WS08 Hyper-V, one set worked flawlessly while the other one failed. I couldn't get them to work. I downloaded the hold set again(12 GB).I tried a hotfix from microsoft. It just changed the error given. I even tried to use just the VHD. It just wouldn't work. I used vhdmount to check if the VHDs were corrupt. The VHDs mounted just fine.  I searched the MCT Private newsgroup and found a few ppl with the same problem. It was concluded that the WS08 R2 Hyper-V exported VMs might not work on WS08 Hyper-V. I am OK import being failed but why on earth would the VHD not work. Well I just gave in ( I didn't have a WS08 R2 Hyper V available at time).

This again is an exclusive issue to the virtualization world.

Michael OrtegaSales & Systems EngineerCommented:
Shahid are you saying that you used SCVMM to do your P2V conversions, initially opened those VM's on a Hyper-V server running R2 (2008) and had no problem? And then tried to run those same VM's on a non R2 release of Hyper-V, but had problems?

If I have that right then I guess I can't relate. All our running Virtual Machines are running on non R2 machines originally or were converted and ran directly on an R2 server. Not really a problem though as much as it is perhaps just a prerequisite for doing this. It would be same as you saying that you ran an XP SP3 compatible application on XP SP3 fine and then tried to run it on XP SP2, but had problems. Not really a virtualization issue but an application compatability issue.

Perhaps better planning could've prevented your problems. No offense intended, but I'm trying to be clear with what issues are geniunely a problem that could parallel problems experienced in the physical server world. This, again, just sounds like an application compability issue.

Michael OrtegaSales & Systems EngineerCommented:
Meant to add:

"No offense intended, but I'm trying to be clear with what issues are geniunely a problem that could parallel problems experienced in the physical server world, and which are unique to the virtual world."

I would globally state the issue is "because things are virtualized", but rather you have to consider compatibilty and prerequisites with all applications.

Maybe I did a bad job about communicating the issue.
What I am saying, I had some exported VMs. Initially, I didn't know that they were exported from R2 version of hyper-v (Since they were downloaded from the MCT site as a part of a MOC, which was in beta and I was trying to get it run and submit feedback on it). I tried importing them into a WS08 Hyper V server and failed with some VMs not importing. On digging, I found out that these VM were exported from a WS08 R2 Hyper-V Server. Skipping to the end here, I found out that VMs that are exported from R2 version of hyper-V have a fair chance of failing to import on R1(since some worked and some didn't but they all were exported from a R2 version of Hyper-V).  I was trying to point that this is something to look for when managing Virtual environments having both versions of hyper V.

As I found out, I was an issue with the VHDs, the import would fail complaining the VHD is corrupt. However, when i mounted the VHD using vhdmount, it would mount just find, with a proper filestructure. Thus I figured the VHDs created using R2 are in someway different from the one created using R1.
This is something I experienced and thought I should share.

Hope it much clear this time around.
Michael OrtegaSales & Systems EngineerCommented:
I understood your post. I guess I just didn't realize that the author wanted an "obscure, rare" scenario such as that. I mean you downloaded the VMs as part of a MOC which was in "Beta" and tried to run them in a pre R2 environment inspite of their being known compatibility issues.

Again, no offense, but I'm trying to keep to the authors points.

lineonecorpAuthor Commented:
I didn't want obscure but I appreciate the effort. As I indicated I wanted a top 3, 5, 10 type of situation.  So what I have to date from your posts is the following top 4 of  'what can go wrong with HyperV that can't go wrong with physical is:

virtual machine file gets corrupted - (for non-physical reasons)

In this case the answer was 'recreate'. As opposed to trying to recreate something from scratch wouldn't it be possible to have backup configurations of all VM files that I could 'copy back' from archive if necessary? So where are they stored and how would I get them into action - just copy over?

vhd gets corrupted - (for non-physical reasons)
Answer I got was use the regular tools such as chkdsk.  Any references to their usage with VHD's specifically?  Have either of you ever had to do this and had no problems?


Answer: not a good idea on a production server.
Why?  Did they really design this tool just for non-production servers?

Difference disks

Any gotcha's with these? Also not for a production environment?

Links to answer any of the above questions are good.

If you have personal experience with the above good as well.

If the above  made clearer the type of info  I wanted and triggered some more areas to add to the list that would be good as well.

lineonecorpAuthor Commented:

Anything to add?
msmamjiConnect With a Mentor Commented:
Just a few.
Coming back to the original question.
Since networking in Hyper-V is different from the physical world. You might run into issues which are exclusive to VW. One thing that comes to mind is MAC duplication, where multiple Hyper-V servers allocate the same MAC address pool to themselves leading to VM having same MACs. This is rare and happens only when you deploy hyper-V server using images. Possible remedy are to install hyper-V after deploying images.

I am only stating this as answer to the original question. This normally doesn't occur in the PW (but can occur if MAC address is changed using NIC properties - Reason is entirely different for MAC duplication here).

Other then that I was thinking about issues when Hyper-V is coupled with other products like VMM, OM, DPM but I think that is not your concern here.

Hope this was relevant and useful.
All Courses

From novice to tech pro — start learning today.