Virtualization


VirtualBox on Windows: Stuck in capture mode as the keyboard does not have a right Ctrl button

Recently, we got a laptop that did not have a right Ctrl button and we found out after we started a VM with no Guest Additions installed.
Because of these two factors we could not escape the VM capture mode and return to the host OS.

To resolve the issue, we pressed Alt+Ctrl+Del to force the window to escape by entering that specialised Windows security screen and the hit Cancel.
Then, we went to the VirtualBox window and did the following procedure to change the button that allows you to escape the capture mode.

From the VirtualBox Window menu we went to: File –> Preferences –> Input and then clicked on the box next to HOST KEY COMBINATION and then typed the key we wanted to use.


Send ALT+CTRL+Delete to QEMU virtual machine

Recently we wanted to start a Windows virtual machine from a physical hard disk using a Fedora w/ GNOME 3 host machine to change the domain password of a user.
To do so, we used QEMU, QEMU is a generic and open source machine emulator and virtualizer.

To perform the password change, we needed to sent the ALT+CTRL+Delete key combination to the virtual machine to access the system screen and then change the user password.
Pressing ALT+CTRL+Delete on the Fedora/GNOME 3 host machine, it popped up a prompt to shut down the host machine instead of sending the key combination to the active window of the VM. Apparently, we could not sent the key combination directly to the VM and had to find a way around it.

Solution:

We pressed ALT+CTRL+2 while the QEMU window was selected/active to switch to the QEMU terminal/monitor.
In the blank screen that appeared, we typed sendkey alt-ctrl-delete and pressed the Enter key.
This action sent to the virtual machine OS the key combination ALT+CTRL+Delete.
Finally, to switch back  to the guest screen we pressed ALT+CTRL+1.


Fedora: Start a Virtual Machine using a physical hard disk

Recently, we wanted to start a Virtual Machine running a Windows installation from a physical hard disk.

We could not find a way for GNOME Boxes to achieve this, so we installed qemu to do so.

We installed qemu using:

sudo dnf install qemu -y;

Configuring our command to start the Virtual Machine from the physical hard drive:

  • Our hard disk was identified on the physical machine as /dev/sda so we set the -hda parameter to that value.
  • Then we added the parameter -boot c to instruct the virtual machine to boot from the first hard disk.
  • The default guest start-up RAM size was 128 MiB, so we set the parameter -m to 4096 to give to the virtual machine 4GB of RAM.
  • Finally we added the -snapshot parameter which instructed the system to write to temporary files instead of the disk image files (all disk images are considered as read only).
    In this case, the raw disk image used are not written back. When sectors are written, they are written in a temporary file created in /tmp.
    You can however force the write back to the raw disk images by using the commit monitor command (or C-a s in the serial console).

In the end our command was as follows:

sudo qemu-kvm -snapshot -m 4096 -boot c -hda /dev/sda;


A couple of notes on moving a VirtualBox ‘.vdi’ disk image to a GNOME Boxes virtual machine

Recently we had a CentOS virtual machine on VirtualBox which we wanted to use in GNOME Boxes.
We copied the .vdi disk image and we used it to create a new virtual machine in Boxes.

Note A:

By doing this we realized that the system did not reuse the .vdi image.
It merely created a copy at ~/.local/share/gnome-boxes/images/ that was suitable for GNOME Boxes.
So, be sure to have enough space when doing an import like this.
You will need at least twice the space of the .vdi image to complete the migration.

Note B:

When the guest OS started the window manager crashed and it did not allow us to login.
We assumed that this issue occurred due to the VirtualBox Guest Additions that were installed on the guest OS.
As we could not login with the graphical interface, we could not verify this claim.

Fortunately, CentOS (and many other Linux distributions) allow you to switch to a console login using the key combination alt + ctrl + F3.
(There are more than one valid key combinations to do this. In some systems alt + ctrl + F4 is also valid or alt + ctrl + F1 etc).
We hoped that by trying to login via a console login, the Guest Additions would not start and the system would not crash, which luckily this was the case, and we managed to login through the console!

After we logged in, we had to remove the Guest additions. To do so we had to execute the uninstall script that was located at /opt/VBoxGuestAdditions-X.Y.Z/uninstall.sh
(X.Y.Z is the version number of the installed VirtualBox Guest Additions).

When the removal was complete, we executed sudo reboot to restart the system and unload any VirtualBox services that could be executing at the time.
Once the system completed the restart we were able to login properly from the GUI of GNOME and use our virtual machine properly.


Ubuntu 11.10 (Oneiric Ocelot): Cloning a KVM Virtual Machine

After properly installing and creating your first virtual machine, you might want to create a clone for some reason.

To do this we use the command virt-clone as follows:

sudo virt-clone --connect qemu:///system -o coeus -n phoebe -f /home/kvm/2KA.qcow2 -f /home/kvm/zK6.qcow2 --force

Where:

  • –connect is used to connect to the hypervisor of the virtual machine, here it is system
  • -o is the original virtual machine name (which is registered with the previous hypervisor)
  • -n is the name of the new virtual machine, the clone (this name will be used to register the clone to the hypervisor)
  • -f the location that the clone will use to store it’s virtual hard drives, can be used as many times as needed (in the above example coeus has two hard disks and that is why we need to provide two -f paramaters)
  • –force prevents interactive prompts and replies ‘yes’ to all yes/no questions

There is more directives that can be provided to the clone manager from which a very important one is the: –mac where you get to define the mac address of the new virtual machine (e.g –mac C0:FF:EE:11:00:11)


