In other threads, we've occasionally discussed virtualization as an alternative to conventional multibooting.  I thought I'd share with the group a two-week experiment I just concluded this weekend that illustrates a practical use of virtualization.  For those who are familiar with and use virtualization products (VMware, VirtualPC, VirtualBox, et al), this will be old hat.  For those who are just beginning to use them or who are still trying to grasp what they could be good for, this real-life example may be enlightening.


The Objective:  Recently a few people have asked me to recommend spam filtering software to use with Outlook Express, so I thought I'd run a test comparing a few of these programs head to head.

This is an ideal use for virtualization.  I would setup several virtual machines to provide identical environments, then give each anti-spam program its own virtual machine.  At the end of 2 or 3 weeks, I'd see how each one did.  (Turns out I didn't need 3 weeks--results were obvious within 2 weeks.)


The Test Candidates:  After some google searches and scanning a few newsgroup discussions, I chose 10 mail filtering programs for the test.


Providing Content for the Test:  Since I have control over my own domain mail server, I created 10 temporary mail accounts.  To get some junk mail, I activated the domain's "catch-all" mailbox (to collect mail that isn't addressed to a valid username) and configured the server to replicate copies of each incoming message to all 10 temporary mailboxes.  To get some legitimate mail, I had the server replicate incoming mail from my real mailbox to all 10 temporary mailboxes.  Now each of the 10 mailboxes would fill with identical collections of junk and non-junk mail.


The Virtual Machines:  I used VirtualPC for this experiment.  I first created one virtual machine with a 4GB virtual hard disk, and set it up with a bare-bones installation of XP Home Edition and Outlook Express.  I placed the virtual machine file ("spamtest.vmc") and the virtual hard disk file ("spamtest.vhd") in a folder on an external USB hard drive, then copied that folder 10 times.  That gave me 10 identical virtual machines.

I imported the 10 virtual machines into VirtualPC's launch console.  Unless I wanted to run only one at a time, however, slight adjustments would be needed so they wouldn't collide with each other.  I booted each virtual machine, changed the network 'computer name' for each copy of XP, and ran SysInternal's 'newsid' utility to generate a unique sid for each.  That gave me 10 copies of XP that could coexist simultaneously on my home lan.

A different anti-spam program was installed on each virtual machine, and one of the temporary mail accounts was associated with each copy of OE.


Running the Test:  Once a day, I started up the VirtualPC console and launched the virtual machines.  Given ram and screen space considerations, I had no more than 4 or 5 vms running at a time as I cycled through all 10.  Each OE downloaded its mail, and I did whatever spam processing was called for with each program.  Then I deleted all downloaded mail and closed each vm, using VirtualPC's "save state" option (akin to hibernating each machine).  That saved time, since each vm was restoring and hibernating daily instead of booting and shutting down.

Remember that all the mail messages were duplicates anyway, so I didn't need to read or save anything.  All I was doing was checking and correcting what the programs were identifying as spam so they could improve their accuracy.  The whole process to check 10 vms took less than 10 minutes a day.


The Conclusion:  Virtual machines provided an ideal platform for tests such as this.  It was extremely beneficial to be able to compare the test subjects working with identical content in identical environments.  In just two weeks, it was very clear which anti-spam programs stood out from the rest.

Oh... you mean you want the results of the comparison?  Okay, I'll make that the subject of another thread, and keep this one on the topic of practical uses for virtualization.

[Rad edit] That thread is located here » http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1238321569

Dan Goodell wrote on Mar 29^th, 2009 at 5:10am:

configured the server to replicate copies of each incoming message to all 10 temporary mailboxes

how do you do that?

Spanky wrote on Mar 29^th, 2009 at 11:29am:

configured the server to replicate copies of each incoming message to all 10 temporary mailboxes how do you do that?

Depends on whether you have access to that level of your mail server.  If you've got your own domain, your hosting service probably has a control panel of some sort that allows you to setup your own mail accounts.  Mine also allows me to enable or disable a "catch-all" account, and email forwarding.  I set the catch-all account to mailtest1@(mydomain), then setup forwarders to have anything sent to mailtest1 forwarded to mailtest2, mailtest3, etc.

Dan Goodell wrote on Mar 29^th, 2009 at 7:02pm:

Depends on whether you have access to that level of your mail server.If you've got your own domain, your hosting service probably has a control panel of some sort that allows you to setup your own mail accounts.

