Connecting To A Virtual Machine

Published Date: 02 Nov 2017

The virtual lab has to be setup and configured to act as the base for the VoIP virtual tutorial environment. Having discussed and specified software choices for each stage of building an Asterisk VoIP PBX environment, applications now have to be installed and configured. This stage is described in sequence as the environment is built. VoIP voice quality does rely on bandwidth, PSTN networks do present advantages over VoIP in this regard. The literature review concluded that dial up connections do not provide the bandwidth required for VoIP networks.

Traditionally implementing of a project involves ongoing user and management feedback and support. For instance if a company had commissioned a VoIP tutorial environment there would be continual involvement and opportunities to mould and build the application to requirements. With this model there is also scope for less generalities where decisions become less ubiquitous. As there is not a user-designer communication the entire project has to be concluded without alternative views on problem solving and design approaches. Typically the user would ask question relating to functionality and would provide an option for testing. Evidently the project must be designed and implemented by relying on generalities of requirements. In other terms this project can be seen as a beta version designed purely for theoretical means.

In this section the VoIP virtual tutorial environment will be designed and implemented based on research conclusions from the literature review and project objectives. The complexity of implementing each component dictates that explanation and justification of practices be explained. There are theoretical and practical challenges in utilising the software and hardware solutions to enable voice signals to be traversed across a secure and reliable VoIP network. VMware workstation will be used as the virtualisation platform, the CentOS operating system will then be used to host the Asterisk PBX server application. The soft phone software as well as Wireshark will also be installed on CentOS. For the purposes of this project two separate identical Virtual Machines will incorporate this setup to allow for communication between machines and analysis purposes. The figure below logically represents the plan for the VoIP Virtual tutorial environment from an application level.

Figure 1: Virtual Tutorial Environment

To begin the implementation the VMware platform will be installed and configured on top of the Windows 7 PC. When creating the virtual machines in VMware player configuration settings need to be defined. VMware needs to be configured for optimal performance whilst making provisions for power saving. As this environment needs to distributed, configuring VMware to allow for remote access would provide a Software as a Service (SaaS) solution. SaaS environments allow for users to access software over a network connection. Using this model will provide easier administration as there will not be multiple desktop based distributions to configure. Patch management and automatic updates, compatibility, collaboration and of course accessibility.

VMware Setup

As the operating system to be installed on VMware is centos it is important to configure settings that most appropriate for running CentOS. The minimum install requirements for CentOS are surprisingly modest. A text-only install can be completed with as little as 128MB of RAM. The CentOS Project (centos.org, 2013) provides a list of tested minimum requirements for an install, but for the majority of production uses, a more substantial deployment in necessary. The requirements are as follows: 500 MHz processor or higher, 256 MB minimum. Typically a minimum of 3GB of RAM and hard drive space of 2GB for medium to large implementations. Section 3.1 Software requirements outlined the specification of the PC used to developed the tutorial environment. These specifications are easily able to meet the requirements for installations and use. VMware provides simple instructions for installing the product, after installing the software onto the PC and updating to the latest version the configuration needed to take place. The VM was configured to use bridged connections for network connectivity. Bridged networking utilises the Ethernet connection of the host machine which can be wired or wireless on a windows host. With bridges networking each virtual machine has to have its own IP address on the TCP/IP network, this way the VMs can act as full members of the network. Before proceeding to installing the CentOS operating system a new virtual machine was created within VMware Player. When creating a new virtual machine four files are added to the VM directory. These are the virtual disk file (.vmkd), team configuration file (.vmxf), metadata file (.vmsd) and the virtual machine configuration vile (.vmx). The .vmx file needs to be modified so that Virtual Network Connection (VNC) can be enabled allowing remote access. Providing the SaaS functionality mentioned earlier.

4.1.1 Configuring A Virtual Machine For Access By A VNC Client

