Archive

Posts Tagged ‘Virtualization’

Running Virtual Machines on KVM and QEMU from command line on Ubuntu 14.04

October 7, 2014 Leave a comment

The aim of this post is to document how to get a Lubuntu 14.04 instance, a Windows 7 instance and an Android-86 instance running on KVM (running on QEMU in most cases).
[NB: This is not yet complete, so it may serve only as pointers and not a full guide…]

Install the prerequisites:

sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Check if Virtualization is supported on your machine (or virtual machine, if you’re trying to nest VMs) using the kvm-ok command

Method 1: Using the libvirt library / package / set of tools:

NB: I used this to get the lubuntu instance running

sudo apt-get install virtinst
sudo virt-install -n testLubuntu -r 512 \
--disk path=/home/USERNAME/Desktop/VMDisks/testLubuntu.img,bus=virtio,size=6 -c \
lubuntu-14.04.iso --network network=default,model=virtio \
--graphics vnc,listen=0.0.0.0 --noautoconsole -v

Check which VMs are running:

virsh -c qemu:///system list

Stop an instance:

virsh -c qemu:///system shutdown  

NB: Replace the with the name of the instance, e.g. in my case “testLubuntu”
Start an instance:

virsh -c qemu:///system start  

Destroy and undefine an instance:

virsh -c qemu:///system destroy  
virsh -c qemu:///system undefine  

Method 2: Using the kvm package directly:

NB: I used this to get the Android-x86 instance running … but without a WiFI network (as of now…)
Create a virtual disk image file

qemu-img create android-4.4.img 8G

Install the Android OS using a virtualized CD-Rom that points to a bootable Android image:

kvm -m 2048 -hda android-4.4.img -cdrom <Bootable-Android-ISO.iso> -boot d

Create a partition that is bootable and writable when the cfdisk prompts you to do so.

I haven’t been able to get the networking part right because it involves some bridging … which is a bit mind-boggling.

Resources:

Advertisements

Installing devstack (Openstack for developers) on Ubuntu 14.04

September 16, 2014 2 comments

Step 1: Install git

 sudo apt-get install git 

Step 2: Clone the latest devstack repository (Grizzly, Icehouse, Juno, Kilo, etc …)
For Icehouse

 git clone -b stable/icehouse https://github.com/openstack-dev/devstack.git 

or, for Grizzly

 git clone -b stable/grizzly https://github.com/openstack-dev/devstack.git 

A folder in your home directory with the name devstack should have been created

Step 3: Change directory to the devstack directory

cd /devstack/userDir/devstack

Step 4: Install devstack using the stack.sh installation script

./stack.sh

You will first be presented with at least 5 dialogs asking for passwords for various services. The norm is to use the same password – for easy use while doing development and testing(Great security, right? not really, but it’s for convenience – i.e “Principle of Psychological acceptability”). Read the dialogs carefully and if you chose to put in more secure passwords (longer than 8 characters, alphanumeric, special characters) perhaps note them down somewhere – it may save you a great big headache later.

After these dialogs, the script will run and download stuff from the internet to install (Make sure your internet connection is working). The script runs for at least 20min, if it goes through the entire procedure and works.

At the end of the installation script (which may take at least 20min, so get a coffee, or do something else) you will be presented with the URL where the Openstack dashboard (horizon) can be found, as well as the username and password to log into the dashboard. The default usernames are “admin” and “demo”. The password will be what you set among the dialogs at the beginning, or if you just pressed enter to skip the dialogs, then devstack will choose a random long password for you (which it will show you at this point)

Generally if something went wrong and you want to stop the devstack platform as a whole, i.e. stopping all the services running you can use:

./unstack.sh

If you want to remove everything (well almost everything) that devstack installed on the machine:

./clean.sh

(NB: i’ve had varying success in ensuring that it removes everything. Sometimes you might have to run extra commands like apt-get remove –purge , apt-get autoremove and/or apt-get autoclean among others in order to clean out the devstack installation)

Conversion from KVM qcow2 (from proxmox) to Virtualbox VDI

June 11, 2013 Leave a comment

Method 1:

Convert first from qcow2 to RAW using qemu-utils in an Ubuntu Linux machine

sudo apt-get install qemu-utils
qemu-img convert -f qcow2 <qcow2_VM_filename> -O raw <RAW_file_VM_filename>

