QEMU and KVM

KVM is the Linux kernel module that enables this mapping of physical CPU to Virtual CPU. VT-x and the AMD equivalent is AMD-V. Using these technologies, a slice of physical CPU can be directly mapped to the Virtual CPU. Hence the instructions meant for the Virtual CPU can be directly executed the physical CPU slice.
By itself, KVM is more of a virtualization infrastructure provider. KVM needs QEMU to provide full hypervisor functionality.

If your server CPU does not support virtualization extension, then it is the job of the emulator (or hypervisor) to execute the Virtual CPU instruction using translation. QEMU without KVM uses TCG or Tiny Code Generator to optimally translate and execute the Virtual CPU instructions on the physical CPU.

QEMU by itself is a Type-2 hypervisor. It intercepts the instructions meant for Virtual CPU and uses the host operating system to get those instructions executed on the physical CPU. When QEMU uses KVM for hardware acceleration, the combination becomes a Type-1 hypervisor. This difference is quite clear from the description on the QEMU website.

QEMU can alsol use Xen

KVN Necessary components

virt-manager - v1.0+ graphical manager for the vms. Python app
virt-viewer - video acceleration and clipboard sharing etrc. does it though the SPICE library http://www.spice-space.org
or
spicy - from sudo apt-get install spice-client-gtk
(for video acceleration you might have to change command as following: remove the existing -vga vmware qemu-kvm option, and add these options: -vga qxl -device virtio-serial-pci -spice port=5900,password=mypass -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent)
https://en.wikipedia.org/wiki/SPICE_%28protocol%29

SPICE may need guest side components to be installed and/or built into QEMU - http://www.spice-space.org/download.html
https://en.wikipedia.org/wiki/SPICE_%28protocol%29

ii qemu-keymaps 2.0.0+dfsg-2ubuntu1.22 all QEMU keyboard maps
ii qemu-kvm 2.0.0+dfsg-2ubuntu1.22 amd64 QEMU Full virtualization
ii qemu-system-common 2.0.0+dfsg-2ubuntu1.22 amd64 QEMU full system emulation binaries (common files)
ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.22 amd64 QEMU full system emulation binaries (x86)
ii qemu-utils 2.0.0+dfsg-2ubuntu1.22 amd64 QEMU utilities

ii libvirt-bin 1.2.2-0ubuntu13.1.17 amd64 programs for the libvirt library
ii libvirt0 1.2.2-0ubuntu13.1.17 amd64 library for interfacing with different virtualization systems
ii libvirtodbc0 6.1.6+repack-0ubuntu3 amd64 high-performance database - ODBC libraries
ii python-libvirt 1.2.2-0ubuntu2 amd64 libvirt Python bindings
ii virt-manager 0.9.5-1ubuntu3 all desktop application for managing virtual machines
ii virt-viewer 0.5.6-2 amd64 Displaying the graphical console of a virtual machine
i

KVM Networking

When the libvirt daemon is first installed on a server, it comes with an initial virtual network switch configuration. This virtual switch is in NAT mode, and is used by installed guests for communication. (ie to the outside network)

http://wiki.libvirt.org/page/VirtualNetworking
root
https://help.ubuntu.com/community/KVM/Networking

http://www.linux-kvm.org/page/Networking

KVM vs VirtualBox

virtualbox needs proprietary extension for usb etc sharing
owned by oracle

QEMU+KVM on ubuntu 64 bit intel host is better than VirtualBox

Virtualbox has nicer-easier interface (no need for spice etc)

Where are VMs stored on KVM

/etc/libvirt/qemu

VirtualBox VRDP

http://www.virtualbox.org/manual/ch07.html

RDP authentication

For each virtual machine that is remotely accessible via RDP, you can individually determine if and how client connections are authenticated. For this, use VBoxManage modifyvm command with the --vrdeauthtype option; see the section called “VBoxManage modifyvm” 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 authentication library. VirtualBox ships with two such authentication libraries:

The default authentication library, VBoxAuth, authenticates against user credentials of the hosts. Depending on the host platform, this means:

On Linux hosts, VBoxAuth.so authenticates users against the host's PAM system.

On Windows hosts, VBoxAuth.dll authenticates users against the host's WinLogon system.

On Mac OS X hosts, VBoxAuth.dylib authenticates users against the host's directory service.[33]

In other words, the "external" method per default performs authentication with the user accounts that exist on the host system. Any user with valid authentication credentials is accepted, i.e. the username does not have to correspond to the user running the VM.

