This is a generic post regarding the usage of Virtual Machines and I will bring up topics that I frequently get asked about. There are several reasons why a Virtual Machine is a good choice for a development platform. A couple of reasons might be:
- The env. is contained as a whole and separate from whatever is happening on your host (host here equals the physical machine and guest will refer to the vm). This means that if you need to change host or upgrade OS isn't a big deal. Just have a backup of the VM's.
- You can share your whole dev. env. by simply let someone get a copy of the VM. This is how we share our demo env. internally from Development to the Field organizations.
Performance is rarely an issue anymore since most people should have access to a laptop/pc with at least 8GB RAM and the host OS should be 64 Bit. Some people even have access to SSD drives which removes the last bottleneck, Disk IO.
Moving from VMware to VBox
Inside Oracle most every product team these days share their new releases or early betas using pre-configured VM's and we see them in basically two formats, VirtualBox exports (sometimes just the VDI file) and VMware VM's. VirtualBox will handle both formats with ease. Most everything is now done on linux at Oracle so we see very few VM's with other OS's. Sharing the VM is the same but with Linux there are now license issues.
Some of the product demo VM's are now also available on OTN, http://www.oracle.com/technetwork/community/developer-vm/index.html
Unless the VM is shared in a VBox export format (which is of course is imported via File - Import Appliance) you can create a new empty VM but skip the disk creation step.
Screen shot above showing the step in the Create New Virtual Machine Wizard where the Disk file will be created. Un-check the checkbox and click Continue.
Later in VBox you can just add the disk file (the VDI or VMDK file). Screen shot above shows where to add the disk file in the Storage section in the Settings for the VM. Only thing you need to know is what type of controller that was used in the original VM, IDE, SATA or SCSI. If you have a VMware VM you can just open the .vmx file with any text editor and you can find this info in there.
When you have the VM running in VBox you will have to install the Guest Addtions (and if this was a VMware VM you need to remove VMware Guest Tools).
The Guest Addistions install will compile some kernel extensions and the Guest (the Virtual Machine) needs to be setup so that it can do just that, compile and build kernel extension. I will cover this in more detail later as it's rarely an issue. It can be an issue if you build a Guest from scratch and forgets to add these components (some kernel packages, the gcc compiler etc.).
Most questions I get relates to network issues and I think by now I have convinced most people to do what I do almost 100% of the time, run the guest with NAT networking. It will basically always just work. Regardles if your host is connected to a network or not. It also allows you to do everything you would expect from within the VM in terms of inbound and outbound traffic. Some tidbits of info:
- Each NAT guests on a host will have it's own subnet and they will all have the IP 10.0.2.15.
- A NAT guest will piggyback on the hosts's external IP and will have the same reach as the host. This also applies to VPN connections which means that if the host is on a VPN connection all NAT'd VM's will also be "on VPN". More interesting is perhaps that all these VM's can be reached from the VPN network using the Host's VPN IP. More on this under Port Forwarding below.
- You can create 4 Network interfaces using the VBox GUI (you can create another 4 using the command line interface). Other than NAT you can have Bridged, Host-only, Internal and a Generic mode. More on these modes here: http://www.virtualbox.org/manual/ch06.html#networkingmodes
This is one of the differentiating factors between VMware Player (Linux/Windows), VMware Fusion (Mac) and VirtualBox. VMware Workstation (Windows/Linux) has this feature but comes with a price tag of $189 currently. Oracle stopped licensing VMware Workstation around version 5.5 (current is 7.1) so my experience is a bit outdated but in 5.5 Port Forwarding was a bit complicated to setup. Not exactly intuitive, not the first time anyway.
The Port Forwarding button opens the dialog below and I would say that this is pretty intuitive, correct?
The name column is just for information purposes, you can write whatever you want or leave the default value which is Rule1, Rule2 etc. Protocol is a dropdown and it's either TCP or UDP. Host and Guest IP can be left blank (VBox knows both already). Left to configure is what port in the guest that should be exposed on the host.
With port forwarding configured any service running in the guest can be reached via the host's IP and Port. As an example using the ports above you can connect with ftp from the host to the ftp server inside the guest with ftp://localhost:8021/. If someone on the same network wants to access the ftp server in the guest on your host they would simple replace localhost with the actual IP of your host. They don't need any info about the guest IP. They don't even need to know that this is a VM running on your laptop/desktop.
All the details here: http://www.virtualbox.org/manual/ch06.html#natforward
This is totally transparent to the host and the guest in most cases. One case where you need to do a little bit of configuration inside the guest is if you run a WLS instance and want to deploy to it from a JDev (or any other tool) running on the host or remote. The WLS instance inside the guest needs to know the real IP of the host for this to work. There is a such a setting in the Advanced Section on the WLS Server Console, External Listen Address. Map this to the real IP of host and everything should work just fine.
Navigate to the WLS Console for the AdminServer and click on the Advanced link and the settings shown above will appear.
There are several ways to access a guest both when you're local on the host or if you want to access your guest remotely or give someone else remote access to a guest that runs on your laptop/desktop. You can configure VNC inside the guest or enable Remote Desktop if it's Windows. You can install tools like NX from nomachine.com or Teamviewer from teamviewer.com inside the guest. Assuming we still run NAT you will need to configure Port Forwarding for any solution that runs as a process inside the guest, even pure command line tools like telnet and ssh. But there is a better alternative. Install nothing! Take a look at the dialog below. It shows the Display Settings for one of my guest. VirtualBox has a built-in Remote Display feature and it's better than anything VMware or Parallels have if you ask me.
Remote Display exposes the Console output of the guest using RDP. This means that you can access your linux guest VM's desktop remotely (or locally from the host) using Windows Remote Desktop (or any RDP client on Mac or Linux) and dynamically resize the remote window. you can also copy and paste text (this might behave a little different depending on the guest OS). Since it's the Console you have access to and the Remote Display Server is hosted by VBox and not the guest OS it will also stay connected during a reboot so you can see the usual Console output as if you had local access. As you can see from the dialog you can also share this Remote Display with multiple users. This Remote Display access has no connection to what type of Network your guest is using, NAT, Bridged, Host-only or even no networking. You can always enable the Remote Display.
I'll stop here for now but I will return with more on Virtualization. Both regarding VirtualBox and OVM.