For a virtual machine to have VNC connectivity the configuration file (.vmx) has to be modified when the machine in shutdown. The Virtual machine has yet not been powered on so at this stage the configuration can take place without any problems. The .vmx file is opened in text format for editing, certain lines of code need to be added for enabling connection. RemoteDisplay.vnc.enabled = TRUE, This line is set to TRUE which allows for VNC standard to be supported. As with any VNC connection the host has to be powered on for connection to take place. RemoteDisplay.vnc.port = ****, VNC uses port numbers for connection, the port number has to be specified on this line. As default the port number selected will be 5900, when using more that on VM a unique port number has to be assigned to each. VMware specifies that a port number between 5900 and 5999 is preferable. Just now this will be left as default, port numbers can be assigned when other VMs are added. As other ports are used by other applications it is important to create any conflicts here by using the same port number twice. Although adding the RemoteDisplay.vnc.enabled = TRUE line does specify that port 5900 is used as default the RemoteDisplay.vnc.port line can be added to the file but commented out at this point. RemoteDisplay.vnc.password = ********, Here a password is set for authentication and security, an eight character password must be selected. Upon imitating the VNC connection this will be asked for.

Connecting to a virtual machine with a VNC Client

Connecting to the virtual machines using a VNC client is a basic operation, the IP address and port number specified in the RemoteDisplay.vnc.port line in the .vmx configuration file. Authentication then takes place by entering a username and the password. As security and encryption are important the fact that VNC uses weak password encryption is an issue. Data is sent through VNC unencrypted because of this a secure tunnel is used through SSH.

Initially connection through VNC failed which was upon research pointed towards built in VNC capability with WMware server and workstation implementations. It was believed that VMware player could not offer this support. Further research indicated that it was in fact a windows firewall problem that was easily rectified.

CentOS Setup

After the VMWare machine was created the next step was to install CentOS. An ISO was downloaded for the CentOS mirror site, from there the GUI installer was used to install the base system. Basics like the language was selected (English). Then the keyboard typeStorage type was selected, then the hostname for the Server was set. The timezone / locationset and root password for disk partitioning was assigned, as this was a fresh install the option "Use All Space" was selected. After completing the install the system was logged into as root to update the system using "yum update". The interface IP configuration takes place automatically where the IP and Netmask is assigned. The firewall for CentOS was disabled, firewall (and SELinux)configuration with iptables and CentOS will be discussed later. Numerous services not needed for this implementation were removed (Bluetooth, firstboot etc) whilst Network manager was enabled for connection availability. The goal was to streamline the OS where services and applications were analysed for any potential compatibility or detrimental effects on the VoIP network. The afore mentioned Wireshark application was downloaded and installed using default settings which will be looked at later in this dissertation.

Setting Data Capture Filters

Setting up sample data captre filters within the virtual machines allows for analysis by users into network traffic. Protocol values and relevant network traffic is to be used by users to understand the VoIP functionality and security threats. Snort is an Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) application. Snort can be used to inspect network traffic and log specific packets depending on the rules set. An efficient way of using snort is with Packet Capture (PCAP) files which contain rules for capturing known suspicious packets. As Wireshark is being utilised for this project it s more efficient to use a plug-in instead of Snort to make use of these PCAP files. Wireshark would need to translate snort filters into wireshark filters taking up more time. WireShnork is a plug-in for this purpose, it automatically translates snort rules for Wireshark.

Asterisk PBX Setup

To Install and configure Asterisk first CentOS was logged into as the ‘root’ user (superuser). The ‘current’ Asterisk source tarball was downloaded to the host machine. This downloaded the latest (minor) version of Asterisk. The current directory was changed to the newly created source directory where ‘install_prereq’ in thecontrib/scripts subdirectory was executed. This installs the required dependencies and all the packages essential to build all option Asterisk components. As Asterisk is running as non root, Asterisk has to know which user to run as. This is done via the asterisk.conf file. It is then copied (sample version) from the Asterisk source to /etc/asterisk. To tell Asterisk what modules to load the modules.conf file is used. Create the file modules.conf in /etc/asterisk/ directory. For now this is all the configuration needed.

Zoiper Softphone Setup

Zoiper Softphone was downloaded from the Zoiper website, the installation was completed on CentOS. After completion of the installation a SIP account was created using the Asterisk PBX. This was done by editing sip.conf to adda sip.zoiper username and other configuration options then reloaded. From the literature review it was concluded that SIP be the protocol implemented in the virtual tutorial environment. Extensions for account dialling between was added to the extensions.conf file. A new SIP account is created and registered through the options tab of the zoiper GUI.

Applying a VLAN

