Migrating from XenServer to ESXi

For the past two months we’ve been trying to migrate a bunch (90 or so) VMs from XenServer to ESXi … However for some reason on some of them, the Converter Service would crash.

VMware Converter crashing due to rsintcor32.dll
VMware Converter crashing due to rsintcor32.dll

Up till Monday, I had no idea why. I decided to look into the error once again, and this time decided just to Google the failing module… And guess what ? Out came this Citrix forum post regarding the failing module. So, after knowing that rsintcor32.dll belongs to the Citrix System Monitoring Agent service (well, I could have guessed that from the DLLs path :P) I decided to simply stop the service.

And now, we can migrate the remaining VMs to ESXi and get rid of XenServer!

XenServer 6.x: Update all hosts in pool

Well, what annoyed me in the past was that I had to patch each XenServer patch by patch (no bulk applying) and when used in combination with UCS blades (especially if those have >250GB RAM), it takes ages to keep a pool up-to-date. So I ended up writing yet another script (I know why I hate Citrix XenServer … the XenCenter GUI is lacking sooooo much) which will download new patches from a directory on a HTTP server and then print the lines necessary to apply the patches to all hosts in a pool.

There’s just a little caveat (not because of the script – but of XenServer’s design): if you switch the pool master before the updates are applied to all host, you’ll need to manually delete the patches from the pool (xe patch-delete) and rerun the script on the new pool master …

XenServer 6.x: Quick VM Protection Policy to VM name-label script

Well, today I ended up writing a short script that’ll give me a list of VMPPs with the VMs that are associated to it.



XenServer 6.0.2: Fixing Root-Disk-Multipathing with Boot-from-SAN

As the title pretty much tells, I’ve been working on fixing the Root-Disk-Multipathing feature of our XenServer installations. Our XenServer boot from a HA-enabled NetApp controller, however we recently noticed that during a controller fail-over some, if not all, paths would go offline and never come back. If you do a cf takeover and cf giveback in short succession, you’ll end up with a XenServer host that is unusable, as the Root-Disk would be pretty much non-responsive.

Guessing from that, there don’t seem to be that many people using XenServer with Boot-from-SAN. Otherwise Citrix/NetApp would have fixed that by now…. Anyhow, I went around digging in our XenServer’s. What I already did, was adjust the /etc/multipath.conf according to a bug report (or TR-3373). For completeness sake I’ll list it here:

And as it turns out, this is the reason why we’re having such difficulties with the Multipathing. The information in TR-3373 is a bunch of BS (no, not everything but a single path is wrong, the getuid_callout) and thus the whole concept of Multipathing, Failover and High-Availibility (yeah, I know – if you want HA, don’t use XenServer :P) is gone.