To finish the KVM series (part 1 and part 2), this last part will show what has to be done to have another virtual machine up&running. This assumes you're using some of the newer Linux distros with udev enabled. The example is for Debian, I guess it's very similar on others.

Let's assume you have your first VM all setup, with IDS running and everything configured the way you wanted. Then you want to setup another one, almost identical (to play with HDR for example), with only minimum necessary config changes, both on OS and in IDS.

Can't be easier: just shut down your VM to save a stable state and copy the image.

My last KVM blog entry showed how to install all the prereqs and do the initial install of the virtual machine to host your IDS toy instances.

To really start playing we'll need networking of course.
I'm not going into the details explaining every single line of config, much better explanations are already written on the web. But I'll try to give a reasonable overview.

To connect the VMs both to the outer world and between themselves we'll need a kind of virtual switch running on host machine and "wire" network interfaces in VMs to it.
We'll use virtual TUN/TAP network interface and promote it to the virtual switch using VDE utility.

Motivated by article on using Xen and Informix on Developerworks (http://www.ibm.com/developerworks/db2/library/techarticle/dm-0807fuerderer/index.html) and by Eric's comment I'll try to give a similar step-by-step explanation on how to setup KVM virtual machines on Linux box if you need a playground to test new features or proof-of-concept projects. Originally, I commented it seems easier to setup KVM than Xen, and hopefully I'll show it is. Except maybe for one bit :) And that's networking. More on that later. I'm assuming the next hardware configuration:

An issue I bumped into two weeks ago.
Opened a call with IBM, but didn't go further than being pointed to Documentation Notes, which is fine, but I'd still prefer to know why.

A simple table with one varchar field:

Load it with records of varying real length (approx. 60000 rows in my case), then do:

So, this is just lengthening of varchar field definition, not the data itself.

If you're careful enough (which I wasn't) you'll notice it takes some time to execute the statement, it uses a lot (depending on number of rows, of course) of dbspace in which the table is created and logical log space.