Tuesday Jul 31, 2012

VirtualBox and Mountain Lion (Mac OS X 10.8)

VirtualBox.png[Update:

VirtualBox 4.1.20 and later are now completely compatible with Mountain Lion and this jiggery-pokery is no longer needed

- FB]

Apple released Mountain Lion (Mac OS X 10.8) late last week and a few people are stumbling over installing VirtualBox on it, so here are a few tips:

At the time of writing, the current version of VirtualBox is 4.1.18. Strictly speaking, this is not commercially supported, but VirtualBox users tend to be an intrepid and gung-ho bunch, and will try to run it on Mountain Lion anyway. They'll download VirtualBox and run the installer by clicking on the VirtualBox.mpkg icon:

...and get a message like this:

This will happen if you are using the default Security settings of Mountain Lion for downloaded applications, which probably look like this:

Application Settings

To get VirtualBox installed you can either:

  1. temporarily allow applications downloaded from Anywhere in the System Preferences box above, changing it back after installation; or
  2. hold Control key down as you click the .mpkg and choose Open. Doing this, you'll get a subtlety different dialog like this:

...which now has an Open button. Clicking on this will get VirtualBox installed too.

HTH someone out there.

-FB 

 P.S. You can expect to see a "Fully Supported" version in the not too distant future ;-)

Friday Jun 08, 2012

Networking in VirtualBox

VirtualBox.pngNetworking in VirtualBox is extremely powerful, but can also be a bit daunting, so here's a quick overview of the different ways you can setup networking in VirtualBox, with a few pointers as to which configurations should be used and when.

VirtualBox allows you to configure up to 8 virtual NICs (Network Interface Controllers) for each guest vm (although only 4 are exposed in the GUI) and for each of these NICs you can configure:

  1. Which virtualized NIC-type is exposed to the Guest. Examples include:
    • Intel PRO/1000 MT Server (82545EM), 
    • AMD PCNet FAST III (Am79C973, the default) or 
    • a Paravirtualized network adapter (virtio-net).
  2. How the NIC operates with respect to your Host's physical networking. The main modes are:

The choice of NIC-type comes down to whether the guest has drivers for that NIC.  VirtualBox, suggests a NIC based on the guest OS-type that you specify during creation of the vm, and you rarely need to modify this.

But the choice of networking mode depends on how you want to use your vm (client or server) and whether you want other machines on your network to see it. So let's look at each mode in a bit more detail...

Network Address Translation (NAT)

This is the default mode for new vm's and works great in most situations when the Guest is a "client" type of vm. (i.e. most network connections are outbound). Here's how it works:

NAT Networking

When the guest OS boots,  it typically uses DHCP to get an IP address. VirtualBox will field this DHCP request and tell the guest OS its assigned IP address and the gateway address for routing outbound connections. In this mode, every vm is assigned the same IP address (10.0.2.15) because each vm thinks they are on their own isolated network. And when they send their traffic via the gateway (10.0.2.2) VirtualBox rewrites the packets to make them appear as though they originated from the Host, rather than the Guest (running inside the Host).

This means that the Guest will work even as the Host moves from network to network (e.g. laptop moving between locations), and from wireless to wired connections too.

However, how does another computer initiate a connection into a Guest?  e.g. connecting to a web server running in the Guest. This is not (normally) possible using NAT mode as there is no route into the Guest OS. So for vm's running servers we need a different networking mode....

Bridged Networking

Bridged Networking is used when you want your vm to be a full network citizen, i.e. to be an equal to your host machine on the network.

In this mode, a virtual NIC is "bridged" to a physical NIC on your host, like this:

Bridging to wired LAN

The effect of this is that each VM has access to the physical network in the same way as your host. It can access any service on the network such as external DHCP services, name lookup services, and routing information just as the host does. Logically, the network looks like this:

Bridged Networking

The downside of this mode is that if you run many vm's you can quickly run out of IP addresses or your network administrator gets fed up with you asking for statically assigned IP addresses. Secondly, if your host has multiple physical NICs (e.g. Wireless and Wired) you must reconfigure the bridge when your host jumps networks. 