If you don't have that level of access, you could also set up a rule on your mail client that forwards all mail to a list of address you supply.  This could start to mean a lot of mail flowing in and out of your account, tho, so configure it carefully.

Another idea I had about how to do it is to set up all the clients in the test to leave copies of the email on the server when they download it.  Then they could all access the same account.

MrMagoo wrote on Mar 29^th, 2009 at 7:54pm:

Another idea I had about how to do it is to set up all the clients in the test to leave copies of the email on the server when they download it.Then they could all access the same account.

Hmm.. I didn't think of that!  Yeah, that would have been a lot easier.

On second thought, that wouldn't work.  Some of the programs (like Mailwasher) deleted files from the server that they identified to be spam.  At the beginning of the test, I didn't know which programs might do that, so I'd have to let each program have its own mailbox.

Here's another practical, real-world example.  I help a nearby business with their computer needs, and the boss just bought a new laptop and was having trouble installing one of her programs on it. She called me over to take a look and sure enough it wouldn't install, giving an error message I'd never seen before ("This program is incompatible with this version of Windows"). Well, hell, it's Vista, I'd just put it on one of their other Vista machines a few weeks ago (tick,tick,tick - lightbulb!). Me: "Hey, is this by any chance 64-bit Windows?". She: "What's that?".

Yep. she'd just walked into the big-box store and bought an HP laptop off the shelf with 64-bit Vista. I could go into a whole sidebar about how irresponsible it is for the MegaloComputerMart to just be selling boxes with 64-bit Windows to anyone who walks in off the street. It's not even that easy to tell you've got Vista64. It looks the same. We had to Google and search the control panel to even find out what she had, and when we found out it was indeed 64-bit (and this old but necessary and unique business specific program hasn't been updated since it was released for for Win 3.1), I said "Sorry, you're hosed".

But, VM to the rescue! Like Dan did with the mail filters above, I built her up an XP Virtual machine with nothing on it but her program - it weighed in at about 3GB. I put it on her laptop, got her the VMware player, she starts it up and yipes, she's ready to party like it's 1999 again.

I'll still tell her to go back to 32-bit when she moves to Windows7, though.

slangtruth wrote on Apr 7^th, 2009 at 10:58am:

I could go into a whole sidebar about how irresponsible it is for the MegaloComputerMart to just be selling boxes with 64-bit Windows to anyone who walks in off the street.

In my experience, half of the salesmen at MegaloComputerMart don't know the difference anyway.  As you said - it looks the same.  You can't trust them to sell you what you need anymore than you can trust a real estate agent to pick the right house for you.  

Even if they have good product knowledge, I'm not sure we could expect some salesman at a big chain to know that she has a particular program written over 15 years ago she just can't let go of.  At some point, the industry has to move on, and those who remain chained to old technology need to solve it with things like virtualization, as you have done.  

slangtruth wrote on Apr 7^th, 2009 at 10:58am:

she starts it up and yipes, she's ready to party like it's 1999 again

:) Yer funny. Made me chuckle.

MrMagoo wrote on Apr 7^th, 2009 at 6:17pm:

In my experience, half of the salesmen at MegaloComputerMart don't know the difference anyway.As you said - it looks the same.You can't trust them to sell you what you need anymore than you can trust a real estate agent to pick the right house for you.

She probably didn't even talk to a salesperson. I think she went in with a budget, picked something out that met the budget and had a big enough screen, and said "I'll take one of these". To a layperson, it's just a computer and they expect it to work just like their last one, only faster.


MrMagoo wrote on Apr 7^th, 2009 at 6:17pm:

Even if they have good product knowledge, I'm not sure we could expect some salesman at a big chain to know that she has a particular program written over 15 years ago she just can't let go of.At some point, the industry has to move on, and those who remain chained to old technology need to solve it with things like virtualization, as you have done.

