...
However, it is not a good idea to mix hypervisors on the same machine. They get into conflicts over the CPU VM support (VT-x, Nested Paging, etc.). So while you would never install VMWare or Hyper-V just in order to run the Sandbox, if you already have them installed for other projects then it is not necessary to rip them out and replace them with VirtualBox. Running a Sandbox OS disk on VMWare or Microsoft requires changing the hard disk format, creating a VM configuration (number of processors, size of memory, etc.), and then after the OS boots up you have to install the vendor specific Guest Support services and drivers. If you do not know how to do this, ask someone for help.
However, it It turns out that VirtualBox is generally regarded as the best tool to convert one virtual hard disk format to another (VDI, VMDK, VHD). So even if you are not going to use it to run virtual machines, you may need to install it somewhere to do the conversion.
Download and install the current version of Virtualbox from virtualbox.org (at least 5.0.0). Run the installer. Launch the VirtualBox Manager.
Now you have to install a Sandbox VM. This turns out to be a bit more complicated than just copying some files from disk.
The virtual machine definition (the *.vbox file) is an XML text file. It is not hard to read, but it has two types of problems:
For some reason, VirtualBox has decided to remember every DVD image you mounted in the virtual DVD drive. Worse, these images are remembered with a fully qualified path name
<Image uuid="{9d9e4ed4-faaf-4f84-be68-271462e7c756}" location="D:/tpshare/ISO/Fedora-Live-Workstation-x86_64-22-3.iso"/>and the virtual machine will not start if you move this configuration to another machine in which the DVD file image is not in the exact same location. Since there was really no reason to remember the iso file in the first place, the solution is to delete all these lines and then the machine will startA Virtualbox VM is a directory on disk. There is a xxx.vbox file that configures the memory, processors, network, and options of the VM, and a large xxx.vdi file that is the virtual disk.
A VM can become slightly attached to the environment in which it last ran. For example, by default a VM remembers the fully qualified path to any *.iso DVD image files that were previously mounted in its virtual DVD reader. It also may be connected to a virtual network that was configured with a name ("natnet1") on the previous system. If you copy a Virtualbox directory from another computer, you may have to flush the history of previously mounted DVD images and reconnect it to the name of a network that exists on your host computer before it will start up properly.
Sometimes the virtual machine has to be associated with a particular device on the real machine. Your computer may have more than one Audio adapter, and the virtual audio of the VM has to be associated with one of the real audio drivers on your computer. Similarly, you computer may have multiple LAN adapters (wired, wireless, etc.) and in certain network configurations (like "Bridged") the VM has to be associated with one of these adapters. However, if the VM is moved from one computer to another, then these associations with real devices is broken and you have to work with the VirtualBox Manager to change the Settings of the VM so that each of these virtual hardware features is reattached to an appropriate real device on the new machine.
Each Sandbox OS defines a user named "casdev" with admin privileges who is the owner of SandboxData and some other directories on disk. It is an objective that this user have a specific userid number shared on all Unix hosts, so the disk file ownership transfers when the disk is moved from one OS disk to another. If that did not happen, then even though the user is named "casdev" on both systems, the SandboxData disk moved to a new system will appear to be owned by an unknown user and you have to reassign ownership of the work directories by running the chown command as root.
There is a "standard" portable format for VMs called a *.ova file. It saves space by zipping up the hard disk image, and it gives you an opportunity during installation to reconfigure the audio adapter and virtual LAN adapters as part of the installation rather than having to clean up after the fact. The Sandbox may be distributed in this format to save space and download time.
VirtualBox has a feature called "Shared Directory" that allows the host operating system to share one of its directories with the VM (like a network share, but implemented without the network). It is often convenient to have, but the Sandbox process has no standard use for it.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
Where
Oracle Java comes in a standard Red Hat distribution format called an "RPM" that contains both the files and instructions where to put them. Oracle puts a JVM in /usr/local/java. Red Hat official RPMs for JBoss are not available without a subscription, and RPMs for Eclipse are typically several releases behind the current verison. So JBoss comes from http://jbossas.jboss.org/downloads.html and Eclipse comes from http://www.eclipse.org/downloads/ and they are unzipped into subdirectories of /opt.
Then ownership of the directories is assigned to the "casdev" user instead of "root". JBoss contains configuration files and it writes to work directories that are part of the single distribution directory tree, and Eclipse has to change itself whenever you add new software. Eclipse and JBoss could have been put in the casdev HOME directory, but putting them in /opt seems cleaner. They are not, after all, part of your normal development workfiles. The Eclipse workspace that you are using goes in the casdev home.
There are a few things that have to go in the same place in the Sandbox and production. For example, the log files should be written to /var/log/jbossas on the Sandbox because that is where they go in production and that specific path has to go into log4j.xml. The JBoss Server configuration in Eclipse is modified to add -Djboss.server.log.dir=... onto the end of the JBoss start commandthe new computer may not have the same type of audio or LAN adapter and the device name of the association has to be changed.
A VM can be archived in OVA format. This is a semi-standard zip file that contains a special version of the configuration data and a compressed version of the disks. Virtualbox will read an OVA and explode it into a real VM directory. You still may have to go back and change the network names.
There is also a very convenient feature called a "Shared Directory". This allows the host computer to share a directory or an entire disk with the Sandbox VM. It is very much like a disk shared over the network, except that the connection is directly between the host computer and the one VM so there is no extra security environment. Windows users may recognize this arrangement because it is exactly the same as a Remote Desktop Client sharing a disk with your own terminal session on another computer. Because you are the real user on both ends, there is no need for additional authentication and security. However, the directory to be shared is part of the VM configuration and it will break if you shared the D:\ drive on one computer and then move the VM to another computer that doesn't have a D:\ drive. You may have to redefine or delete the Shared Directory before you can start the VM.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
The VM
The VM is a standard Virtualbox 64 bit Linux configuration. With JBoss running the used memory only gos up to does not exceed 1.3 GB, so the amount of virtual RAM for the VM could be reduced to 1.5 or 2 GB if you need to run two VMs on an 8G laptop.
...