Hmm, so what if you want to run servers in vm's but don't want to involve your network administrator? Maybe one of the next 2 modes is for you...

Internal Networking

When you configure one or more vm's to sit on an Internal network, VirtualBox ensures that all traffic on that network stays within the host and is only visible to vm's on that virtual network. Configuration looks like this:

Configuring Internal Networks

The internal network ( in this example "intnet" ) is a totally isolated network and so is very "quiet". This is good for testing when you need a separate, clean network, and you can create sophisticated internal networks with vm's that provide their own services to the internal network. (e.g. Active Directory, DHCP, etc). Note that not even the Host is a member of the internal network, but this mode allows vm's to function even when the Host is not connected to a network (e.g. on a plane).

Internal Network

Note that in this mode, VirtualBox provides no "convenience" services such as DHCP, so your machines must be statically configured or one of the vm's needs to provide a DHCP/Name service.

Multiple internal networks are possible and you can configure vm's to have multiple NICs to sit across internal and other network modes and thereby provide routes if needed.

But all this sounds tricky. What if you want an Internal Network that the host participates on with VirtualBox providing IP addresses to the Guests? Ah, then for this, you might want to consider Host-only Networking...

Host-only Networking

Host-only Networking is like Internal Networking in that you indicate which network the Guest sits on, in this case, "vboxnet0":

Host-Only Networking

All vm's sitting on this "vboxnet0" network will see each other, and additionally, the host can see these vm's too. However, other external machines cannot see Guests on this network, hence the name "Host-only".

Logically, the network looks like this:

Host-only networking

This looks very similar to Internal Networking but the host is now on "vboxnet0" and can provide DHCP services. To configure how a Host-only network behaves, look in the VirtualBox Manager...Preferences...Network dialog:

Configure Host-only NetworksDHCP Server

Port-Forwarding with NAT Networking

Now you may think that we've provided enough modes here to handle every eventuality but here's just one more...

What if you cart around a mobile-demo or dev environment on, say, a laptop and you have one or more vm's that you need other machines to connect into? And you are continually hopping onto different (customer?) networks.

In this scenario:

  • NAT - won't work because external machines need to connect in.
  • Bridged - possibly an option, but does your customer want you eating IP addresses and can your software cope with changing networks?
  • Internal - we need the vm(s) to be visible on the network, so this is no good.
  • Host-only - same problem as above, we want external machines to connect in to the vm's.

Enter Port-forwarding to save the day!

  1. Configure your vm's to use NAT networking;
  2. Add Port Forwarding rules;
  3. External machines connect to "host":"port number" and connections are forwarded by VirtualBox to the guest:port number specified.

For example, if your vm runs a web server on port 80, you could set up rules like this: 

Port-forwarding Rules

...which reads: "any connections on port 8080 on the Host will be forwarded onto this vm's port 80".

Port Forwarding route

 This provides a mobile demo system which won't need re-configuring every time you open your laptop lid.

Summary

VirtualBox has a very powerful set of options allowing you to set up almost any configuration your heart desires. 
For more information, check out the VirtualBox User Manual on Virtual Networking.

-FB 

Friday Mar 09, 2012

Creating a VirtualBox appliance that uses a click-thru license

Lots of people use VirtualBox to create virtual appliances or vm's which they can share with others. There's a whole host of them over at the OTN Developer VM's page, BTW.

But someone asked me how they would go about about redistributing a vm which required a "click to accept" type of license. Here's how:

When you are happy with the vm that you want to redistribute, you can use the GUI or command-line interface of VirtualBox to export the vm.  

Export 

  1. Choose "File...Export Appliance..." to bring up the Export wizard, then select the vm's that make up your appliance. (Note that you can export multiple vm's here. For example, the database vm may be separate from the business logic vm, etc).

  2. Export Wizard

  3. Choose the flavor of appliance: ovf or ova, and whether to create a manifest (hashes which can be used to determine if the appliance components arrived intact). Note that VirtualBox uses the extension to decide which type (ovf or ova) of appliance to create:

  4. Export Settings

  5. When you get to the Appliance Export Settings dialog you can describe who you are, what the appliance is called as well as specifying license text:

  6. Appliance Export Settings

    You can leave any of these fields empty, however, it is the presence of the License text field that causes VirtualBox to present the License at Import-time.