Sure, but if I wanted to hear "If you buy this new computer, your old programs won't work any more. Buy new ones or do without.", I'd have bought a Mac.  For myself, I've got boatloads of 16-bit programs that I don't want to give up on. I wrote stuff in Clipper for a long time, and still have some legacy dbf databases. For new GUI type stuff I manipulate them with programs written in C++ Builder, but for a quick and dirty report or manipulation there's nothing faster than firing up my favorite 1991 text editor (which has at least one facility I've never seen in any other editor), banging it out, compiling and running it right from the command line. I could rewrite all the legacy stuff and with practice could probably get just as fast at Q&D cycles with more modern tools, but why should I have to?  I'm too lazy.

It is perhaps too obvious, but Windows Vista allows any application to be run in a “compatibility mode,” emulating versions of Windows all the way back to Windows 95.  In addition:


Quote:

Many 32-bit applications will not be updated for Windows Vista x64 Edition; however, most 32-bit software will still function because of a Microsoft emulation layer. This emulation layer, known as Windows on Windows 64 or WoW64, enables 32-bit programs to run as though on a 32-bit version of Windows by translating instructions passing in and out of 32-bit applications into 64-bit instructions. Emulated programs act as though they are running on an x86 computer and operate within the 2 GB of virtual memory that a 32-bit version of Windows allocates to every process.

Source:  A Closer Look at Windows Vista, Part III: 32-Bit vs. 64-Bit Windows

(Of course, perhaps not every application will work properly in an emulated environment.)

One issue that users of “old” software should consider is security.  The vast majority of security threats to a PC are not related to the operating system, but are due to faulty applications.  If, for example, you’re not running the most recent release of Acrobat (or J2SE runtime environment, or X, or Y, etc.), you’re at significant risk.  Thus, keeping current with new versions of software not only provides enhanced functionality, but in general it also improves security.

And another example of old programs not being compatible with newer hardware and/or software (or are they?!):

I have a DOS based business program that I have used up until about two years ago (my work situation changed so I didn't need to use that program--at least for now) that I purchased back in 1994.

In 2000, the company said it was migrating to a Windows only based version of the program and would no longer be updating and supporting the old DOS version--primarily because the old data base function in DOS was not FAT32 compatible--and all new versions of Windows were going to be FAT32 or NTFS going forward.

They, of course, were marketing their new version--and failed to mention that you can create a separate FAT16 partition on the HDD, that Windows is completely compatible with, along with those FAT32 and/or NTFS partitions, and you could then continue to run the program from within a *command window* under Windows--as long as the program was on the FAT16 partition and did all its read/writes to that partition!

slangtruth wrote on Apr 8^th, 2009 at 8:41am:

She probably didn't even talk to a salesperson. I think she went in with a budget, picked something out that met the budget and had a big enough screen, and said "I'll take one of these"

All the more reason why I don't think it's fair assign (ir)responsibility to the store.


slangtruth wrote on Apr 8^th, 2009 at 8:41am:

Sure, but if I wanted to hear "If you buy this new computer, your old programs won't work any more. Buy new ones or do without.", I'd have bought a Mac.  For myself, I've got boatloads of 16-bit programs that I don't want to give up on.

You don't have to give up on them.  You can run them in compatibility mode or a Virtual Machine.  Virtual Machines can even share files with their host and other virtual machines, so I'm hard pressed to think of a disadvantage in this case.  And, a virtual machine would work on a Mac, if that is the system you really want to use...


slangtruth wrote on Apr 8^th, 2009 at 8:41am:

To a layperson, it's just a computer and they expect it to work just like their last one, only faster.

This is the heart of my point - the same people who want faster/better computers also want them to work exactly the same forever.  These goals are not entirely symbiotic.  I agree that we have to maintain some amount of compatibility as long possible, but sometimes you have to change the way things work a little bit to make them faster/better.  

In this case, a 32-bit processor can only address 3.2 GB of memory (along with a few other limitations.)  This was more than enough for any OS up until now, but its not uncommon to see Vista desktops shipping with 4 GB of memory.  Recommending to someone that they buy only 32-bit Windows7 guarantees them a computer with an amount of memory that will likely be below average by then, making the goal of a new computer being 'fast' difficult to achieve.  

On the other hand, solving it with Compatibility Mode or a virtual machine is free and allows the host computer to have up to a theoretical limit of 16.8 million terabytes of memory (which even at the rate M$ bloats their software, should be enough for several generations of software.)

Pleonasm wrote on Apr 8^th, 2009 at 9:40am:

One issue that users of “old” software should consider is security.

Another fine side-effect of virtualization is that it isolates programs running on the virtual machine from the host, providing a fairly good security barrier.

MrMagoo wrote on Apr 8^th, 2009 at 8:13pm:

Another fine side-effect of virtualization is that it isolates programs running on the virtual machine from the host, providing a fairly good security barrier.

MrMagoo,

If you are surfing the net from the virtual machine and download a few viruses, are they confined to the virtual machine and able to be removed by "Delete Undo Disk Changes"?

A virus/trojan/malware that attacks a virtual machine is typically confined to the virtual machine.  If you can revert the machine to a state before the virus infected the machine, you should be safe.  Since the virtual machine is just a file, you can easily back it up by simply making a copy of the file when the virtual machine isn't running.  Deleting the current copy and reverting to your most current back-up copy is akin to restoring a previous Ghost image (although faster and easier.)

One neat thing a paranoid person could do is make a copy of their virtual machine every day before booting it.  Then boot the new copy and do all your surfing there.  At the end of the day, shut down and delete the copy you have been running, leaving your previous VM in a (hopefully) pristine condition.  In fact, some new security software for web servers works on this exact concept.  Virtual machines are automatically rotated fast enough that any infection doesn't get to stick around for long.

There are a few cavets to keep in mind.  One is that if you share files between your VM and host, those shared files could be infected, spreading the infection to the host.  

Second, there could be security holes in the virtualization software that would allow an infection to jump from a virtual machine to its host.  That situation is currently incredibly rare; An attacker would have to find a vulnerability in both your virtualization software and an application running on the virtual host and exploit them both, and virtualization software is considered pretty secure right now.  

I'm unfamiliar with "Delete Undo Disk Changes".  Which VM software offers that?

Microsoft Virtual PC. When you shut down the OS you have 3 choices...

Commit changes to the virtual hard disk
Save undo disk changes
Delete undo disk changes

Depending on which virtual machine I'm using, I choose the first or last.

Ah, ok.  I've never used Microsoft Virtual PC.  

Brian wrote on Apr 8^th, 2009 at 8:39pm:

If you are surfing the net from the virtual machine and download a few viruses, are they confined to the virtual machine and able to be removed by "Delete Undo Disk Changes"?

Yes . . . though you should never say never, as MrMagoo explained.  Just think of the virtual machine as though it is a separate, standalone computer on your home network.  If you have a standalone box on your LAN and it gets infected, can that infection spread to the other computers?  If it can spread across the network, it can do the same from a virtual machine.  So whatever safeguards you would use to insulate your LAN's machines from each other still apply to a vm.

In general, any infection that cannot jump across the network also cannot jump from the vm to the host--although you'll have to be more careful if you've enabled VirtualPC's "shared folders" option.

VirtualPC's "undo disk" option is one of its best features, and something I really, really miss with VMware or VirtualBox.  As MrMagoo mentioned, you can always make duplicates of your virtual hard disk beforehand so you dirty up only the duplicate, or you can make a snapshot beforehand and afterward revert to the snapshot, but "undo disks" is so much easier and more convenient, IMHO.  With the option enabled, VirtualPC leaves your virtual hard disk in its pre-session state and caches all disk changes in a separate file.  At the end of the virtual session, you tell VPC whether or not to merge all the changes into the virtual disk file.

In case anyone doesn't appreciate how fundamentally convenient this approach is, consider this example: let's say you startup and close your virtual session daily, and on the fourth day the vm gets infected.

With VMware or VirtualBox:  Copy virtual disk to a backup file.  Start/stop virtual session.  Infected?  No.  Copy the updated virtual disk to backup.  Second virtual session.  Infected?  No.  Backup the virtual disk again.  Third session.  Infected?  No.  Backup again.  Fourth session.  Infected?  Yes.  Copy from the backup file back to the virtual disk file.

(Note that using snapshots is really just the same--you would make a new snapshot in place of each "copy" operation above.)

With VirtualPC:  Start/stop virtual session.  Infected?  No, VPC merges the undo disk into the virtual disk.  Second virtual session.  Infected?  No, disks merged.  Third session.  Infected?  No, disks merged.  Fourth session.  Infected?  Yes, toss undo disk.

The problem is you never know when you're going to get infected, and the "snapshot" approach puts the onus on the user to make sure he's got a recent backup to revert to.  The VPC way says even though we don't know when you'll get infected, when it does happen we'll just use whatever you ended with last session.

And note it makes no difference if you choose not to backup after each and every session; it's the same principle, if just a longer timeline.

I use the undo disk feature all the time.  If someone asks me to take a look at some program they downloaded, I don't have to think twice.  Startup VPC, install the program, look at it, then delete undo disk changes.  Even if the program's not malware, I don't have to think about whether I want that program left on my vm, or bother uninstalling it, or have to remember to make a snapshot or backup before testing.  Quick and simple.

Thanks, Dan.  Sounds like a good feature missing from other VM software.