The Virtual LAN as mentioned provides Isolation of packet transfer and increased security with scalability, traffic management and summarisation. A VLAN can be configured on Asterisk by adding a file to /etc/sysconfig/networking/devices. The VLAN needs to have a number assigned, for the purposes of this project the number 10 was chosen. This number selection is an arbitrary choice. A text file is created with numerous configuration lines written, these include; IP address, netmask and VLAN. Asterisk was configured to listen to the VLAN only in the sip.conf file. Only when users are added to the VLAN can they send SIP packets.

Figure 2: Virtual Tutorial Environment Interfaces

Firewall Configuration (iptables and CentOS)

The first rule to setup is allowing SSH as an incoming connection. With SSH allowed remote shell connection is can take place, this is set by applying rules on TCP port 22. With IP table rules the destination port is the host where the connection is set. HTTP and HTTPS incoming connection is allowed by applying rules on ports 80 and 443 respectively. It is important to enable incoming data connection for traffic that the host establishes considering the use of VNC. TCP is set to established, related and accept. UDP traffic was set to allowed as was the ICMP protocol which can be used for testing purposes such as PING. Other traffic was set to be dropped that did not meet the previous rules. All outgoing traffic was allowed, then the IP tables was saved.

QoS and Packet Filtering

Having defined QoS metrics for analysis the VoIP network performance must be optimised. Firstly packet loss which can materialise during a call needs to be measured. Packet loss which is measured as the percentage of the packets which are undelivered needs to understood. With the Qos implemented some packets are intentionally discarded for example by jitter buffers. There is also unintentional loss where packets have options set within the IP header such as the Time To Live (TTL) parameter. Packet loss can be calculated by checking sequence figures which are defined in the IP packet header. These can be analysed and compared using a sample selection of sent and received packets. By using a rule with the WireShnork plug-in for Wireshark packet filtering results can be logged to a text file. The CSeq number is used in SIP headers

As UDP does not support encryption, there for SIP messages cannot offer security functions. Also UDP packets are more susceptible to spoofing as the connection state does not require a maintained state. UDP is also a protocol where packet loss or delay is not taken into consideration at the transport layer. The application layer is responsible for such imperatives, leaving the application at risk for network over utilisation. Clearly there are arguments for implementing TCP or TLS rather than SIP dues to the security offered. However SIP and UDP have been selected for this project based on research of performance, overhead and because of a segregated network environment which negates susceptibility to external threats. From the literature review it was concluded that for quality the G.711 (ulaw or alaw) audio codec would provide the best theoretical MOS result. The sip table from Asterisk had to be updated to make the code available, it was then set as a higher priority than other codec's. Essentially the G.711 codec would be used in the first instance.

Creating VM Clones

With the Virtual Tutorial Environment created the host VM needs to be cloned to provide a network topology with endpoints. A clone can be created quite simply by copying the VMware virtual machine files. Cloning can also provide another benefit, a ready to use backup which provides reliability. Cloning saves time in not having to redo the installation and configuration for each implementation. Although the cloning process is simple there are some considerations and consequences. A cloned machine will have the same IP and MAC address which can result in loss of network access. Additionally traffic intended for one clone could be intercepted by the other. The computer name would also be identical creating further conflicts. Each clone needs to be accessed remotely which means that they have to have separate computer names, IP addresses and MAC addresses.

The Tutorial Material

Deciding on which parts of the Asterisk installation and configuration should be covered in this tutorial required some investigation. The areas chosen were based on a number of factors; the minimum configuration needed for a working connection between end device (softphones), providing an overview of how Asterisk functions as a PBX, the file system used within Asterisk and providing an engaging learning experience. The following sections look at these choices in more detail.

The asterisk.conf configuration file allows users to tweak various settings that can affect how Asterisk runs as a whole. Here the user is introduced to the concepts and content of the asterisk.conf file. is a configuration file where the locations of different asterisk components are configured global runtime options. The user is introduced to this configuration file in order to develop an understanding of the asterisk architecture. The options table is where the core of configuration options can be viewed, whilst not directly related to the tutorial having an understanding of this file will help the user understand how asterisk works.

The dial plan is the heart of an Asterisk system, the user is shown how to set up extension numbers, playback, hang-up and testing the newly registered devices. Without a dial plan it is impossible for any end devices such as soft phones to communicate with each other. As this tutorial makes use of soft phones it is imperative that the user can configure and implement a basic dial plan.