BTW The command line interface syntax that achieves the same thing is:

$ VBoxManage export
Usage:
VBoxManage export           <machines> --output|-o <ovf/ova>
                            [--legacy09|--ovf09|--ovf10|--ovf20]
                            [--manifest]
                            [--vsys <number of virtual system>]
                                    [--product <product name>]
                                    [--producturl <product url>]
                                    [--vendor <vendor name>]
                                    [--vendorurl <vendor url>]
                                    [--version <version info>]
                                    [--eula <license text>]
                                    [--eulafile <filename>]

So you can create scripts to automate the building of this. 

The end result is the same: an ova file or an ovf file with stream-optimized disk images and an optional manifest file. 

Import

Here's what this appliance would then look like on import: 

  1. From the File...Import... menu in the VirtualBox Manager you select the ova or ovf file and you're show what the appliance contains:

    Appliance Import Settings

    At this point you can modify the devices if required, or change the MAC address (to avoid clashes with existing vm's). 

  2. But on continuing, if there is a License, it gets presented thus:

    Software License Agreement

    So your users can choose whether they want to accept your terms of use or not. 

That's all there is to it.

- FB 

Thursday Feb 24, 2011

VirtualBox and the Unbreakable Enterprise Kernel

This has tripped me up twice now, so time to write it down :-)

Oracle Linux 5 and now also Oracle Linux 6 come with a choice of kernels:

  • a 100% Red Hat compatible one; and
  • the Unbreakable Enterprise Kernel.

When installing VirtualBox, or the VirtualBox Guest Additions, we need to build and install kernel drivers which are dependent on the version of Linux you are using. So we need a few packages to be installed to allow us to do this.

Here's how using the standard kernel:

	yum update
	yum install gcc
	yum install kernel-devel

 or if using the Unbreakable kernel:

	yum update
	yum install gcc
	yum install kernel-uek-devel

 There, now I'll never forget how to do this again.

-FB 

Monday Jun 07, 2010

VirtualBox 3.2.4 is released!

Thanks to all in the community who spotted a couple of regressions with 3.2.2. We couldn't let them pass and so have updated VirtualBox to version 3.2.4 to fix them.

-FB 

Tuesday Feb 09, 2010

Migrating from VMware to VirtualBox (Part 1): Oracle Enterprise Linux

There are a growing number of people asking the question: how do you move a VMware virtual machine to VirtualBox. So it is about time the Fat Bloke rolled up his sleeves and showed us how. (BTW you can click on screenshots below to magnify)

People typically want to do this because they have spent time installing a guest OS together with a software stack and they don't really want to go thru all this again. But moving a vm from one virtualization platform to another is analogous in the real world to unplugging a hard drive(s) from one computer and plugging it into a different manufacturer's computer. You may find that the guest operating system gets upset when it boots up and sees virtual hardware which is different than it was expecting. Different guest operating systems react differently to this situation (Linux is typically more accommodating than Windows in this respect).  In fact some guest operating systems get so upset, they may BSOD (Blue Screen of Death) on you.

Secondly, some of the software that you have installed above the OS, such as VMware Tools, may also be relying on specific virtual hardware.

So the Fat Bloke's First Rule of VM Migration is: Don't, if you can help it. If you can create a new vm from scratch on the new virtualization platform, you probably should. That way the guest OS installs the right drivers for your particular virtual hardware, and you are not left with orphaned software which needs a specific virtualization layer.

That said, there are still going to be people looking to avoid a complete reinstallation and willing to live dangerously, so let's discuss what is possible. Note that because different guests behave so differently we're going to focus on one guest OS in this blog: Oracle Enterprise Linux, and we'll move it from VMware Workstation 7 to VirtualBox 3.1. Here is our start state, the vm running in VMware Workstation 7 on Windows 7:

