- Jun 02, 2011 by the_angry_angel
- Virtualisation, Linux, Hyper-V, Debian and Ubuntu
Whilst it's possible to get Debian, and by proxy Ubuntu, running under Hyper-V it's nice to see that Microsoft are potentially going to officially support them along side CentOS, Red Hat and SuSE.
As someone who is running Debian and Ubuntu under Hyper-V I would heartily welcome this official support.
Sadly I suspect that if Gupta really does represent Microsoft's view, then the odds of getting on the official list is probably going to be quite low;
"Gupta says Microsoft is drawing the line at 'touching' the Linux code. It won't provide patches."
I'm afraid that for this blog entry you're going to have to sit through some "bullshit-back-story".
For whatever reason our live cluster, running under System Center Virtual Machine Manager (SCVMM) 2008 R2 had gained duplicate copies of 3 virtual machines, and all the duplicate VMs (Virtual Machines) were marked as missing.
SCVMM is a relatively new "toy" for me, however I'm already starting to feel the love-hate relationship growing, probably indicated by the fact that I'm referring to it as "scum" to my co-workers and friends. My point being forgive me if this is common knowledge. It doesn't appear to be.
Delving deeper the Failover Cluster Manager MMC was showing only a single copy of the virtual machines in question. That narrowed it down to just SCVMM being the problem child. All attempts to perform a repair, or even an attempt at removal (despite my better judgement) in SCVMM itself resulted in a bullshit error message. Frankly a restore at 23:00 isn't exactly what I'd want to have been doing any way, so I was somewhat pleased by that.
Poking further there appeared to be a MS KB (KB2308590) that directly addressed this problem No joy.
So, doing what I always do in these situations, I started prodding at the database that powers SCVMM, using SQL Studio Manager. Yeah it's a GUI, but it was nearly midnight, and it was easier.
If you're using the default database you'll want to connect to COMPUTERNAME\MICROSOFT$VMM$. Otherwise it'll be where ever you specified at install. The table that interests most of all is the tbl_WLC_VObject. If you select with a where statement to find your problem machines you should fine that you have duplicate entries. Carefully choose the entry that is not running, and delete it. Luckily our duplicates had no tags, and no owners, so it was actually fairly easy to figure out which ones to remove. Close and reload the SCVMM console and you should find that you have a less scary looking SCVMM administration console.
I'm sure that there are some bits left behind in other tables that are referencing the VMs, however I'm going to bed. It can be tidied in the morning.
At work we've been virtualising stuff for a long time, perhaps longer than most, but I'm still coming across companies and sysadmins that either don't know about virtualisation (inconceivable!) or have written it off as a fad. That really does surprise me.
The feature that many of these people and companies are missing, in my opinion, is that virtualisation is not just a solution (for business needs). It should be a core part of your toolbox. You need to tear down that physical SQL server and upgrade the OS and application version numbers? It's a core box, but the customer doesn't have the budget for another one? Having a back out solution is highly desirable? Virtualisation.
Run your backups as normal, convert that bad boy to a virtual machine, test it, and then start ripping that physical server a new install. Everything goes tits up (and it wasn't your fault), come Monday morning you won't have an upset customer and you can continue to work in (relative) peace and look awesome to your customer.
If you know about virtualisation, but don't do this because you think it's hard work then I suggest you need to re-evaluate the state of P2V tools. If you're running Hyper-V and the source install is also Windows then I highly recommend Sysinternals Disk2VHD. Occasionally you need to re-create the VHD or massage its output with testdisk, but you always test first.
Clonezilla is another great tool, and not just for P2V. There are a whole host of other tools designed just for this purpose. Some free (in both senses of the word), and some not so.
If you're using a combination of a scripting language, diskshadow and task scheduler to backup your Hyper-V machines take special care to make sure that task scheduler does not cut off the job whatsoever. Doing so can cause the host server to crash out, although it doesn't seem to be perfectly repeatable I've been able to track down an issue we were having at work where the power was blipping at a customer's site very briefly causing task scheduler to stop the job which immediately crashed out the host box. Unfortuantely it only seems to crash out in this circumstance, when attempting to backup certain virtual machines, although I'm yet to figure out a pattern.
Removing the "stop task if computer goes onto battery power" option and then ensuring that the UPS interface software takes care of it when the battery runs low is a good enough solution for us, for now.
Following up to yesterday's post on LXC: Linux Containers, I had a quick play with 2 ULA subnets (aka RFC4193 addresses - dont forget that site-local was depreciated) - one subnet was dedicated to the LXC containers, one for my normal LAN. Perhaps unsurprisingly IPv6 appears to work perfectly well in this setup.
I also altered the setup and bridged a container directly to eth0 on the host node, and watched the container assign itself a stateless address based on my prefix, and again everything appeared to work perfectly well out onto the public v6 network (courtesy of Hurricane Electric's Tunnel Broker service).
So all in all I'd say that LXC is looking pretty good so far. There are a few other things I'd like to test, like how effective iptables are in the context of containers, and whether or not it is secure enough. Unfortunately I'm not going to have time to play with these things this weekend really. Answers on a postcard to the usual address if you already know though!
