IntroductionVirtualBox has a very exible internal design that allows you to use different front-ends to control the same virtual machines. To illustrate, you can, for example, start a virtual machine with VirtualBox’s easy-to-use graphical user interface and then stop it from the command line.
With VirtualBox’s support for the Remote Desktop Protocol (VRDP), you can even run virtual machines remotely on a headless server and have all the graphical output redirected over the network.
1. VirtualBox is our graphical user interface (GUI), which most of this User Manual is dedicated to describing. While this is the easiest-to-use of our interfaces, it does not (yet) cover all the features that VirtualBox provides. Still, this is the best way to get to know VirtualBox initially.
2. VBoxManage is our command-line interface and is described in the next section.
3. VBoxSDL is an alternative, simple graphical front-end with an intentionally limited feature set, designed to only display virtual machines that are controlled in detail with VBoxManage. This is interesting for business environments where displaying all the bells and whistles of the full GUI is not feasible. VBoxSDL is described in chapter 7.3, VBoxSDL
4. Finally, VBoxVRDP is yet another front-end that produces no visible output on the host at all, but merely acts as a VRDP server. Now, even though the other graphical front-ends (VirtualBox and VBoxSDL) also have VRDP support builtin and can act as a VRDP server, this particular front-end requires no graphics support. This is useful, for example, if you want to host your virtual machines on a headless Linux server that has no X Window system installed.
If the above front-ends still do not satisfy your particular needs, it is relatively painless to create yet another front-end to the complex virtualization engine that is the core of VirtualBox, as the VirtualBox core neatly exposes all of its features in a clean COM/XPCOM API.
Using VBoxManage to control virtual machines
This section will give you a brief introduction to VBoxManage and how you can use it to create and operate virtual machines.
In essence, VBoxManage supports everything that our graphical user interface allows you to do with the click of a button. VBoxManage supports a lot more than that, however. It exposes really all the features of the virtualization engine, even those that cannot (yet) be accessed from the GUI.
You will need to use the command line if you want to
• use a different user interface than the main GUI (for example, VBoxSDL or the headless VBoxVRDP server);
• control some of the more advanced and experimental configuration settings for a VM.
There are two main things to keep in mind when using VBoxManage: First, VBoxManage must always be used with a specific “subcommand”, such as “list vms” or “createvm” or “startvm”.
Second, most of these subcommands require that you specify a particular virtual machine after the subcommand. There are two ways you can do this:
• You can specify the VM name, as it is shown in the VirtualBox GUI. Note that if that name contains spaces, then you must enclose the entire name in double quotes (as it is always required with command line arguments that contain spaces).
For example:
VBoxManage startvm "Windows XP"
• You can specify the UUID, which is the internal unique identifier that VirtualBox uses to refer to the virtual machine. Assuming that the aforementioned VM called “Windows XP” has the UUID shown below, the following command has the same effect as the previous:
VBoxManage startvm 670e746d-abea-4ba6-ad02-2a3b043810a5
You can type VBoxManage list vms to have all currently registered VMs listed with all their settings, including their respective names and UUIDs.
Some typical examples of how to control VirtualBox from the command line are listed below:
• To create a new virtual machine from the command line and immediately register it with VirtualBox, use VBoxManage createvm with the -register option,1 like this:
$ VBoxManage createvm -name "SUSE 10.2" -register
VirtualBox Command Line Management Interface Version 1.4.0
(C) 2005-2007 innotek GmbH
All rights reserved.
Virtual machine ’SUSE 10.2’ is created.
UUID: c89fc351-8ec6-4f02-a048-57f4d25288e5
Settings file: ’/home/username/.VirtualBox/Machines/SUSE 10.2/SUSE 10.2.xml’
As can be seen from the above output, a new virtual machine has been created
with a new UUID and a new XML settings file.
• To show the configuration of a particular VM, use VBoxManage showvminfo;
see chapter 8.2, VBoxManage showvminfo, page 80 for details and an example.
• To change VM settings, use VBoxManage modifyvm, e.g. as follows:
VBoxManage modifyvm "Windows XP" -memory "512MB"
For details, see chapter 8.5, VBoxManage modifyvm, page 81.
• To control VM operation, use one of the following:
– To start a VM that is currently powered off, use VBoxManage startvm;
see chapter 8.6, VBoxManage startvm, page 85 for details.
– To pause or save a VM that is currently running, use VBoxManage
controlv.
VBoxSDL, the simplified VM displayer
VBoxSDL is a simple graphical user interface (GUI) that lacks the nice point-and-click
support which VirtualBox, our main GUI, provides. VBoxSDL is currently primarily
used internally for debugging at innotek and therefore not officially supported. Still,
you may find it useful for environments where the virtual machines are not necessarily
controlled by the same person that uses the virtual machine.
As you can see in the following screenshot, VBoxSDL does indeed only provide a
simple window that contains only the “pure” virtual machine, without menus or other
controls to click upon and no additional indicators of virtual machine activity:
To start a virtual machine with VBoxSDL instead of the VirtualBox GUI, enter the
following on a command line:
VBoxSDL -vm
where
UUID of an existing virtual machine.
Remote Desktop Support (VRDP)
VirtualBox, the graphical user interface, has a built-in server for the VirtualBox Remote
Desktop Protocol (VRDP). This allows you to see the output of a virtual machine’s
window remotely on any other computer and control the virtual machine from there,
as if it was running on the remote machine.
VRDP is a backwards-compatible extension to Microsoft’s Remote Desktop Protocol
(RDP). Typically graphics updates and audio are sent from the remote machine to the
client, while keyboard and mouse events are sent back.
With VirtualBox, the graphical user interface, the VRDP server is disabled by
default, but can easily be enabled on a per-VM basis either with the VirtualBox GUI or
with VBoxManage:
VBoxManage modifyvm
If you use VBoxVRDP (described below), VRDP support will be automatically en-
abled.
Additional settings for modifyvm are -vrdpport and -vrdpauthtype; see chap-
ter 8.5, VBoxManage modifyvm, page 81 for details.
VBoxVRDP, the headless VRDP server
While the VRDP server that is built into the VirtualBox GUI is perfectly capable of
running virtual machines remotely, it is not convenient to have to run VirtualBox if
you never want to have VMs displayed locally in the first place. In particular, if you are
running servers whose only purpose is to host VMs, and all your VMs are supposed to
run remotely over VRDP, then it is pointless to have a graphical user interface on the
server at all – especially since, on a Linux host, VirtualBox comes with dependencies
on the Qt and SDL libraries, which is inconvenient if you would rather not have the X
Window system on your server at all.
VirtualBox therefore comes with yet another front-end that produces no visible out-
put on the host at all, but instead only delivers VRDP data. This “headless server” is
called VBoxVRDP.
To start a virtual machine with VBoxVRDP, you have two options:
• You can use VBoxManage startvm
-type option causes the VirtualBox core to use VBoxVRDP as the front-end to
the internal virtualization engine.
• The recommended way, however, is to use VBoxVRDP directly, as follows:
VBoxVRDP -startvm
This is the recommended way, because when starting the headless interface
through VBoxManage, you will not be able to view or log messages that
VBoxVRDP may have output on the console. Especially in case of startup er-
rors, such output might be desirable for problem diagnosis.
Step by step: creating a virtual machine on a headless
server
The following instructions may give you an idea how to create a virtual machine on a
headless server over a network connection. We will create a virtual machine, establish
a VRDP connection and install a guest operating system – all without having to touch
the headless server. All you need is the following:
1. VirtualBox on a server machine with a supported host operating system (Linux
or Windows); for the following example, we will assume a Linux server;
2. an ISO file on the server, containing the installation data for the guest operating
system to install (we will assume Windows XP in the following example);
72
7 Alternative front-ends; remote virtual machines
3. a terminal connection to that host over which you can access a command line
(e.g. via telnet or ssh);
4. an RDP viewer on the remote client; on a Linux client, you could use rdesktop
to connect; from a Windows machine, you could use the RDP viewer that comes
with Windows (usually found in “Accessories” -> “Communication” -> “Remote
Desktop Connection”).
Note that on the server machine, since we will only use the headless server, neither Qt
nor SDL nor the X Window system will be needed.
1. On the headless server, create a new virtual machine:
VBoxManage createvm -name "Windows XP" -register
Note that if you do not specify -register, you will have to manually use the
registervm command later.
2. Make sure the settings for this VM are appropriate for the guest operating system
that we will install. For example:
VBoxManage modifyvm "Windows XP" -memory "256MB" \
-acpi on -boot1 dvd -nic1 nat
3. Create a virtual hard disk for the VM (in this case, 10GB in size) and register it
with VirtualBox:
VBoxManage createvdi -filename "WinXP.vdi" -size 10000 -register
4. Set this newly created VDI file as the first virtual hard disk of the new VM:
VBoxManage modifyvm "Windows XP" -hda "WinXP.vdi"
5. Register the ISO file that contains the operating system installation that you want
to install later:
VBoxManage registerimage dvd /full/path/to/iso.iso
6. Attach this ISO to the virtual machine, so it can boot from it:
VBoxManage modifyvm "Windows XP" -dvd /full/path/to/iso.iso
(Alternatively, you can use VBoxManage controlvm dvdattach directly,
without having to register the image first; see chapter 8.7, VBoxManage con-
trolvm, page 85 for details.)
7. Start the virtual machine using VBoxVRDP:
VBoxVRDP -startvm "Windows XP"
If everything worked, you should see a copyright notice. If, instead, you are
returned to the command line, then something went wrong.
8. On the client machine, fire up the RDP viewer and try to connect to the server.
Assuming a Linux client, try the following:
73
7 Alternative front-ends; remote virtual machines
rdesktop -a 16 my.host.address
(With rdesktop, the -a 16 option requests a color depth of 16 bits per pixel, which
we recommend. Also, after installation, you should set the color depth of your
guest operating system to the same value.)
You should now be seeing the installation routine of your guest operating system
Remote USB
As a special feature on top of the VRDP support, VirtualBox supports remote USB
devices over the wire as well. That is, the VirtualBox guest that runs on one computer
can access the USB devices of the remote computer on which the RDP data is being
displayed the same way as USB devices that are connected to the actual host. This
allows for running virtual machines on a VirtualBox host that acts as a server, where
a client can connect from elsewhere that needs only a network adapter and a display
capable of running an RDP viewer. When USB devices are plugged into the client, the
remote VirtualBox server can access them.
For these remote USB devices, the same filter rules apply as for other USB devices,
as described with chapter 3.7.6.1, USB settings, page 41. All you have to do is specify
“Remote” (or “Any”) when setting up these rules.
RDP authentication
For each virtual machine that is remotely accessible via RDP, you can individually
determine if and how RDP connections are authenticated.
For this, use VBoxManage modifyvm command with the -vrdpauthtype op-
tion; see chapter 8.5, VBoxManage modifyvm, page 81 for a general introduction.
Three methods of authentication are available:
• The “null” method means that there is no authentication at all; any client can
connect to the VRDP server and thus the virtual machine. This is, of course, very
insecure and only to be recommended for private networks.
• The “external” method provides external authentication through a special au-
thentication library.
VirtualBox comes with two default libraries for external authentication:
– On Linux hosts, VRDPAuth.so authenticates users against the host’s PAM
system.
– On Windows hosts, VRDPAuth.dll authenticates users against the host’s
WinLogon system.
In other words, the “external” method per default performs authentication with
the user accounts that exist on the host system.
However, you can replace the default “external” authentication module with any
other module. For this, VirtualBox provides a well-defined interface that allows
74
7 Alternative front-ends; remote virtual machines
you to write your own authentication module; see chapter 9.3, Custom external
VRDP authentication, page 93 for details.
• Finally, the “guest” authentication method performs authentication with a special
component that comes with the Guest Additions; as a result, authentication is
not performed with the host users, but with the guest user accounts. This method
is currently still in testing and not yet supported.
RDP encryption
RDP features data stream encryption, which is based on the RC4 symmetric cipher
(with keys up to 128bit). The RC4 keys are being replaced in regular intervals (every
4096 packets).
RDP provides three different authentication methods:
1. Historically, RDP4 authentication was used where the RDP client does not per-
form any checks in order to verify the identity of the server it connects to. Using
a man in the middle (MITM) attack, the user’s credentials could be obtained.
Therefore RDP4 authentication is insecure and should generally not be used.
2. RDP5.1 authentication employs a server certificate for which the client possesses
the public key. This way, it is guaranteed that the server must possess the corre-
sponding private key. However, this hardcoded private key became public some
years ago and therefore RDP5.1 authentication must be considered to be inse-
cure and should generally not be used.
3. RDP5.2 authentication is based on TLS 1.0 with customer supplied certificates.
The server supplies a certificate to the client which must be signed by a certificate
authority (CA) that the client trusts (for the Microsoft RDP Client 5.2, the CA
has to be added to the Windows Trusted Root Certificate Authorities database).
VirtualBox allows you to supply your own CA and server certificate and uses
OpenSSL for encryption.
While VirtualBox supports all of the above, only RDP5.2 authentication should be
used in environments where security is a concern. As the client that connects to the
server determines what type of encryption will be used, with rdesktop, the Linux RDP
viewer, use the -4 or -5 options.
0 comments:
Post a Comment