The Asterisk command line interface provides various levels of output to let the user know what is happening on the system. The user is introduced to operating the CLI as well as basic commands which can be implemented here. The command line interface is used for configuring Asterisk there for explaining to the user some of the syntax needed to use the CLI as well as being able to implement commands is fundamental in the learning experience.

The file defines the parameters for the various sounds that a telephone system might be expected to produce set for example music may change dependant ion the country. The commands to change these settings are described in the tutorial. Whilst not an essential or core element in Asterisk or indeed any VoIP implementation, the process of configuration is practice for the user in using the configuration files. The process is quite complex and requires the installation of additional modules and updates. Files need to be converted to a format Asterisk understands. Some of these commands encompass the Linux architecture which may be advantageous to users not familiar with Unix or Linux based applications.

The Asterisk flexible voicemail system named Comedian Mail is configured in this exercise. The structure of the Voicemail command is explained as well as the various features available. Security, priority’s, voicemail retrieval and many other options are defined and explained here. Voicemail is a key part of a modern PBX, with both mobile phones and phones connected to the POTS offer voicemail as standard it is expected that every VoIP implantation support this. Here the arguments for specifying voicemail options are explained and implemented.

Session Initiation Protocol (SIP) file is configured in this exercise, the dialling to SIP devices verifies connectivity with softphone devices. As mentioned in section 3, SIP is used for connectivity between end devices. Without SIP or another VoIP communication protocol it is not possible to have a working PBX. SIP is the most popular protocol for VoIP and exploring the fundamentals of how the protocol initiates connections within Asterisk can be seen as essential. This is done via the sip.conf configuration file.

Packet management products such as yum and RPM are discussed, these are useful for downloading additional add-on feature to the base asterisk system. Of course this can be seen as non essential in terms of functionality but it is good practice as a VoIP administrator to update the base system whenever necessary. The updates and installations are used for add on modules to converts music files which are used for the music on hold. It is quite a tricky but rewarding exercise which should be engaging whilst teaching the user.

Testing

Testing involved the isolation of specific variables which make up the Virtual tutorial environment. These tests were aimed at a complete evaluation of network performance, functionality and ability to meet the project aims and objectives. Each component of the network contributed to the environment on the whole, with subjective controls and configurations impacting on functional specifications. The finished environment included a wide variety of variables with bespoke modifications and configurations. The choices made in terms of technology and implementation were made by informed research, however theory at practical implementation often present discrepancies. The intermittent changes in network environments, network parameters and data collection leads to many unknowns. Each of the programs and applications which were used to make up the environment have to be evaluated and tested to analyse functionality and the ability to meet the objectives. Clearly it is not possible to compare the choices made within this project to alternative options which makes it apparent that evaluation and testing must be performed in a more general sense. Ideally an implementation like this would require months of rigorous testing using a wide variety of tools and methods, the complexity of such a network demands such. However testing the environment in more general terms should supply efficient information which could theoretically be built upon in the future.

VNC connectivity / Log-in

The tutorial environment required users to use and implement VoIP practices, a client server distribution was selected for access. VNC was configured so that users could remotely log into the virtual machines which hosted the environment from any location with appropriate network access. Users of the environment would simply need a VNC client installed on their computer to provide access. As seen in the implementation stage VNC was configured so that it could be used with the virtual machines. For testing purposes three separate connections were made to the virtual machines using computers on different logical networks. After VNC client was installed on the machine the connection was made using the network information from VMware player. Once logged in form each machine a few basic task were performed to evaluate the performance and network connectivity. The first task was to launch the Asterisk program and to log into the system as 'root'. Then network connectivity was checked by pinging an external host form the command line interface. For all three machine the performance was good. There was no problems with lag or applications. Network connectivity was also established as the ping packets were sent successful to their destination. It was noticed that when logged into a virtual machine it was not possible to suspend or resume. Much of the functionality described in the literature review described how advantageous it was to be able to pause and continue with VMs. This functionality was not available on any of the connections made. After trying various troubleshooting and configuration options within VNC and VMware it was discovered that when using VNC to connect to a virtual machine the power off, suspend and resume functions are not available. Clearly using VNC is not perfect in terms of providing the access to a client server distribution with VMware. Although there was good performance and network access one of the reasons VMware was selected as a platform was the functionality described above.

VLAN Connectivity

