Todays episode is … screwing up your test environment and fixing it. As many know, I test management tools like some people switch socks. I have a simple theory on it: If what I’m using could be better, and there’s no business impact in switching, I’m going to switch. I went from Groundwork Open Source to Spiceworks 1.0 (see my prior post here) to Hyperic. Spiceworks 2.0 is out (and has been for some time) and it’s even spicier than the last version, although the Chili Peppers were missing for a while. So time to put it into the demo lab, right? Absolutely! A little short on time? Of course! In so being, I hosed that Spiceworks 2.0 demo box from sheer stupidity. And I mean sheer stupidity. I didn’t follow any best practices. The worst thing I did was putting the app on a default XP build image. It didn’t need to be on a server OS for the initial testing phase, and I had a blank XP image ready to go. To channel my Inner Yoda: Saved myself some setup time I did. Hosed myself in the long run I had.
The default image for an XP Virtual Desktop is 8 GB in size. This is just enough space for the applications to be installed and to have room for updates, patches and whatnot. It makes maximum use of disk space on our NAS box without leaving the XP machine’s disk too stripped for future expansion. Or so I thought.
As it turns out, Spiceworks eats up disk space, about 4 GB for the one subnet I have it scanning. I didn’t have the helpdesk module in use except for my own testing, so that space count doesn’t include tickets with attachments. Considering that this machine had just under 4 GB of free space, I soon found myself with a problem, one that caused my Spiceworks install to fail, and the box to slow to a crawl.
What to do … should I rebuild? I could, but then I’d lose the data this thing had accumulated over the few days’ time it took to fill the disk, and I liked the results of the test. It was performing on par with Hyperic in terms of general scanning and reporting, although the drill-down detail was somewhat less, and the ability to customize access to a given resource was less (Spiceworks supports configuring only one Windows domain account and one *nix account, and uses SSH and WMI, as opposed to local agents reporting back in the way that Hyperic does). The alerting system was solid. The inventories were solid. Everything about the software was flying high and showing happy, except, of course, the one problem I was having – keeping it from eating the “entire” disk drive. Also, it was running great on XP, and with VMware, there’s no real difference in managing disaster recovery or backup for an operating system. I’m still ticked that there’s no version to install on a Linux box … but that’s for a different forum than this.
Should I recover as much disk space as I can and hope for the best? Sure, why not give it a try? I’ve already hosed myself here, in spite of being addicted to documentation and following templated procedures whenever possible. A short while later, no real luck. As much as I remove, Spiceworks continues to grow as it records scanning results and archives historical data.
Time to fix the problem at the disk level. I did this not too long ago on my XP machine in Parallels, based on this blog post, so I just modified the process to fit the VMware Server 1.04 environment. First off, to expand this disk size, I went to the terminal on my Macbook, remoted to my VMware Server box via SSH, and executed the following command from within my virtual machine’s directory (on my boxes, this is /vmdir rather than the default) :
vmware-vdiskmanager -x 14GB “My Disk Name Redacted.vmdk”
After a short time the disk was successfully expanded. Now, of course, just because the disk was expanded doesn’t mean the space is usable, which is where GParted comes in. Grab a copy from the wonderful folks who host it (SourceForge). GParted makes you go through some configuration when you boot from it, just so that you get the best display resolution and so that it boots properly, but most anyone with experience in IT can follow the process without me outlining it here (especially since it only involved pressing enter twice, and has been outlined elsewhere ad infinitum). I switched the removable drive over to my GParted iso file, booted and configured. At this point, as you can see from the images, I had a full view of my disks and could manipulate to my heart’s content:
I simply right-clicked, selected Resize/Move, and slid the slider from the current position to the end of the drive. The steps, graphically, are as follows:
Strangely enough, it errored out on me (and I didn’t get a cap … dangit). Turns out it wasn’t a show-stopper, but it was strange. When I rebooted, it loaded into Windows normally, which threw me for a loop — it is *supposed* to do a disk check. When the check completes, Windows should see the expanded drive size. As this pic shows, there was a decided difference in opinion between what the drive’s capacity was and what was available in reality.
Not deterred, I manually ran the chkdsk for the next reboot, whereupon nothing changed. Since I had an error before, I decided to try again. I resized the drive to add 1 MB of unallocated space at the end, applied (this time with no errors), and rebooted.
Windows came up, ran a quick scan of the disk, and voila! It found the extra space just fine.
Was the error just an anomaly? I checked Google but nothing really popped. I checked the GParted forums — nothing really popped. Chalk it up to a slight hiccup at the wrong time, perhaps a bug as yet unseen. I posted the info and moved on.
So, as you can see, GParted helped me pull my test bacon out of the test fire before it test-burned. This is definitely a utility I will be keeping in my toolbag from now on.