Starting Position

Step 1 - Preparing to Migrate 

It's a good idea to take a copy of the vm that we're trying to migrate just in case you make a mess of things. With VMware Workstation you can clone a vm to do this or copy the machine in some other way such as copying files.

Clone

To prepare for migration we're going to remove virtualization platform-specific components:

  1. Remove VMware tools
  2. Reset the Display and Input device  configuration
  3. Remove incompatible devices 

The Fat Bloke's Second Rule of VM Migration is that it is easier to unpick platform-specific software on the native virtualization platform. So let's start up the vm under VMware to prepare for migration

Removing VMware Tools 

This is easy enough: 

vmware-uninstall-tools.pl

and you should see something like this:

uninstall tools

Resetting the Display Device and Input Devices

When Oracle Linux was first installed the display was set as a VMware display adaptor and input devices as a VMware keyboard and mouse. By the time we're finished this won't be the case, so let's prepare for that by moving aside the the OEL X.org conf file like this:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.vmware

This file will get recreated later when we run on the VirtualBox platform.

Now let's shutdown the guest. 

Shutdown

Remove Incompatible Devices

The VMware soundcard device is different from the one that VirtualBox exposes so let's remove this device from the vm configuration in the VMware Settings dialog:

Remove Soundcard

Step 2 - Exporting the Virtual Machine

A Virtual Machine consists of :

  • configuration information (in VMware a .vmx file)
  • virtual hard drive(s) which the guest is installed on. (in VMware, typically .vmdk files)

An emerging standard for encapsulating this information to allow vm's to be transported more easily is the OVF or Open Virtualization Format. So in theory you should be able to Export this vm from VMware Workstation and Import into VirtualBox. Sadly, the VMware conversion wizard (File...Import or Export...) doesn't support Oracle Enterprise Linux as a guest:

can't export

But there is a command line ovftool that can be downloaded from VMware's site.

So in a Windows command.exe window you can run:

cd C:\\Users\\fatbloke\\Documents\\Virtual Machines\\Clone of Oracle Enterprise Linux 
"\\Program Files\\VMware\\VMware OVF Tool"\\ovftool.exe "Clone of Oracle Enterprise Linux.vmx" OEL.ovf 

And eventually you end up with 3 files:

  1. OEL.ovf - configuration information
  2. OEL-disk1 - compressed disk format file
  3. OEL.mf -  digital signatures (SHA1) of the other files.

 We can now move these to the destination system for import by VirtualBox.

Step 3 - Importing into VirtualBox 

You can import an ovf file into VirtualBox from the graphical user interface or the command-line.

Import OVF

Importing this takes a while as the compressed disk is converted to a usable format, but your should end up with a new entry in your vm list in VirtualBox like this:

Imported vm

 Now the moment of truth, Start it up...and we should see Oracle Enterprise Linux boot up under VirtualBox

OEL under VirtualBox

 Step 4 - Install the VirtualBox Guest Additions

 Finally don't forget to install the VirtualBox Guest Additions which is the mirror image operation to removing the VMware Tools.

Install Guest Additions

Once you have mounted the Guest Additions iso image you can run install them from the mounted directory using the command:

sh VBoxLinuxAdditions-x86.run 

 Like this:

Install GA

And after a restart of the guest you are all set to go.

Migration is complete! 

Epilogue (Advanced users only)

There is an alternative to step 2 and 3 above for people who know what they are doing.

After performing Step 1 you could simply take the VMware disk image (.vmdk)  and plug this into a manually configured VirtualBox vm. This effectively relies on the user to create an appropriately similar vm instead of relying on the ovf export and import (Steps 2 and 3 above) process. Note that the default disk controller used by VMware is an LSI SCSI controller, so when manually creating a VirtualBox vm you need to configure it appropriately. 

Add SCSI Controller

You still need Step 4 for optimal performance and ease of use. And don't forget the tip about Speeding up Linux Guests too.

Good Luck!

- FB 

About

Fat Bloke

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today