I ran into this same problem and it was the VM that I setup using ubuntu vmbuilder.
Check out this intro that includes a complete vm. I'm certain that this should work for you.
They provide an init script, amongst other things, that set up certain networking parameters at boot so this is likely at the heart of the issue. They more fully explain this here with contextualization.
General Context Method
So it turns out installing the contextualization files in the VM is a rather simple issue.
If you are using vmbuilder to make your VM you can use a post install hook (and I'm sure other build methods also have various post install hooks too).
Create the copy file (hostfile to guestfile, make sure it's single space separated?)
Create the post install hook
# create mount point for context image
# setup vmcontext at runlevel 2 service level 1
ln -s /etc/init.d/vmcontext /etc/rc2.d/S01vmcontext
Create script to chmod to vm guest
# vmbuilder passes vmguest root as $1
chroot $1 /tmp/postinstall.sh
Finally, edit your vmbuilder conf file for the VM
copy = <full_path>/copy.cfg
execscript = <full_path>/chvm.sh
Then construct with vmbuilder
sudo vmbuilder kvm ubuntu -c vmbuilder.cfg
Add a nebula based vnc
Include something like this in your context
GRAPHICS = [
LISTEN = 0.0.0.0,
PORT = 5900,
TYPE = vnc ]
Then ssh tunnel to a computer that's on the guest machines network
ssh -L 5900:127.0.0.1:5900 yourserver.com
And open a vnc client at 127.0.0.1 on your local computer.
Nebula can't force kvm/libvirt to run your drives on hd*/sh* so you'll need to play around with where they wind up (and edit the rc file to reflect this). E.g. with my Ubuntu setup the qcow2 image gets /dev/sda and the context image gets /dev/sr0.
I also had an issue where either kvm or nebula couldn't guess the format of my .qcow2 image. Hence, in DISK I had to include DRIVER=qcow2. This same problem occurs for processor architecture hence in OS I had to include ARCH=x86_64 (since I was running an amd64 guest).