I’ve recently purchased a new server for our production environment and went to our preferred provider of hardware for a new server. The one stipulation I had was that is was VMWare ESX certified. I did my research and selected all my components and then purchased the server. However, after purchasing, the vendor sent me an email stating they were substituting some of the components on me. Of course, I panicked about the VMWare issue, as drivers for VMWare are not like Windows – you can’t get them from hardware sites, more often than not. Anyway, the vendor assured me the subs would still be ok.
Long story short, although they kept to the letter of the law on that, they didn’t keep to the spirit of the law, so to speak. All the components are VMWare certified – except the very expensive hardware RAID card cannot be used on the VMWare ESX OS partition. In otherwords, VMWare can still have the guests in a mirror, but the OS will be outside the RAID.
This left me with 3 choices:
I’ve always been meaning to try out Hyper-V but a production-acid-test is not what I had in mind. None the less, I am an impulsive idiot, so I am going to do it. While it’s production, it won’t directly effect any of our customers and I can wear the headache myself, for the time being, if it’s not great.
So anyway, back to the topic of the post.
I began the installation of Microsoft Hyper-V server on the box and got as far as being asked for the RAID card drivers. After providing these, I was dismayed to see that Windows was telling me it was able to see the disk, create the partitions and format them but was still “unable to install to the selected location”.
This didn’t seem fair. I have a driver and OS that can see the disks, I can work with the disks but I can’t use them? This sucks!
Being the old school guy I am, I of course went looking for newer drivers but it turns out I already had the newest. I was almost ready to give up and go for option 2 above, when I came across a little trick.
It turns out that this error message is kind of Windows’ weird way of saying “please put the Windows CD back in the drive and remove the driver CD”. It actually turns out all you need to do to continue is pull out the driver disk and put the Windows 2008 R2 DVD back in the drive, then rescan the disks. Hey Presto! You can now install to the partitions.
Personally, I find this a little silly but at least I can move on and try out my Hyper-V set up now.
I’ll let you know if I live to regret it.
PS: I understand this issue only effects 64bit installations of Windows 2008 / Windows 7. I may be wrong on this but have never tried a 32bit install and have no plans to do so.
It’s probably not a bad thing but if you’re a Windows 2000 Server (or Professional for that matter) user, it’s time to start thinking about upgrading because Windows 2000 is about to “end of life”.
Microsoft have put online a Windows 2000 End of Support Solution guide (which pretty much amounts to “please buy some more software”) here.
See this news over at Rustylime: Firefox 3 is now the #1 browser in the World.
Browser usage stats
Why not add your voice to their vote:
Giving elevated permissions to non administrative users can be a real pain, in Windows land. In fact, it can be so much of a pain that people often don’t bother, and just elevate users to have admin rights when they don’t need them.
A good example of this is when someone needs to be able to restart a service. Often, vendors need access to work on one of their applications on a server – and as part of that, they need to be able to restart a service. However, you don’t really want to hand them the keys to the server at the same time.
So instead of simply giving them local admin rights, or spending ages working with NTMon and NTRegmon to try to work out the specific reg keys and file permissions to change, how about just using Microsoft’s SubInACL tool?
It’s actually very easy to use. Basically, it allows you to modify the security settings directly related to just one service, giving an non-privileged user the ability to work with just that one application (although you can actually do much more with SubInACL than just services).
Here’s the syntax to give a user called “user1″ access to “service1″ on the server “\\domain1\server1″.
subinacl /service service1 /grant=domain1\user1 = TO
Here, T = start service and O = stop service.
Other commands include:
F : Full Control
R : Generic Read
W : Generic Write
X : Generic eXecute
L : Read controL
Q : Query Service Configuration
S : Query Service Status
E : Enumerate Dependent Services
C : Service Change Configuration
T : Start Service
O : Stop Service
P : Pause/Continue Service
I : Interrogate Service
U : Service User-Defined Control Commands
SubInACL can be downloaded here.
Please note earlier versions from the original Windows 2003 Resource Kit will not work on patched / service packed Windows 2003 servers, so this is the new version.
I recently ran a yum update on my CentOS 5.2 server, which I use to run VMware guests – really you could call it my VMware server. Every time I do this, I think to myself “should I really be doing this? Do I really need the newest kernel on this box that works perfectly?” Then I do it anyway and hope for the best.
This time, however, things did not go for the best.
Immediately after updating and rebooting, VMs went to hell. Guests would suddenly stop for no reason, the web interface kept failing and not responding (although the vmware-hostd service would continue to listen on the ports). I assumed it must be kernel related and dropped back to the last one – but to no avail.
Having no time to fix the issue, and all my VMs on a separate set of disks, I simply reinstalled CentOS from scratch, using the very latest version – 5.4. I thought to myself, “this will surely fix the problems – it’s a fresh OS”. Wrong
Long story short – glibc-2.5-42, which incidentally ships with CentOS 5.4 out of the box, is incompatible with VMware.
Here’s how to get VMWare working on your CentOS 5.4 host:
1. Go to /etc/yum.repos.d and copy the file CentOS-Base.repo to a new file. I chose CentOS53-Base.repo.
2. Edit this new file and rename all instances (in [ ] brackets) with a new name. I.e.
[base] becomes [base53]etc
[updates] becomes [updates53]
3. Replace every instance of $releasever with 5.3.
4. Save the file. Now downgrade glibc:
yum downgrade glibc glibc-common
5. Edit the /etc/yum.conf file and exclude these libraries from future updates, until this is resolved. Do this by adding the following line:
exclude=glibc glibc-common glibc-devel glibc-headers nscd
6. Reboot and re-run vmware-config.pl.
Everything should now work, once more.
There’s lots of information around, relating to how to improve VMware performance; some of it useful and some of it not so useful.
For example, it does help to be reminded to defrag your guest OS virtual hard disks – but being told that fibre channel is faster than DAS is a little pointless, when you’re trying to improve the speed of your personal VMware box and don’t have the budget for such things.
So with this in mind, I’ve collected bits and pieces that I have found made a big difference to performance, without having to spend money on hardware.
Firstly, the Guest OS:
1. As mentioned above, where appropriate, always keep the virtual disks de-fragmented.
It does make a small improvement to performance and disk size. Obviously, the more fragmented the disk, the worse the performance and the bigger the file size.
2. Use the minimum number of CPUs per guest OS.
Contrary to “real” computers, more processors does not equal more power. In fact, it can equal less power. If you have a dual or quad core host system, synchronising your cores across the guest OS, with the host OS’s use of them is actually likely to degrade performance, not enhance it. A CPU can only process one thing at a time (albeit pretty damn quickly), so each instruction has to queue and be run in synchronisation. It’s likely that if you try your guest with just one CPU, it will perform better than if you try it with two. Especially if you are using more virtual CPUs than you have physical.
3. Always choose the SCSI disks over the IDE.
As can be seen here, a virtual IDE controller will use more CPU load than a virtual SCSI controller.
4. Always install VMware Tools on the guest OS.
It allows the guest to stay in better communication with the host and will help.
5. Pre-allocate disk space.
It’s faster but it makes the storage requirements more of a problem. Your call.
6. Disable anything you don’t need.
A guest VM does not need visual pretties, high res wallpapers, screensavers, etc. Turn them off. You don’t need a fancy Matrix-style screensaver that requires 40% of the CPU and 512MB of RAM, on a screen no one can even see. Any services you don’t need, as well.
7. No RAID.
There is no sane reason why the guest OS needs virtual disks in a virtual RAID. This makes no sense – they’re almost certainly just files stored on the same physical disk or RAID anyway – let the Host OS worry about RAID.
8. Don’t use Snapshots.
They really slow Guest OS systems down.
Speeding up the Host
There’s only so much you can do on the guest, to make an impact, if the host is running slow. So let’s address what we can, there, as well. You’re likely to find a bigger impact on the Host than the guest.
1. Set up the hard drives in the most efficient, fastest fashion.
Obviously, a slow software RAID is going to degrade performance – but you may not have a choice. I myself use a software RAID-1 on my VMware Host because I am willing to sacrifice some performance for peace of mind and i don’t have the money for a real RAID card – but I acknowledge the performance will be degraded.
2. Don’t over use resources.
You have a finite amount of RAM and number of CPUs. Deal with it. Don’t allocate 10 VM guests, with a CPU and 2GB of RAM each on a dual core PC with 4GB of RAM and then complain things are slow. If you care about performance, then allocate 1 CPU to the Host OS, and 1 CPU per guest. Ensure the Host OS has enough RAM to do its job and don’t allocate more RAM than you have, physically.
3. The Host OS must be minimised.
The Host OS should not need to run a web server, etc, etc. It should be a VMware server. That’s all it should be doing. Don’t install junk you don’t need and, if possible, don’t use Windows as the Host OS. This is because you can squeeze a lot more performance out a Linux host, with a much smaller footprint. You won’t need to run anti-virus products, etc, which all hog memory and CPU cycles.
4. The Host OS should be maximised.
Maximise the performance of the Host OS and the way VMware Server 2.x interacts with it. See below for practical ways to do this, right now, with next to no effort. They make a very noticeable performance.
5. Disable power management on your Host OS.
If you’re running Linux, compile the kernel to use noapic, (you may need to do this anyway, on an AMD chip). See the link (also on this blog) as to how to do this.
6. Synchronise the CPU speed on the Guest and Host systems.
See this entry (on this blog) as to how to do this.
7. Set the Host system BIOS up for maximum performance.
There will almost certainly be an option in your BIOS for maximum performance. Basically, this sets the CPU timer to be constant, not cycling down to conserve heat / power, etc.
8. Separate physical disks for OS and VMware Guests.
This way, the OS read / writes don’t interfere with the VMware guest disk I/O. Obviously, the faster the disks, the better.
9. Make some config changes to your Host VMware Server.
Out of the box, VMware works fine – but performance isn’t great – especially disk I/O. The below changes make significant improvements over default performance.
Changes to the VMware configuration (assuming Linux Host OS).
1. Edit the /etc/vmware/config file. Add the following:
tmpDirectory = "/tmp/vmware"
mainMem.useNamedFile = "FALSE"
sched.mem.pshare.enable = "FALSE"... Read more
MemTrimRate = "0"
MemAllowAutoScaleDown = "FALSE"
prefvmx.useRecommendedLockedMemSize = "TRUE"
prefvmx.minVmMemPct = "100"
Basically, what we’ve done here is set a new temporary directory for VMware to use (we’ll come to this in a minute). Then we’ve told it use no more memory than we actually have and to stop sharing it between guests (much faster), not allow memory trimming and cut out sharing of certain resources.
2. Give VMware it’s own temporary location (swap) for files.
As you see above, we’ve defined a new location for VMware to keep it’s swap info, instead of in the regular file system. Aside from the above, we now need to make a location “/tmp/vmware“. We then create the following entry in /etc/fstab, so we can define this location as new file system:
tmpfs /tmp/vmware tmpfs defaults,size=100% 0 0
Now Linux knows this location is a temporary file system – think of it a bit like a swap file.
Once you make the changes above, you can expect to see a reasonable performance improvement, as opposed to a “vanilla” VMware Server 2.x environment. I can personally attest to a really noticeable disk I/O improvement, especially on Windows based Guest systems.
I just came across a situation in a client site where an SQLExpress (2008) instance was stood up by an unknown person, who did not leave an SA password and removed the local admins from SA access. He then left the organisation and is no longer contactable.
So how to get back access to the SA account?
1. Firstly, we need to shutdown the SQL instance and set the system into SingleUser mode. This is done as follows:
a. Run the SQL Configuration Manager.
b. Right click on the relevant instance and select "properties".
c. Select the advanced tab.
d. Select the start up option and append ";-m" (no spaces and no ") to the end of the line.
e. Say ok.
f. Stop and start the instance.
2. Now go to the command prompt and reset the password:
a. Start > run > cmd
b. At the command prompt, run "osql -S Servername\SQLInstanceName –E".
c. This will open a prompt window with a "1>" in it. Use these commands.
d. 1> sp_password NULL,’new_password’,’sa’
e. 2> go
f. 3> quit
3. Now go back to the SQL Configuration Manager and undo the above change (stop the service, remove the “;-m” and restart the service.
4. Tada – SQL SA password is changed, even without the local admin group being SA enabled.
Windows XP used to allow you to remove hiberfil.sys from within the power management options, under control panel. There’s little point going over how to do this as it’s well known and well documented.
However in Vista (and therefore Windows 7), Microsoft push hibernation and sleep far more aggressively and don’t provide a GUI way of turning it off. This is a real pain in the butt, as the hiberfil.sys is likely to be about the size of your physical memory – in my case 16GB. So I am wasting 16GB of space on my system drive for a feature I will never use. Not cool.
None the less, it is easy to disable and get your disk space back.
Just open the command prompt and enter:
powercfg.exe -h off
That’s it. Hibernate should disappear from the shutdown menu and the disk space should be cleared up straight away.
Ok, it’s time to get 1990’s on yo’ ass. I admit this post is old news but sometimes it’s better late than never.
Anyway, on occasion, you may wish for the ability to log into to other Linux boxes or securely copy files between Linux boxes, using SSH, without being prompted for passwords. I.e. scripts. In my case, I wanted to copy the contents of my CentOS web development directory on a VM machine back to the VMWare Server 2 host system, so that I have an extra backup, that’s “not on the same machine” (it is actually a physically different disk and it’s not in the same config so despite sharing hardware, this is sort of true).
Anyway, enough background. Here’s the how.
Step 1. Log into the source computer. I.e. the computer that will run the script.
Step 2. Generate some SSH public keys as follows.
ssh-keygen -t dsa
Step 3. Load the newly created public key to the destination server, as follows.
ssh-copy-id -i ~/.ssh/id_dsa.pub user@destination.servername
Please note: user should be the same on both boxes.
Step 4. Test it out by trying to SSH to the destination server.
Step 5. Test copying your files. Here’s an example:
scp /backup/friday/* root@192.168.1.1:/u02/backup/webdev/friday
That’s it. You should now be able to use SCP to securely copy files between machines with no password prompts.
When you remotely connect to a computer on a slow link, the last thing you want is a high res vendor background, which takes minutes to load. Dell, HP, Compaq, etc all seem to do this.
Oddly enough, this background is unlikely to be related to the actual user’s own background so removing it shouldn’t be a problem. It’s also easy to do. Here’s how:
Step 1: Connect to the remote computer’s registry. You can either do this by logging into the computer, if you have to or if you are on the same network, as below:
1. Open regedit by clicking Start > Run, then typing Regedit.
2. Go to file and select Connect Network Registry.
3. Type in the PC name.
Step 2: Modify the following registry key:
HKEY_USERS\.DEFAULT\Control Panel\Desktop
by clearing the entry that is currently there.
That’s it. Now when you RDP to the computer, you won’t be slowed down by an overly large image.