Convert from RAW to VDI using VBoxManage on any machine that has Virtualbox Installed

VBoxManage convertfromraw <RAW_file_VM_filename> <VDI_Output_file_VM_filename> \ 
--format vdi

The “\” is just a line-break because the command doesn’t fit in one line on this page

Method 2:

Use qemu-img directly in a Linux machine:

qemu-img convert -f qcow2 <qcow2_VM_filename> -O vdi <RAW_file_VM_filename>

NB: For some strange reason Method 1 worked once and failed the 2nd time, Method 2 was always successful. So i suggest using Method 2

How to: Get Virtualbox hooked up to your Wireless LAN

April 29, 2013 Leave a comment

Totally forgot about this “How-to” …. Will update this later …

Virtual LAN over Wireless LAN: Get the Wireless Routing Going in Virtualbox

September 24, 2012 Leave a comment

Virtualbox definitely has it’s fair share of networking chaos that makes it rather difficult to quickly set up the networking options and get it right the first time. The various networking modes that it gives you are tailor made for very particular scenarios with very precise conditions that must be met – and not to mention, some very annoying exceptional circumstances to boot. It’s a big jumble and if you need a good primer to get you at least somewhere on the way, I suggest that you read this:

https://blogs.oracle.com/fatbloke/entry/networking_in_virtualbox1 [Very nice and easy read. With pics 🙂 …]

and, this:

http://www.virtualbox.org/manual/ch06.html [The manual itself – with almost all the gory details explained.]

To cut the long story short, I needed to test some security tools in a wireless environment where I need 2 virtual machines, the host machines and any other machine on the host machine (wireless) network to all be in communication at the same time, i.e, more or less on the same LAN, or at most one hop away through a single router.  I need to easily (and seamlessly) switch between communication with the virtual machines, the host itself and physical machines on the host’s LAN – and also get to the Internet. The physical LAN is actually a Wireless LAN, and well the Virtual LAN, is … well … virtual (Physical or Wireless, it’s hard to tell). Is that all too much to ask (even as an early Christmas present) from the almighty Virtualbox?

Well, it seems it’s more difficult that it actually seems. None of Virtualbox’s networking modes seems to support this scenario out of the box (No pun intended 😛 ). I’m pretty sure there are many people who are looking for this kind of thing to work: Virtual machines to talk to each other, the host and other devices on the host’s WLAN. The closest thing is using NAT with port-forwarding, but i didn’t like that solution because it’s rather limiting in terms of getting several things on several different ports to get through without having to manually configure the ports.

Something that could have been close to the ideal situation would have been if Virtualbox could support bridging with the physical host’s Wireless interface. (There are probably several other “almost” solutions, but none working yet).

The main problem it seems is that Virtualbox – on it’s own – does not support actual routing – or at least from the little testing done, it doesn’t seem to do any serious routing – whether in NAT, bridged adapter mode, host-only adapter or internal network mode. Routing between the physical LAN that the host is on

The Solution:

What worked for me was the luck that my Virtualbox environment was actually running on a Windows 7 host that supports a rather nifty tool called the Microsoft Virtual Miniport Adapter – something that seems to have hived off from a previous Virtual Router project. The idea is that it allows the Windows 7 user machine to easily act as a Wireless Router… and perhaps share the Internet connection also.

So the thing is that I shared the Internet Connection of the host machine (and thereby the connection to the Host Machine’s Wireless LAN, Wired Lan, etc) with the Microsoft Virtual Miniport Adapter (i.e Virtual Router). This creates a bridge between the physical wired/wireless LAN to this “Virtual Wireless Router.”

(Now comes the beautiful part …)

In Virtualbox, if one uses the Bridged Adapter mode and bridges the virtual machines to the respective “Microsoft Virtual Miniport Adapter”/ Virtual Router … Hey presto! Magic happens! Suddenly the virtual machines are able to route traffic towards the host itself as well as towards any other machine on the host’s network … and onwards to the Internet – if the host network is connected to the Internet.

Suddenly, the problem that Virtualbox cannot (as of  yet: Sept 2012) support bridging to the host’s Wireless Adapter, is suddenly alleviated. All the pent up tension is relieved  … absolute carthasis, and a sense of relaxation follows. It works!

🙂 A step-by-step “How-to” guide will follow in the next post. 🙂