Virtual Insanity: Part Three - A Quick Catch Up
by, 12th March 2013 at 03:54 PM (3231 Views)
This draft has been sitting here for ten months now. I very much doubt anyone who was following along before still gives a monkey's. However, I'm sick of EduGeek prompting me to carry on with this draft, so I'm going to write this introduction then just publish the bloody thing
I think the advice below is all still sound. It looks right, but the work was a year ago. I've done a lot in that year so have completely forgotten everything I did with the servers.
~~wibbly lines of travelling back in time, perhaps the sound effect from the TARDIS ~~
Right, this hasn't been updated in ages because I got busy with, y'know, actually doing the work, and now I've largely forgotten half the stuff I did. However, I do still want to list the bits that caught me out, as some of them have had me caught out for a while, and if I can save someone else the heartache it will have been worthwhile.
So, some tips and tricks!
* In 2008R2, use the Windows MPIO stuff. The vendor-specific things are only actually for 2003. Using them on 2008R2 will only muck your SCSI3 commands up, and it's nigh-on impossible to strip them out once they're on, so you pretty much have to reinstall your virtual hosts. Lesson learnt: the hard way.
* Use Synthetic instead of Emulated where possible. Not having this set for my NIC had me stuck for 6 days with my Live Migration.
* Storage being used by the cluster for write operations should only be visible to the cluster. Once it's set up in the cluster, drives get SCSI reservations on them and that knackers up the Virtual Disk Service on other servers outside the cluster, filling your system log with NTFS 55 and 57 errors. If there's storage that the cluster needs to see that other servers need read/write on, don't import it as cluster storage, just have it added to the servers.
* When setting up the SCOM / VMM integration, make sure you're logged in as an account that is a SCOM administrator. Otherwise the installation program will outright bloody crash with absolutely no indication that this is the problem. You may be able to use Run As; it's probably easier to temporarily shove your admin account into the SCOM admin group for the duration of your setup.
* When setting up the SCOM reporting, make sure you've actually configured SQL reporting; just installing the reporting features isn't sufficient, and again, the installer won't particularly point out that this is the issue. The error log it created was so useless that at one point it genuinely cut off mid-word. Defaults for the SQL reporting are fine.
* Again, when doing SCOM reporting, make sure your SCOM Admins group has full control for the folder you're creating the database in. What is it about enterprise software that implies error messages can be completely obtuse? How difficult would it be to put a check in place beforehand? Nevermind...
Total Trackbacks 0