• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 371
  • Last Modified:

Virtual machine failure distinguished from physical machine failure

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?

1 Solution
lineonecorpAuthor Commented:
Just to add a little bit of 'real' world detail to this let's say my current environment includes 3 physical servers - a DC/file server, an Exchange Server that's also a secondary DC and a TS server.  What unpleasant 'early morning' surprises will I avoid if I virtualize this type of network? What unpleasant 'early morning' surprises will I encounter that I would never have seen before?
1. Not enough resources on the host. Obviously if the host cannot support an infinite number of virtual machines(VM)s. This is probably the biggest one. Other than that, pretty much whatever you can do to crash any computer will work in you VM
2. In terms of the VM, it doesn't have to worry about physical hardware. You can connect to a VM at a remote server with your laptop, and then if you laptop burns out or something, the VM remains completely intact.
3. I know on VirtualBox, if you have a dynamically increasing virtual hard drive, it can keep a large size even if you delete files in the VM. At least with VirtualBox, so you can go through a process on the VM to nullify any bytes that aren't being used, and VBoxMange it so they get delete from the actual image file. It just scans and if it sees any null bytes in the virtual machine, it deletes them.

4. Whenever I need to recover data, I use a linux live cd to 'see' the HDD. This works just as well with VMs Always helpful.

You have less problems after they are set up and configure them, especially if all the equipment on the host is working properly, so yes.
VMs allow snapshoting, so if i snapshot at point A and then delete '/' or 'C:\' folder, at point B in time, you can restore the VM to point A with a command or two. You can do this on the host for a lot of cases(version control), but it's not the same as knowing the ENTIRE computer is completely backed up.
Other than that regular recovery tools would also work.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

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.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now