KVM: How to configure a bridge connection in Ubuntu 11.10 2

Make the file : /etc/network/interfaces  look something like this (make changes only to br0, add it if not there and to the device that you want to bridge with, we used eth1):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

# Building a bridge to be used by the Virtual Machines
auto br0
iface br0 inet static
        address 192.168.0.10
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth1
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Then issue: sudo /etc/init.d/networking restart
If you get:

* Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces
 * Reconfiguring network interfaces...                                                                                                                                                    RTNETLINK answers: File exists
ssh stop/waiting
ssh start/running, process 11489

Waiting for br0 to get ready (MAXWAIT is 20 seconds).
RTNETLINK answers: File exists
Failed to bring up br0.                        [ OK ]

Try bringing down the device to be bridged (eth1) like this: sudo  ifdown eth1 and then issue sudo /etc/init.d/networking restart again.
After that enable it the device again again like this: sudo  ifup eth1
If this doesn’t worked try restarting the machine, worked for us.

When properly configured ifconfig should result to something similar as this:

br0       Link encap:Ethernet  HWaddr 00:1a:64:67:d3:86  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:64ff:fe67:d386/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1752 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:136973 (136.9 KB)  TX bytes:1500 (1.5 KB)

eth0      Link encap:Ethernet  HWaddr 00:1a:64:67:d3:84  
          inet addr:10.16.20.60  Bcast:10.16.20.63  Mask:255.255.255.224
          inet6 addr: fe80::21a:64ff:fe67:d384/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:91218 errors:0 dropped:0 overruns:0 frame:0
          TX packets:51796 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:123551183 (123.5 MB)  TX bytes:4754458 (4.7 MB)
          Interrupt:16 Memory:ce000000-ce012800

eth1      Link encap:Ethernet  HWaddr 00:1a:64:67:d3:86  
          inet addr:10.16.20.33  Bcast:10.16.20.63  Mask:255.255.255.224
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:2605 errors:0 dropped:48 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:321878 (321.8 KB)  TX bytes:3490 (3.4 KB)
          Interrupt:17 Memory:ca000000-ca012800

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:129 errors:0 dropped:0 overruns:0 frame:0
          TX packets:129 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17588 (17.5 KB)  TX bytes:17588 (17.5 KB)

virbr0    Link encap:Ethernet  HWaddr b6:ae:8d:e0:06:c3  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


Ubuntu 11.10 (Oneiric Ocelot): Installing KVM 2

Without any additional comments, we managed to install KVM over a fresh installation of Ubuntu 11.10 (Oneiric Ocelot).

To do this we installed the following packages from the repositories and added our user to the libvirtd group.

We called kvm-ok to make sure that our hardware supports KVM properly and thus having better performance.
Installation Commands:

sudo apt-get install kvm libvirt-bin
sudo adduser $USER libvirtd
sudo apt-get install virt-viewer
sudo apt-get install python-vm-builder
sudo apt-get install bridge-utils
sudo apt-get install virtinst #for cloning

After these we created a virtual machine with the following command:

sudo vmbuilder kvm ubuntu --suite oneiric --flavour virtual --arch amd64 --mem 1024 --cpus 2 -o --libvirt qemu:///system --ip 192.168.0.100 --hostname uranus --part vmbuilder.partition --user userName --name MyName MySurname --pass myPassword --addpkg unattended-upgrades --addpkg acpid --addpkg nano

where in general, what it does is, create an Ubuntu Oneiric Ocelot JeOS virtual machine that has an AMD64 architecture, 1GB of RAM, 2 Virtual CPUs, it’s name is uranus, has a user with the username userName, has pre-installed some applications like nano and enabled automatic updates for the system.


How to setup DNS service for DHCP-enabled KVM guests

So you’ve set up KVM on your machine and you have installed a few guests to run on top, now it’s the time to access them.

Since KVM can run without a GUI, you might want to control these guests from the command line. But, how can you do it if you do not know the IP of the guests?

You can either connect to the guest using virt-viewer:

virt-viewer -c qemu:///system $MACHINE &

which requires more bandwidth since it will open up a VNC session.

Or, use ssh to connect using the guest’s name, like this:

ssh $MACHINE

which doesn’t require that you know the IP beforehand.

To achieve this, access guest machines using their hostname only, you can do the following: Edit /etc/resolv.conf and add the line nameserver 192.168.122.1 right after the search entries .

Your file should look something like this afterwards:
domain in.bytefreaks.net
search in.bytefreaks.net
nameserver 192.168.122.1
nameserver 194.44.13.20
nameserver 194.44.13.58
nameserver 194.44.13.11

Then you are ready to go! No restarts needed no extra steps.

NOTES:

  • After restarting (and some times periodically), the /etc/resolv.conf file will return to its original form because it is updating each time you restart the host machine from data it gets via the network DHCP server.
  • For this tutorial to work as is, your host machine needs to have the virtual IP 192.168.122.1 (the default IP of your host in libvirt — NOT THE IP of eth0, it’s a totally different thing). If you have a different libvirt IP use that one in the /etc/resolv.conf file.
  • Use your host’s IP as your first nameserver in /etc/resolv.conf to achieve name resolution for your guests.


Oracle VirtualBox: Enable eth0 on backtrack4 / enable default ethernet card on backtrack

ifup eth0

*INFO: The default Ethernet device is disabled on boot but it can easily be enabled by just issuing the above command. (You still need to configure it depending on your system’s structure). In order to activate the Ethernet card you need to call the above command from the Terminal.