...
While production services for some reason refuses to put routine maintenance on their VMs, the Sandbox is typically kept up to date with the latest bug fixes.
We would never run VirtualBox as a production hypervisor, but it is perfectly adequate for development. Of course, you are free to run Hyper-V if it is already installed on your laptop.
To fully exercise every part of an application you may have to install optional libraries in the system. Nominally the Netid application requires the kadmin Kerberos library to run, but it exposes a parameter and if you install it with "kadm5_activation=false" then it doesn't use that library and can even run on Windows. When a particular system service is only marginally important and can be bypassed or mocked out, this is a best practice.
...
The Sandbox system allows to to edit, compile, and debug the program. After debugging, the Sandbox commits source changes back to Subversion. To move those changes even into DEV requires a Jenkins Build job that checks the source out of Subversion, reruns the compile, and stores the JAR or WAR on the Artifactory server. So the only external consequences of the Sandbox development are the source changes in Subversion. Except for that, everything that happens in the Sandbox is private and doesn't matter.
Installation
First you download and install the current version of Virtualbox from virtualbox.org. You only require Conceptually the Sandbox can run on VMWare Player or Hyper-V, but the disk format has to be converted and if you intend to use the supplied OS disks, then their drivers should be updated. Generally speaking, VirtualBox turns out to be the tool everyone points to when they want to convert a virtual hard disk file from one vendor format to another. So you may need to install VirtualBox as a tool even if you want to try to use a different VM host software.
Download and install the current version of Virtualbox from virtualbox.org. Unfortunately, this is a moving target because virtualbox itself is changing and the operating systems it hosts are changing. However, you only need a version that is reasonably stable . You will not be running production servers under it 24x7, and you will not be using the more exotic personal desktop features like 3D video acceleration or USB passthrough.
Because the Sandbox has no special requirements for the virtual machine host, this is one place where you are free to prefer VMWare Player or Hyper-V if you already have them installed.
Later on you can decide to mount the SandboxData files natively on your Windows or Linux laptop. This should not be your initial choice because you may have to change some native OS configuration parameters, and it is better to get used to the VM before you attempt an advanced configuration process on your normal machine.
There is an admin user named "casdev" defined in every Sandbox OS. Yes, the name comes from designing the Sandbox first to develop CAS, but there was no reason to rename a perfectly good userid. Casdev user is the owner of all the directories on SandboxData and must have at least write privileges to any directory used during execution (/var/log/jbossas/standalone for example). Because JBoss runs from Eclipse interactively instead of as a service, there is no service account for JBoss or Tomcat or the applications. Casdev runs everything.
Once you have VirtualBox installed, the next step is to install a Sandbox VM.and has the convenience features you need. It is a hard problem to choose a system for 24x7 production servers with the ability to dynamically migrate them across systems. On desktop machines, it is a hard problem to do 3D video acceleration or play YouTube from the VM. The Sandbox doesn't have any of these problems. It needs to run Eclipse, and that is a fairly simple requirement to meet.
It is possible to put the SandboxData files on your native laptop OS and do without the VM entirely. This is a good choice if you have only one software project that you develop full time. If you have to jump from application to application, then setting up each new application may be too much trouble. So doing the Sandbox on you native laptop is an advanced configuration that you try later, rather than a choice you make initially.
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 it with the chown command.
Once you have the OS system disk and the SandboxData disk sorted out, there is still a requirement to define the parameters of the VM. You must assign a number of processors, size of memory, type of disk controller, and so on. In VirtualBox this is done with an XML file with an extension of *.vbox.
Virtual Machines are an advanced feature, and people who use them need the ability to specify some advanced options. For example, the host computer can have more than one LAN adapter. One LAN adapter could be connected to the public internet, while the second adapter would be connected to a "lab" network that only includes in one room belonging to your group. When you define a VM, you need to configure its virtual LAN adapter. It could be entirely imaginary and exist only inside your machine, or it could be "connected" to one of the two real LANs. Is it going to be connected to the Internet or to the Lab network? The VirtualBox configuration tool allows you to make the choice.
...