Generally spring is the time for cleaning, but for me it came early this year because one of my hard disks failed after only 4 months of service. It also happened to be the hard disk that contained all of my VM’s, quite annoying but I had backups. All of this lead to a rethink and a decision to replace my broken hard disk with 2 mirrorred hard disks. As these were both new, I decided to use 2 different brands of the disks in case some kind of factory problem was going to cause these to fail on the same day.
Installing the new disks into my trusty HP server was easy, it can hold 4 disks and it has support for Hardware RAID. I have a spare slot still and I will put the RMA’d failed disk into that when it arrives and use it as a backup device.
The net result of all this thinking was that some thinking and re-arranging of stuff was going to leave me with new drive letters for my Hyper-V area, as a result some configuration changes are needed to pull this off. On the net I’ve seen several somewhat hacky ways to do this but I wanted to do it what I think is “the right way”.
This is the approach I took:
- Export each of the VM’s to the new disk using the Hyper-V manager’s built in Export feature which I would say 2 things about:
– is rather slow to be polite. I am certain it would be faster if I paid an exhorbitant amount of money for expensive disks but still this is SATA-300 to SATA-300 on the same machine and exporting 120GB took somewhere over an hour.
– in general there should be an optimized way to just “move a VM” along with all its stuff. Exporting is more made for moving between machines.
- Delete the VMs in the Hyper-V manager (gulp)… gotta hope that export was successful.
- Change the Overall hyper-v settings to point at the new mirrored drive/paths.
- Import each of the virtual machines. This is very much faster than exporting thankfully.
This all seems pretty obvious, there’s likely a better way, the trouble is that Hyper-V is doing so many clever things with differencing disks and stuff all the time that just copying the VHD hard disk file is never going to work.
All of this wasn’t admin for the sake of Admin.. These problems have lead me to re-think the way I back up. Previously my main network server with lots of important stuff on it (which happens to be Windows 2003) was always backed up from the “inside”, e.g. it was running backup jobs on itself like it was a normal machine. This meant that when I had to restore it was really like doing a BMR (bare metal restore) and that took an age to do, I did have backups of the VM configurations and disks from an earlier point but they were out of date with my daily inside backups which left me in no-mans land a bit.
Usually I use Acronis to back up, but I’ve actually been having some problems because of patchy windows 2008 support meaning the Hyper-V area doesn’t back up properly (some kinds of VSS problems). My new thought is that I’ll use the build in Windows Backup system to backup the entire system to a hard disk, while still using acronis to back up critical files to an off-site location.
In essence, I’m feeling that when using Hyper-V “outside” backups of the VHD and associated files are going to lead to much faster recovery, but.. at the same time, outside backups are pretty lousy for restoring individual files/data inside the virtual machines, so I will have inside backups for those tasks.
My feeling is that somebody should capitalize on this, its probably not a lot of work, most backup catalogs can be browsed by the tool that makes them, if that browsing and restore ability was extended to include the inside of VHD files (while managing the associated snapshots) we’d be in much better shape for a unified backup solution..