An additional library called VBoxAuthSimple performs authentication against credentials configured in the "extradata" section of a virtual machine's XML settings file. This is probably the simplest way to get authentication that does not depend on a running and supported guest (see below). The following steps are required:

Enable VBoxAuthSimple with the following command:
VBoxManage setproperty vrdeauthlibrary "VBoxAuthSimple"

To enable the library for a particular VM, you must then switch authentication to external:
VBoxManage modifyvm <vm> --vrdeauthtype external

Replace <vm> with the VM name or UUID.

You will then need to configure users and passwords by writing items into the machine's extradata. Since the XML machine settings file, into whose "extradata" section the password needs to be written, is a plain text file, VirtualBox uses hashes to encrypt passwords. The following command must be used:
VBoxManage setextradata <vm> "VBoxAuthSimple/users/<user>" <hash>

Replace <vm> with the VM name or UUID, <user> with the user name who should be allowed to log in and <hash> with the encrypted password. As an example, to obtain the hash value for the password "secret", you can use the following command:
VBoxManage internalcommands passwordhash "secret"

This will print
2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b

You can then use VBoxManage setextradata to store this value in the machine's "extradata" section.

As example, combined together, to set the password for the user "john" and the machine "My VM" to "secret", use this command:
VBoxManage setextradata "My VM" "VBoxAuthSimple/users/john"

Finally, the "guest" authentication method performs authentication with a special component that comes with the Guest Additions; as a result, authentication is not performed on the host, but with the guest user accounts.

This method is currently still in testing and not yet supported.

In addition to the methods described above, you can replace the default "external" authentication module with any other module. For this, VirtualBox provides a well-defined interface that allows you to write your own authentication module. This is described in detail in the VirtualBox Software Development Kit (SDK) reference; please see Chapter 11, VirtualBox programming interfaces for details.
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 different authentication methods:

Historically, RDP4 authentication was used, with which the RDP client does not perform any checks in order to verify the identity of the server it connects to. Since user credentials can be obtained using a "man in the middle" (MITM) attack, RDP4 authentication is insecure and should generally not be used.

RDP5.1 authentication employs a server certificate for which the client possesses the public key. This way it is guaranteed that the server possess the corresponding private key. However, as this hard-coded private key became public some years ago, RDP5.1 authentication is also insecure.

RDP5.2 authentication uses the Enhanced RDP Security, which means that an external security protocol is used to secure the connection. RDP4 and RDP5.1 use Standard RDP Security. VRDP server supports Enhanced RDP Security with TLS protocol and, as a part of TLS handshake, sends the server certificate to the client.

The Security/Method VRDE property sets the desired security method, which is used for a connection. Valid values are:
Negotiate - both Enhanced (TLS) and Standard RDP Security connections are allowed. The security method is negotiated with the client. This is the default setting.
RDP - only Standard RDP Security is accepted.
TLS - only Enhanced RDP Security is accepted. The client must support TLS.

For example the following command allows a client to use either Standard or Enhanced RDP Security connection:
vboxmanage modifyvm NAME --vrdeproperty "Security/Method=negotiate"

If the Security/Method property is set to either Negotiate or TLS, the TLS protocol will be automatically used by the server, if the client supports TLS. However in order to use TLS the server must possess the Server Certificate, the Server Private Key and the Certificate Authority (CA) Certificate. The following example shows how to generate a server certificate.
Create a CA self signed certificate:
openssl req -new -x509 -days 365 -extensions v3_ca -keyout ca_key_private.pem -out ca_cert.pem
Generate a server private key and a request for signing:
openssl genrsa -out server_key_private.pem
openssl req -new -key server_key_private.pem -out server_req.pem
Generate the server certificate:
openssl x509 -req -days 365 -in server_req.pem -CA ca_cert.pem -CAkey ca_key_private.pem -set_serial 01 -out server_cert.pem

The server must be configured to access the required files:
vboxmanage modifyvm NAME --vrdeproperty "Security/CACertificate=path/ca_cert.pem"

vboxmanage modifyvm NAME --vrdeproperty "Security/ServerCertificate=path/server_cert.pem"

vboxmanage modifyvm NAME --vrdeproperty "Security/ServerPrivateKey=path/server_key_private.pem"

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.
Multiple connections to the VRDP server

The VRDP server of VirtualBox supports multiple simultaneous connections to the same running VM from different clients. All connected clients see the same screen output and share a mouse pointer and keyboard focus. This is similar to several people using the same computer at the same time, taking turns at the keyboard.

The following command enables multiple connection mode:
VBoxManage modifyvm "VM name" --vrdemulticon on