Installing and Running the VM

VirtualBox

In the build-svmp.sh script at the “Images to Build” screen, choose the “ovf-vbox” option. This will initiate a preset build with 2 virtual disks attached via a SATA controller in the resulting VM appliance.

Note for laptop users: VirtualBox will pass ACPI data from the host into the VM by default. If you start the VM while running on battery, VBox will incorrectly pass a “sleep” command to the VM causing it to immediately shutdown right after it’s finished booting. To correct, either plug in to the wall or configure VBox to not do ACPI pass-through.

Note 2: You can add a serial port device to the VM to get access to dmesg and init console log. If you attach an interactive pty to that serial port, you can also get a local root shell.

VMware

In the build-svmp.sh script at the “Images to Build” screen, choose the “ovf-vmware” option. This will initiate a preset build with 2 virtual disks attached via a SCSI controller in the resulting VM appliance.

KVM

There is not yet an appliance build for KVM, so a slightly longer approach is required.

In the “Image to Build” screen of the build script, choose “qcow2”.

At the “Drive Type” screen, choose the appropriate model for the drive controller type you will be using. For virtio para-virtualized disks (recommended for best performance), select the “vdx” option.

Select “all-in-one” or “separate” system and data disks per your preference

This build will create one or more qcow2 files in ${SVMP_AOSP_ROOT}/out/target/product/svmp/

Convert android_system_disk.img and android_data_disk.img to QCOW2 format using qemu-img.

OpenStack (with KVM compute nodes)

Build QCOW2 virtio images as per the KVM instructions above

Upload the resulting images to glance.

Create a cinder volume based on the android_data_disk glance image. This will become the master copy that every new user’s persistent data disk is cloned or snapshotted from.

Launch a new VM instance from the system disk image. Use a flavor that has at least 1GB for the root disk and 1GB of RAM. Ephemeral disk can be left as zero.

Configure the security groups as needed. See below.

[Optional] Connect a VM to the “gold image” volume made in step 3 and install any applications and configure any settings you’d like all users to have (keep in mind the entire environment will be cloned). Detach the VM when you’re done.

Create a cinder volume for each user account using the “gold” snapshot from step 3 as the base. Attach this new volume to the now running VM.

Hard Reboot the VM instance so it can find the now attached data volume.

Security Groups

Openstack security groups can be used to effectively create host-based firewalls for the SVMP instances. If you use this feature, these are the ports that must be allowed access.

SVMP Server

Inbound TCP 8001 from the svmp-server

WebRTC

Outbound TCP and UDP 3478 to your STUN/TURN server

If using STUN, Inbound and Outbound UDP on all ports if using STUN for NAT traversal

If using TURN relay, Inbound and Outbound UDP on ports 49125-65535 to/from the TURN server (or match the range configured in the TURN server if not the default)

Debugging (ADB and SSH shells)

Inbound TCP 5555

Inbound TCP 22 (only accessible if you built the VM image with an embedded SSH keypair)

Data Disks

SVMP 1.5.0+

In SVMP 1.5.0 and newer, the data disk is automatically created from scratch by the build system based on the settings in the BoardConfig.mk and image_build/svmp_*_image_layout.conf files in device/mitre/svmp/.

Also in 1.5.0, the cache partition has moved from data disk to the system disk. For backwards compatibility, the data volumes created will still contain a partition in the slot previously occupied by cache, so old data volumes will still work on newer VM versions.

To customize the data partition size simply alter the value (in bytes) of BOARD_USERDATAIMAGE_PARTITION_SIZE in BoardConfig.mk to something of your choosing. If necessary, also adjust the “num_lba” value in the layout.conf file so to sufficient size for all the contained partitions.

SVMP 1.4.1 and below

The default data disk created by the build system and output as android_data_disk.img is a 5GB disk with 4GB assigned to /data and 1GB to /cache.

Several alternate images in a variety of sizes can be found in ‘device/mitre/svmp/data-disk-blanks’ named by the size of the /data partition. All contain a 1GB cache partition.

If the prebuilt images don’t fulfill your needs you can create a custom blank data disk with the following steps.

Create a sparse file of the desired size

$ dd if=/dev/zero of=android_data_disk.img bs=1 count=0 seek=

Create partitions within the image for /cache and /data. The /cache partition should be approximately 1GB and /data is configurable, but should be at least 1GB itself.