As mentioned a VLAN was selected to use with the virtual tutorial environment. VLAN connection was established by configuring the Asterisk PBX software and also the Zoiper softphone. When logged into one of the virtual machines Asterisk was used to verify VLAN configuration at the command line. Both the VLAN and the interface was checked to make sure that the configuration had been successful. When performing network checks there was an issue with communication between machines. To verify connectivity between the machines the "ping" network command was run from each virtual machine via the terminal application. The ping defaults for Linux machines is to send continual IMCP packets to the other machine. It was decided to change this to four ICMP packets. Each packet was being dropped somewhere within the network. After analysing the network connections and configurations it was discovered that one of the machines had been added to VLAN 1 instead of VLAN 10 which had been selected for implementation. Once this had been resolved network connectivity was successful. A basic network trace on each machine can verify network interface reliability and show traffic information on the network interfaces. Additionally the network topology can be ascertained by looking at the IP addresses and Mac addresses contained within the network scans. This information can help build a logical view of the network infrastructure.

VoIP Call Detection and Analysis

With Wireshark it is possible to look at the RTP packets and SIP packets traversing the virtualised network. When a call is initiated using the Zoiper softphones with Asterisk packet capturing rules set within wireshark can analyse the network interface. As mentioned it is the UDP, SIP and RTP packets which verify an existing communication between end devices. The first rule to setup will specifically capture the UDP and SIP packets. The command is as follows: /usr/sbin/tcpdump -n -i eth0 -w /tmp/wireshark.pcap -s2000 udp port 5060. The -w flag allows for only raw packets to be captured. Port 5060 is used by SIP so the SIP packets will be captured. This created a .pcap file with tcpdump, this can then be opened with wireshark. Before opening the .pcap another command is issued to capture the RTP data by removing the port specification from the previous command.

Figure 3: Wireshark Packet Capture

Wireshark has a VoIP call option in statistics where the it is possible to view the protocol packet communication. There is a graph option which shows VoIP calls during the capture run, it gives a visual presentation of how in this case SIP messages communicate.

Figure 4: Wireshark RTP Audio Capture

The voice calls can be listed to using the "player" option which reruns the audio from the VoIP communication. This is useful for a practical perspective as it gives assurance to the communication taking place. Furthermore this recording can be used to implement QoS testing by listening for any noticeable discrepancies such as delay or interference. This option can be used to listen to the call from both ends, this is very important as if there had been any problems isolation of which end or both ends could have taken place. Also on the statistics menu is an option to view the RTP data, it can be used to analyse every single RTP packet captured during the conversation. The RTP data can be viewed in both directions and statistics are given, these include; Total RTP packets, Lost Packets, Sequence errors and Max delta. These statistics are an excellent metric for analysing QoS considerations.

Table 3: RTP Packet Statistics

Call Number

Total RTP packets

Expected Packets

Lost Packets

Sequence errors

Max delta

1

806

806

0

0

.43372

2

922

922

0

0

.44217

3

765

765

0

0

.41109

As the G.711 A-law and G.711 mu-law codec has been specified for use it is possible to save the RTP audio content. This data can be copied straight from Wireshark to an Au file using the save payload option.

The bandwidth usage, jitter and delay of the RTP stream can be analysed along with packet loss and sequencing errors. The graph option is useful in analysing differences in the packets during a conversation.

RFC3550 defines the calculation of jitter within wireshark; the following extract is taken directly from the RFC document:

Wireshark calculates jitter according to (RFC3550, ietf.org)

If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as

D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)

The interarrival jitter SHOULD be calculated continuously as each data packet i is received from source SSRC_n, using this difference D for that packet and the previous packet i-1 in order of arrival (not necessarily in sequence), according to the formula

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

This formula can be used to understand the RTP packets captured during a sample conversation through the virtualised network. The captured packets show how to apply these to the formula;

R0 = frame 225: frame.time = April 4, 2013 13:22:18.428237000

S0 = frame 225: rtp.timestamp = 1120

R1 = frame 226: frame.time = April 4, 2013 13:22:18.538813000

S1 = frame 226: rtp.timestamp = 1280

R2 = frame 227: frame.time = April 4, 2013 13:22:18.511729000

S2 = frame 227: rtp.timestamp = 1440

