Line One
asked on
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?
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?
ASKER
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.
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.
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?
Regards,
Shahid
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?
Regards,
Shahid
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.
MO
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.
MO
ASKER
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.
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.
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.
MO
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.
MO
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.
Regards,
Shahid
This again is an exclusive issue to the virtualization world.
Regards,
Shahid
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.
MO
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.
MO
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.
MO
"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.
MO
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.
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.
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.
MO
Again, no offense, but I'm trying to keep to the authors points.
MO
ASKER
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:
1)
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?
2)
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?
3)
Snapshots
Answer: not a good idea on a production server.
Why? Did they really design this tool just for non-production servers?
4)
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.
1)
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?
2)
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?
3)
Snapshots
Answer: not a good idea on a production server.
Why? Did they really design this tool just for non-production servers?
4)
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
msmamji:
Anything to add?
Anything to add?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
MO