1/6
Paper Reference Number: WCEEENG_A00_000
The effect of machine virtualization on the environmental impact of
desktop environments
Dr. Mahmoud Abaza1, Daryl Allenby1,2
1
Athabasca University, 2 The Northern Alberta Institute of Technology (NAIT), Canada
II. REQUIREMENTS ANALYSIS
T
Abstract-This paper evaluates two important and recently
prominent ideas in computing science in terms of their
combined potential to provide responsive and
environmentally responsible alternatives to traditional
desktop computing deployments. The ideas of
virtualization and green computing are combined to
develop a production model for virtual desktop
environments. This virtual model is then studied to
determine possible concurrencies when varying desktop
operating system and secondary storage input/output
performance variables. The potential for concurrency in
the production model is based on the use of modern
equipment, hypervisor processing hosts, Virtual Machines
(VMs) and thin clients as end user devices. The virtual
model, as a final presentation, is then compared to equal
numbers of traditionally deployed desktop computers.
Keywords – Virtual Machines, green computing,
hypervisor, environment friendly.
I. INTRODUCTION
The model being studied is comprised of VMs hosted on
servers running VMware’s ESX Server version 3.5 and thin
clients. We refer to this coupling of VM and thin client as
Virtual Desktop Infrastructure (VDI). The research will
determine the number of VMs that can be supported by a
given amount of processing power as it varies by Operating
System (OS) and secondary storage.
The limit of
concurrency will be equal to the maximum useable number of
VMs as determined by each variable pair. Each VM will
employ a reasonable analogue of actual user activity achieved
by scripted programmatic tasks performed in the VM.
This VDI model is then be evaluated as to its potential to
achieve a higher degree of efficiency in terms of power,
cooling and ultimately CO2 produced when compared to an
identical number of traditionally deployed machines. The
results of the evaluation can be interpreted in terms of net
reduction in the total cost of energy needed to supply both
solutions for a period of years. The total cost of energy is
determined by the pounds of CO2 contributed by each
solution.
VM host OS and secondary storage are expected to be
important variables because they are likely to become
bottlenecks sooner than other components of the system [1],
[2]. Varying OS type under the included selections will
expose efficiencies in software architecture. Varying
secondary storage presentations under the included selections
will show how decreasingly available Input/Output
Operations per Second (IOpS) affects the upper limit of
concurrency. Secondary storage or Logical Unit Number
(LUN) types and OS types chosen have been done so to
reflect likely choices that organizations are apt to make if
implementing a VDI based solution [8].
III. BENCHMARKING AND DATA COLLECTION
The purpose of benchmarking will be to determine
empirically that the limit of concurrency under each variable
has been reached. The study will simulate user activity on
each VM. The simulations are achieved by a series of host
shell scripts written that incorporate several typical user
activates. For example each shell script opens a word
processing document, an email client, a spread sheet, copy a
large file, delete a large file, open and close several different
web sites that are specifically chosen for their dynamic
content and displayed media types, play a video and
open/close a PDF document. Each activity is punctuated by
an appropriate intervening time delay. The entire sequence
runs for approximately twenty minutes and loop infinitely.
Between the Microsoft operating systems the identical shell
scripts, source files and productivity software can be studied.
The Ubuntu desktop VMs will be unique in both shell script
implementation, productivity software, and will have some
differences in source file types. The shell scripts are designed
to produce an acceptable randomness of hypervisor resource
consumption as realized as an average over time.
After the template VMs are created, n additional VMs will
be spawned from their templates, the processing, memory
access and I/O read write patterns of the group will become
randomized as their preconfigured shell scripts: start, close,
launch and use applications. This will negate most of the
benefit realized by caching that the processing host uses at the
processor, memory and storage controller.
The 2009 World Congress on Electronics and Electrical Engineering, WCEEENG'09
April 6-9, 2009, Cairo, Egypt
2/6
Paper Reference Number: WCEEENG_A00_000
IV. THE CONCURRENT LIMIT
When adding additional VMs to determine the concurrent
limit for each pair of variables; that limit will be met when
one of two things happens after the addition of an active VM
to the hypervisor:
1. A critical hypervisor resource reaches (as a percentage
averaged over one hour) 75 percent, in scope resources
include CPU cycles (in MHz), memory (in KB), network
throughput (in KBps) and disk IOpS (in KBps) ;
2. The user experience in VM n + 1 (assessed qualitatively)
becomes unacceptable in terms of responsiveness.
The goal in stopping at 75 percent average utilization is to
allow for unexpected user activity in production, as a useable
production model is an important outcome of the study. At
100 percent utilization of any one resource more VM
concurrence would be possible, but the user experience would
be poor and not a realistic implementation. A good
production model will allow for a reasonable and achievable
statement of concurrency. Succinctly that; a given server
configuration produces x number of VMs; this plus thin
clients equal to concurrent running VMs requires x amount of
kWh and produces n BTUs. Compare that to an equal number
of standard desktops requiring x’ kWh and producing n’
BTUs.
The second condition represents a safeguard; if for
example, after adding one more VM to the server
configuration, the response time in terms of general usability
is unacceptable; then concurrency will be considered to be
that number less one. This would be true even if the critical
hypervisor resources were all within the 75 percent limit. This
condition covers any influencing variables that are difficult or
impossible to quantify. One of the expected unquantifiable
variables that might be encountered is that of instantaneous
latency. Latency, in this context, is the momentary delay in
the delivery of data, over a bus or network, which is not
reflected well in measures of throughput or, in our case,
IOpS. This latency may affect VM performance in ways that
would otherwise be difficult to measure or predict, but still
manifest as a user experience that is unacceptable.
The qualitative evaluation will be simple; if the first item in
the user simulating shell script does not launch instantly, the
experiment enters a caution phase. If, after a delay of five
minutes, the same delay is observed, the concurrency limit
will be considered met. If, after the delay, the observation is
not repeated, it will exit the caution phase and VM additions
continue normally.
Hypervisor resource utilization data will be collected from
the ESX management interface regarding processor, memory
and I/O requirements of each VM and the total committed by
the hypervisor.
V. POWER CONSUMPTION MONITORING
Once the limit of concurrency has been determined under
each variable pair, measurement of amps drawn at
concurrency will be measured by inline electrical meters. All
equipment involved in the study will be connected to
instrumented circuits.
The thin client and its LCD panel power usage will be
determined, while in active use, under a RDP session to one
of the VMs. This number will be multiplied by the concurrent
maximum determined at the hypervisor and added to the total
energy consumed by the virtual model.
To determine the energy used by the equivalent traditional
deployment of desktop computers, the same operating
systems, applications, source files and shell scripts will be
used, as was done in the VMs. All three operating systems
will be tested on a single desktop configuration, and the
energy consumed each time will be multiplied by the
concurrent maximum determined at the hypervisor.
VI. CALCULATIONS AND FORMULA
After finding the sum in watts for each model, the
determination of net kilograms CO2 can be made, and those
calculations extrapolated in years to determine the total cost
of energy for each. During calculations the following
assumptions will be used:
1. There is 0.613 kilograms of CO2 in every kWh [3]. This
figure is based on the average across all forms of
generation according to the source;
2. Each kWh used produces 3,412 BTU of heat [5];
3. The instruments measuring amps at the circuit breaker
have a manufacture’s stated accuracy of ±0.0375 amps.
The results of calculations will therefore have an
uncertainty of at least ±0.0375 and possibly more if the
results of multiple circuits are added. In no case, will the
results of more than five circuits be combined so we can
confidently state an uncertainty in measurement of
±.1875 watts for all experiments.
The primary formulas used to determine net pounds of CO 2
are described below and flow from one to another in
descending order:
1. kWh × cost in CO2 per kWh = kilograms of CO2
contributed by processing;
2. Kilograms of CO2 contributed by processing + kilograms
of CO2 contributes by cooling = net kilograms of CO2.
VII. VDI EXPERIMENTAL RESULTS
Table 2, shows the results of extrapolation and compare
both solutions is terms of carbon measuring a single day’s
operation.
TABLE 2: CARBON COST AFTER EXTRAPOLATION
The 2009 World Congress on Electronics and Electrical Engineering, WCEEENG'09
April 6-9, 2009, Cairo, Egypt
3/6
Paper Reference Number: WCEEENG_A00_000
VDI
Power
(kWh)
Carbon
Cost
(kg)
Desktop
Power
(kWh)
Carbon
Cost
(kg)
Carbon
Delta
Ubuntu
FC-SCSI
1345.99
825.09
1527.59
936.41
-111.32
Ubuntu
FATA
1272.60
780.10
1527.59
936.41
-156.31
Ubuntu
iSCSI
1316.25
806.86
1527.59
936.41
-129.55
Ubuntu
NFS
1388.27
851.01
1527.59
936.41
-85.40
Ubuntu
SAS
1287.33
789.14
1527.59
936.41
-147.27
XP SP2
FC-SCSI
1433.50
878.74
1568.71
961.62
-82.88
XP SP2
FATA
1376.37
843.71
1568.71
961.62
-117.90
XP SP2
iSCSI
1405.07
861.31
1568.71
961.62
-100.31
XP SP2
NFS
1445.10
885.85
1568.71
961.62
-75.77
XP SP2
SAS
1380.70
846.37
1568.71
961.62
-115.25
Vista
SP1 FCSCSI
1587.13
972.91
1631.69
1000.23
-27.31
Vista
SP1
FATA
1476.60
905.16
1631.69
1000.23
-95.07
Vista
SP1
iSCSI
1540.88
944.56
1631.69
1000.23
-55.66
Vista
SP1 NFS
1554.43
952.87
1631.69
1000.23
-47.36
Vista
SP1 SAS
1489.33
912.96
1631.69
1000.23
-87.26
In looking closely at our data we can make some general
conclusions and recommendations:
1. VDI must be scaled up to hundreds of VMs before it
starts to have an environmental advantage over standard
desktop deployments;
2. Once properly scaled up, VDI, in all the forms tested, is a
more environmentally friendly solution than standard
desktop deployments by an average of 9.98 percent or
95.64 kilograms of CO2 saved for every day, for a
deployment of approximately 750 stations. This number
becomes even more impressive when extended to the
year over year saving at 34,908.60 kilograms of CO 2
saved ;
3. FATA based VMs are the top environmental performers,
regardless of installed VM OS, by an average of 12.82
percent or 123.09 kilograms of CO 2 saved every day for a
deployment of approximately 750 stations. Once again,
this number is more impressive when extended year over
year at 44,927.85 kilograms of CO2 saved;
4. Choice of operating system does make a difference; we
see that Ubuntu scores the best, with XP SP2 needing on
average 18.18 percent more resources to match the same
number of VMs and Vista SP1 needing on average 41.78
percent more resources to reach an equal number.
We include a delta column where positive values (if
present) indicate a solution that is more costly to the
environment. Values near zero show that the solutions are
competitive and, finally, negative numbers indicated solutions
that are less costly to the environment. We now have all the
information we need to make some conclusive statements
about VDI’s performance in terms of greenness.
Acknowledgment
VIII. CONCLUSIONS AND RECOMMENDATIONS
Figure 2, shows summary results in terms of carbon
performance, sorted by the delta between VDI and traditional
desktops after one year of operation.
This work was supported by NAIT in the provision of all
computing and instrumentation equipment necessary to
perform the experiments and collect data.
For additional information or questions on the study please
contact Daryl Allenby by email at daryl.allenby@gmail.com.
FIGURE 2: SUMMARY PERFORMANCE IN CARBON SORTED BY
DELTA
References
[1] Ahmad, Irfan, et al. 2003. An Analysis of Disk Performance
in VMware ESX Server Virtual Machines. VMware
Corporation Web Site. [Online] October 27, 2003. [Cited:
February 8, 2008.]
http://www.vmware.com/pdf/wwc_performance.pdf.
The 2009 World Congress on Electronics and Electrical Engineering, WCEEENG'09
April 6-9, 2009, Cairo, Egypt
Paper Reference Number: WCEEENG_A00_000
[2] Buytaert, Kris, et al. 2007. Best Damn Server Virtualization
Book Period. Burlington : Syngress Publishing, Inc., 2007.
[3] Energy, Department of and Agency, Environmental
Protection. 1999. Carbon Dioxide Emissions from the
Generation of Electric Power in the United States.
Environmental Protection Agency. [Online] October 15,
1999. [Cited: January 30, 2008.]
http://yosemite.epa.gov/oar/globalwarming.nsf/UniqueKey
Lookup/SHSU5BPL2K/$File/co2emiss99.pdf.
[4] Energy, U.S. Department of. 2007. Electric Power Annual .
Energy Information Administration. [Online] October 22,
2007. [Cited: July 6 , 2008.]
http://www.eia.doe.gov/cneaf/electricity/epa/epa.pdf.
[5] Larabie, Chuck. 2003. Power and storage: the hidden cost of
ownership - Storage Management. Business Technology
Network. [Online] October 2003. [Cited: February 18,
2008.]
The 2009 World Congress on Electronics and Electrical Engineering, WCEEENG'09
April 6-9, 2009, Cairo, Egypt
4/6