The clock rate can be calculated by 1/8000 as g.711 (u-law & Alaw) uses 8bit pulse code modulation equalling 0.8GHz at 0.000125 seconds. Using this data the jitter can be calculated, For frame 225 J(0) = 0/. Frame 226 D(0,1) = (R1 - R0) - (S1 - S0) = [in seconds] (.538813000 sec - . 428237000 sec) - (1280 * 0.000125 sec - 1120 * 0.000125 sec) = 0.02. J(1) = J(0) + (|D(0,1)| - J(0))/16 = [in seconds] 0 + (0.02 - 0)/16 = 0.00125. Frame 227 uses D(1,2) = (R2) R1) - (S2 - S1) which has a result of = [in seconds] (.511729000 sec - . 53881300 sec) - (1440 * 0.000125 sec - 1280 * 0.000125 sec) = -0.02.

From the literature review it was concluded that the MOS for the g.711 codec could be as high as

Compatibility with Modest PC Specification

As mentioned there were test performed by connecting to the VoIP network using computers form differ networks. These were all separate machines with unique specifications and configurations. The Virtual Tutorial Environment was built and run using a high end PC. To check that computers which have specifications which closely reflect and average implementation was important. By checking the performance monitor for each machine it was possible to evaluate the computers performance whilst using the Virtual Environment. As the entire environment was being hosted the only real consideration was the VNC client. The performance counters with the performance monitor on each machine used to connect through VNC showed that performance was very good.

Compatibility Between Software Applications/Protocols

The users of the Tutorial environment had to complete a list of task which involved configuring and administering the VoIP network. It was important to test these steps by performing them on the tutorial environment first. As the steps involved using Asterisk and the softphones as well as the CentOS operating system each component could be checked.

Provisions for VoIP Encryption / Security

Implementing a VLAN is not a method for applying security to a VoIP network. Applying a VLAN does however allows for easier administration especially if the environment were to grow and incorporate more users and virtual machines. This network segmentation does make it simpler to employ security measures but it is important to realise that a VLAN alone is not a way of securing a network. Security of VoIP network relies on continued support of the infrastructure as external threats would target the devices which are running VoIP services. Many of the common targets include TFTP server, DHCP servers, DNS servers and VPN gateways. A firewall was implemented suing IP tables form asterisk, this was set for tight access control where only the bare minimum of connections were enabled. Firewalls can provide excellent protection against malicious attacks and unauthorised access attempts. The firewall can mitigate these threats however it is important to test the firewall before deployment. Whilst performing extensive penetration testing is beyond the scope of this project it is still important to check for any security flaws. fast-track metasploit (darknet.org.uk) is a program developed to exploit vulnerabilities in systems. The program works by sending various packets at the IP address of the device being tested. Fast-track is specifically designed to be used with virtual machines as the packets sent to the host are malicious and can cause real harm. As mentioned earlier VMware virtual machines cannot spread viruses to the host operating system which means that testing in this manor is safe. Before using Fast-track for penetration testing another clone of the original VM was made. This was used as a test environment. First the "Windows Shell Revers_TCP command was executed from the fast-track command line. The IP address for the cloned device (which had been changed from the original) was entered. The command searched for any open ports on the host machine which returned one open port. This was the VNC port specified earlier as 5900. VNC does not support encrypted passwords which does lead to a security concern. Using a dictionary attack (brute force) the password could eventually be found. Using metasploit command line the VNC port was connected to by entering the password selected earlier. This was done to emulate what would happen if the password was found and a connection was made. Once connected to the port it would have been possible to execute malicious activity such as DLL injection and at the same time bypassing all of the firewall rules applied earlier.

Monitoring Virtual Machine Performance

VMware Player has performance counters which use Microsoft performance consoles to analyse and collate data which is running on virtual machines. It is not possible to analyse the performance of virtual machine on a Linux host but it is however possible to analyse the performance on a Windows host. The data which can be analysed is the reading and writing to virtual disks, the memory usage of the VMs and the virtualised network traffic. The virtual machines need to be running to analyse performance metrics, the analysis is purely of the virtual machines and not the host. Upon analysis of one of the virtual machines it was noted that there was a fairly high process use. This was not really a problem as the host PC was a high spec machine with a large amount of RAM and fast processor. However it was a best practice scenario to adjust some of the VMware settings to make the application run more effectively. Efficiency is one of the main aspect to consider in a virtualised environment as the carbon footprint is an important topic in today's climate. Windows visual effects was disabled and the CDROM was disabled. There was a slight improvement in terms of process utilisation.