journal of cloud computing - advances, systems and...

http://www.diva-portal.org

This is the published version of a paper published in Journal of Cloud Computing - Advances, Systemsand Applications.

Citation for the original published paper (version of record):

Armstrong, D., Espling, D., Tordsson, J., Djemame, K., Elmroth, E. (2015)

Contextualization: dynamic configuration of virtual machines.

Journal of Cloud Computing - Advances, Systems and Applications, 4(17): 1-15

http://dx.doi.org/10.1186/s13677-015-0042-8

Access to the published version may require subscription.

N.B. When citing this work, cite the original published paper.

Permanent link to this version:http://urn.kb.se/resolve?urn=urn:nbn:se:umu:diva-112462

Armstrong et al. Journal of Cloud Computing: Advances, Systemsand Applications (2015) 4:17 DOI 10.1186/s13677-015-0042-8

RESEARCH Open Access

Contextualization: dynamic configurationof virtual machinesDjango Armstrong1*†, Daniel Espling2†, Johan Tordsson2, Karim Djemame1 and Erik Elmroth2

Abstract

New VM instances are created from static templates that contain the basic configuration of the VM to achieveelasticity with regards to capacity. Instance specific settings can be injected into the VM during the deployment phasethrough means of contextualization. So far this is limited to a single data source and data remains static throughoutthe lifecycle of the VM.We present a layered approach to contextualization that supports different classes of contextualization data availablefrom several sources. The settings are made available to the VM through virtual devices. Inside each VM data fromdifferent classes are layered on top of each other to create a unified file hierarchy.Context data can be modified during runtime by updating the contents of the virtual devices, making our approachthe first contextualization approach to natively support recontextualization. Recontextualization enables runtimereconfiguration of an executing service and can act as a trigger and key enabler of self-* techniques. This triggerprovides a service with a mechanism to adapt or optimize itself in response to a changing environment. The runtimereconfiguration using recontextualization and its potential gains are illustrated in an example with a distributed filesystem, demonstrating the feasibility of our approach.

Keywords: Cloud Computing; Contextualization; Recontextualization; Configuration; Virtual machine

IntroductionOne of the key characteristics of cloud computing is rapidelasticity [1]; the ability to quickly provision or releaseresources assigned to a cloud service in order to respondto current demand. In the Infrastructure as a Service(IaaS) model, cloud services are normally comprised of aset of different components, each defined using a VirtualMachine (VM) template. To achieve elasticity, the capac-ity of a cloud service can be adapted during runtime byadjusting the number of running VM instances of eachtemplate. This makes it possible to scale each part of theservice independently.Each VM instance started from a template needs to be

customized with some unique settings, e.g., networkingconfiguration to ensure each instance is assigned a uniqueIP-address. The settings need to be applied dynamically,normally done as part of the VM boot process. This

*Correspondence: [email protected]†Equal Contributors1School of Computing, Faculty of Engineering, University of Leeds, LS2 9JTLeeds, UKFull list of author information is available at the end of the article

boot-time customization process is called contextualiza-tion [2, 3].Several different usage scenarios that join isolated cloud

infrastructures together into a larger unified infrastruc-ture are being considered [4, 5]. Conceptually, a virtualmarket of cloud resources not limited by technologicalboundaries would offer diversity in terms of (but notlimited to) pricing, availability, and a choice of differentgeographical locations to use for hosting. Cloud infras-tructures commonly offer supporting services such asnetwork based storage, and today’s major infrastructureproviders (IPs) such as Amazon wrap the infrastructurespecific functionality into pre-configured VM templates.In a multi-cloud scenario the VM templates need to begeneric enough to be deployed across a wide range ofinfrastructures. Therefore, the contextualization stage isneeded to support interactions with any infrastructure-specific services or settings.VMs can be migrated between physical hosts with-

out being restarted using live-migration. This enables anIP to re-distribute the current VM load across availableserver resources during runtime. Because the VM is not

© 2015 Armstrong et al. This is an Open Access article distributed under the terms of the Creative Commons Attribution License(http://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproduction in any medium,provided the original work is properly credited.

http://crossmark.crossref.org/dialog/?doi=10.1186/s13677-015-0042-8-x&domain=pdf

mailto: [email protected]

http://creativecommons.org/licenses/by/4.0

Armstrong et al. Journal of Cloud Computing: Advances, Systems and Applications (2015) 4:17 Page 2 of 15

restarted during the migration, the contextualization pro-cedure is not triggered post-migration. Therefore, anyVM customization (such as loading infrastructure specificsettings) will remain unchanged.In our earlier work [6] we present and define recontex-

tualization, an emerging technology to allow contextualdata inside running VMs to be updated during runtime.This work extends on earlier work on recontextualiza-tion and contextualization [3] and presents a novel layeredbased approach to contextualization. In this approach,multiple independent sets of contextual data are mergedinto a unified structure realized by a custom file systemwhose data sets can be dynamically added or removedduring runtime. This paper presents the requirements,design, and evaluation of a system that support this multi-layered approach to contextualization, which is the firstcontextualization solution to natively support recontextu-alization. It is worth noting that the research presented inthis paper uses a scientific methodology based on func-tional prototyping and system performance analysis. Wedo not use mathematical modelling. Additionally and forclarity’s sake, the results of this research aims to facili-tate and enhance current cloud provider interoperabilitybeyond the state of the art but we do not claim to solve allproblems of VM or IaaS interoperability.The rest of this article is organized as follows; In

Section ‘Background and related work’ the background oftopics related to the field of contextualization and recon-textualization are presented. Section ‘Contextualization’presents an overview of contextualization including chal-lenges and a summary of our earlier work on thesubject. The corresponding information for recontex-tualization is presented in Section ‘Recontextualization’.Section ‘Context-aware lifecycle management’ showshow the two techniques are used in conjunction toprovide adaptable usage throughout the lifecycle ofa service. The unified approach is demonstrated andevaluated in Section ‘Functional evaluation’. Finally, con-clusions and future work are presented in Section‘Conclusions and future work’.

Background and related workThis section of the paper introduces the topics of Vir-tualization, Service Lifecycle, Configuration Managementand Autonomic Computing in relation to our research.Additionally, the differences between configuration man-agement, contextualization and recontextulization, areexplicitly defined using the life-cycle of a cloud applicationin Section ‘Service lifecycle’.

VirtualizationHardware virtualization techniques [7, 8] provide meansof dynamically segmenting the physical hardware intosmaller virtual compartments. This makes it possible to

run several different VMs in parallel on the same phys-ical hardware. Each VM is a self-contained unit, includ-ing operating system and (virtual) hardware drivers. Thephysical resources are subdivided, managed, and madeavailable to the executing VMs through a Hypervisor.Virtualization is the underlying abstraction technol-

ogy for most IaaS clouds. VMs create natural barriersbetween multiple tenants and offer an environment prac-tically indistinguishable from running on dedicated phys-ical hardware. One of the major benefits of virtualizationis that it enables some of the fundamental assumptionsof physical hardware hosting to be relaxed, which createsnew interesting research areas. For example, the hardwareconfiguration of a VM can dynamically change duringruntime as the number of CPUs or the amount of RAMmemory assigned is adjusted by the hypervisor [9, 10].These events have no correspondance when running onphysical hardware, as the hardware setup is assumed toremain constant from boot-time throughout the uptimeof the server. The lifecycle of a VM therefore is morecomplicated in comparison to a regular server.Another interesting property of virtualization is that

VMs can be relocated (migrated) during runtime from onephysical host to another. This opens up a wide range ofmanagement possibilities from the infrastructure side, asthe mapping between physical and virtual resources canchange dynamically in response to demand and availabil-ity. From the perspective of the system running insidethe VM, migration is not noticeable (apart from a slightpause as control over the VM is finally passed on from thesource to the target hypervisor). Migrations may thereforeinvalidate decisions made during initialization. Such deci-sions may include algorithmic decisions based on nearest-neighbour or geographical hosting location, where thealgorithms assume that the location of the service remainsunchanged throughout the uptime of the system. Howthe layered contextualization approach presented in thiswork can be used to mitigate the effects of migration isdiscussed and described in Section ‘Functional evaluation’.

Service lifecycleThe lifecycle of a cloud service is related to the lifecycleof the underlying VM templates, rather than to the life-cycle of individual VM instances. The VM templates anda service manifest [11] are created during the Definitionphase. The service manifest contains all necessary metadata required to tie the individual VM templates togetherinto a unified service. This includes rules, initial values,and lower and upper bounds for automated scaling of VMinstances. When the service is submitted for executionto a cloud IP the service enters the Deployment phase.During deployment, the initial number of VM instancesare started and assigned to physical resources. The ser-vice executes during the Operations phase, during which


the placement and constitution (size) of the service canchange dynamically.Configuration and contextualization are done during

different parts of the service lifecycle. This is illustratedin Table 1. Configuration takes place during the defini-tion phase of the service and includes all customizationrequired to make the VM templates function as a unifiedservice. Settings specific to the platform to which the ser-vice is deployed are normally not available during the def-inition phase unless the service is designed with a singleplatform in mind. Instead, it is made available to the VMsduring the deployment phase through contextualization.Recontextualization offers means to update customizeddata during the operations phase, enabling migration ofVMs in scenarios where such data is fundamental to theoperations of the service.

Configuration managementThe long lasting deployment of systems such as cloud ser-vices create a need for maintenance and management ofthe application during the operations phase. Such mainte-nance may include, e.g., applying system security updatesacross all associated nodes. For small scale systems thiscan be done manually, but the process is time consum-ing and error-prone. The rapid and automated elasticityof cloud services further limits the feasibility of manualsystem management as instances of VMs may be addedor removed automatically during any period of the day.Configuration management is a well established conceptfor managing distributed systems during runtime, not justspecific to the field of cloud computing. Aiello et al. [12]defines configuration management as:

Definition. Configuration Management. A manage-ment process that focuses on establishing andmaintainingconsistent system performance and functional attributesusing requirements, design, and operational informationthroughout a system’s lifecycle. [12]

Computing oriented configuration management toolssuch as CFEngine, Puppet, or Chef are commonly used inlarge scale hosting on physical platforms. These tools pro-vide a number of benefits including (I) the reproducibil-ity and automation of software configuration across anunlimited number of (virtual) machines, (II) the con-tinuous vigilance over running systems with automated

Table 1 Lifecycle phases of a cloud service

Definition phase Deployment phase Operations phase

Develop Select Provider Monitor/Optimize

Compose Deploy Execute

Configure Contextualize Recontextualize

repairs and alert mechanisms, (III) enhanced control overand rationalisation of large scale deployments, and (IV)the ability to build up a knowledge base to document andtrace the history of a system as it evolves.The CFEngine [13] project provides automated con-

figuration management of large networked systems.CFEngine can be deployed to manage many differenttypes of computer system such as servers, desktops andmobile/embedded devices. The project was started in1993 by Mark Burgess at Oslo University as a way to auto-mate the management of dissimilar Unix workstations.In the work by Burgess the foundations of self-healingsystems were developed and as a precursor heavily influ-enced the ideas of Autonomic Computing developed laterby IBM (see Section ‘Autonomic computing’).Puppet [14] is a configuration management system

originally forked from CFEngine. Puppet provides graph-based and model-driven approaches to configurationmanagement, through a simplified declarative domainspecific language that was designed to be human read-able. The model driven solution enables the configurationof software components as a class, a collection of relatedresources where a resource is a unit of configuration.Resources can be compiled into a catalogue that definesresource dependencies using a directed acyclic graph. Acatalogue can be applied to a given system to configure it.Chef [15] rose out of the Ruby-on-Rails community out

of dissatisfaction with Puppet’s non-deterministic graph-based ordering of resources. In contrast to Puppet, Chefplaces emphasis on starting up services from newly provi-sioned clean systems, where the sequence and executionof configuration tasks is fixed and known by the user.This makes Chef particularly well suited to the paradigmof cloud computing where VM instances are short-livedand new instances are spawned from a newly provisionedbase image. Chef uses the analogy of cooking and creates“recipes” that are bundles of installation steps or scripts tobe executed.Although existing configuration management tools are

well suited to cloud computing they do not resolve allthe issues surrounding configuring an application in andynamic environment. Most notably, these systems oper-ate on the application level for automated managementof runtime reconfigurations for a large number of sys-tem nodes. Contextualization, as described in Section‘Contextualization’, operates on a lower layer of the systemstack. Contextualization offers a multi-purpose mecha-nism for adapting a generically configured VM to a spe-cific and dynamically assigned execution environment.For example, the required settings to connect a bootingVM to a VPN can be supplied by the infrastructure atboot time. Configuration management tools and contex-tualization are complementary techniques for dynamicreconfiguration. Contextualization deals with lower level


IP specifics such as network configuration and platformspecific settings, while configuration management can beused to manage updates at the application level.

Autonomic computingAutonomic computing has been a topic of interest formany years with research starting in 2001 by IBM’s auto-nomic computing initiative [16]. The initiative aimed tocreate a self-managing computing environment, capa-ble of handling increasingly complex systems. Autonomiccomputing has been defined as:

Definition. Autonomic Computing. “Computing sys-tems that can manage themselves given high-level objec-tives from administrators.” [16]

Autonomic computing involves the creation of sys-tems that run diagnostics checks and compensate for anyirregularities that are discovered. Multiple control loopsadjust the system to maintain its state within a numberof specific bounded criteria. The ever growing complex-ity of distributed systems provide motivation for the useof autonomous systems as manual control is expensive,prone to errors and time consuming. Autonomic comput-ing reduces the need for systemmaintenance with aspectssuch as security or software configuration maintained inan unattended fashion. Administrators, instead of con-trolling entire systems by hand, define general rule basedpolicies that guide “self-*” management processes in fourfunctional areas:

• Self-configuration: Automatic configuration ofcomponents during runtime.

• Self-healing: Automatic discovery, and correction offaults during runtime.

• Self-optimization: Automatic monitoring andcontrol of resources to ensure the optimal functionwith respect to the defined requirements.

• Self-protection: Proactive identification andprotection from arbitrary attacks.

Within the context of cloud computing autonomic com-puting can be applied to and reasoned about both at theinfrastructure level and at the service level. At the infras-tructure level, self-management actions primarily withinself-optimization can be used with regards to resourceassignment and control. An example is re-evaluating thecurrent mapping between virtual and physical hardwareto reach higher-level objectives, such as improved applica-tion availability. Work in this area has been done by, e.g.,Dautov et al. [17], Karakostas [18], Fargo et al. [19], Maureret al. [20], Wood et al. [21], and Shrivastava et al. [22].At the service level, autonomic computing approachescan be used to manage the operations of the applications

themselves. This includes triggering self-optimizationroutines to adapt to the current service constitution orself-configuration approaches to adapt to a new executionenvironment. The work presented in this paper focuseson the service-level. We show how the approach can beused as triggers that allow self-configuration and otherself-* processes to react to changes in the service context.This is done by having mechanisms to make dynamicalgenerated and context-aware data available to processesrunning inside the VMs of each service.Athreya et al. [23] investigate the application of self-*

approaches to the Internet of Things (IoT), a vision of hav-ing billions of devices all conneted to the Internet.With somany connected devices, more autonomic managementsystems are required. In their work Athreya et al. presenta number of challenges for self-configurable IoT systems.These challenges include, e.g., addressing and clarifyingthe incentives for self-management (including weighingthe development costs to the potential benefits), and alsodiscuss the great need of having integrated applicationsto fully utilize the advantages granted by a self-* enabledinfrastructures. These challenges clearly applies to ourwork as well, and their work provides a solid ground forfurther discussions.Self-configuration can conceptually be subdivided into

two different subtasks; how to generate the new config-uration data and how to allow the software to transitionfrom using the old data to using the new data. For thiswork we consider the generation of configuration data tobe out of scope, since the specifics of the data is closelyassociated with any given situation.Finally, Windows Azure [24] provides some basic SaaS

level self-configuration functionality through the RoleEn-vironment Class [25]. This makes use of Windows envi-ronment variables but is limited in scope to Microsoft’sproprietary programming languages and the Azure plat-form. This prevents interoperability amongst other IaaSproviders. Our approach strives to enhance this over thecurrent state of the art. Additionally, the RoleEnvironmentapproach does not consider the self-configuration of IaaSand PaaS level software components, which our solutiondoes.

ContextualizationOur research on contextualization of cloud applicationsstarted with an evaluation into the limitations of thecurrent cloud infrastructures. It quickly became appar-ent that, although virtualization brings several key ben-efits and is a critical enabler of cloud computing, italso increases the complexity of managing an applicationdeployed in a cloud.Modern virtualization technologies enable rapid provi-

sioning of VMs and thus allow cloud services to scale upand down on-demand. This elasticity [26, 27] comes with


a new set of challenges for dynamic service configura-tion. The focus of this research is on horizontal elasticitywhere scaling is achieved by adding or removing VMs toa service during its operation. The related case of verti-cal elasticity, i.e. application scaling through VM resizing,is much easier from a contextualization perspective. Forhorizontal elasticity scenarios, predefined yet flexible con-textualization mechanisms enable the manipulation ofVM images during the development of a software service.Previously, this required the complex and time consumingconfiguration of software within base images.For clarity, our definition of contextualization is as

follows:

Definition. Contextualization. The autonomous con-figuration of individual components of an application andsupporting software stack during deployment to a specificenvironment. [3]

In this definition, an environment is considered to bethe specific composition of underlying physical and/orvirtual hardware in addition to any value added servicesprovisioned by an IP.

ChallengesThere are a number of challenges that make the con-textualization of cloud services a non-trivial affair. Inour previous work we argued that contextualization incloud computing is a highly pervasive key technologicalrequirement of any cloud service, where elastic resourcemanagement is critical to the on-demand scalability of aservice [3]. The holistic nature of the services deployedon clouds makes it difficult to provide flexible genericand open tools without limiting the heterogeneity of sup-ported services.We identified three inherent challenges toproviding elasticity through contextualization where VMsare added and removed during service operation.The first challenge to overcome is the complete con-

textualization of cloud services across all classificationswithin the cloud ecosystem: Software as a Service (SaaS),Platform as a Service (PaaS), and Infrastructure as a Ser-vice (IaaS) [1, 28]. These classifications refer to:

• SaaS: web-based applications and services hostedon-line, usually reachable from standard interfacessuch as a web browser.

• PaaS: systems that offer deployment of applicationsdesigned for execution on a specific platform orsoftware environment. For example, the opportunityto upload a Java archive and have it executed onremote resources.

• IaaS: infrastructures that offer the provisioning ofremote resources on which the consumer canexecute arbitrary software as if the resources were

dedicated hardware servers. Virtualization is usuallyused as a layer between the hardware and theconsumer software systems, which makes it possiblefor the consumer to design the software stack fromthe operating system upwards.

In this work, we focus on IaaS contextualization of VMscomprising a cloud service. We touch upon using thesuggested approach to access platform software servicessuch as network based storage or database services thatcould be considered stand-alone PaaS services. In IaaS, thechallenge pertains to low-level contextualization of virtualresources, as found in IPs, where virtual devices requirecontext to enable VMs to be bootstrapped to existingvirtual infrastructures. This approach has been partiallyexplored by RESERVOIR [5].The second challenge to overcome is contextualiza-

tion across multiple IaaS domains for reasons of inter-operability. Many IaaS providers offer platform servicesthat are not interoperable with those of other providers.Also, as contextualization of VMs is performed as partof service development, the service will be customizedto a single provider only. To solve this challenge, weneed to extend contextualization to support run-timerecontextualization.The third challenge pertains to a set of functional

requirements for real world clouds and their impact oncontextualization. Notable among these are end-to-endsecurity through contextualization mechanisms that sup-port a Virtual Private Network (VPN) overlay and soft-ware license management systems. Both of these haveunique contextualization requirements: contextualizationmust be secure with no VPN keys stored unless in use;and contextualization that is able to accommodate licenseprotected software and licensing tokens.In our previous work [6] we discuss the nature of con-

textualization in the light of the OPTIMIS project [4].We present details of the architecture and implementa-tion of our tool for the contextualization of platform levelservices as well as virtual infrastructure. We discuss theimplication of contextualization in clouds, the motivationbehind our work and suggest a landscape for the evolu-tion of contextualization tools across all classes of cloudswithin the ecosystem of the future. We contribute to boththe image and instance level contextualization of VM’s andillustrate the potential effectiveness of our tool through asimple use case.In addition, as part of our previous work on contextu-

alization, a proof of concept contextualization tool wasdeveloped and its performance tested. This prototypewas used to confirm the validity of our contextualisationapproach on a cloud testbed. This provided evidence onthe potential performance of our approach for contextu-alization with regards to preparing generic VM images of


sizes in the range of 1-5 GB in increments of 1 GB andwith varying numbers of concurrent user requests from10-100, for the purpose of creating ISO CD images con-taining 1MB of context data. The results showed adequatescalability and response time over ten iterations of theexperiment with minimal variance.

RecontextualizationRecontextualization can be used to adapt a running ser-vice to any system changes, including making newlymigrated VMs operate properly in the (potentially differ-ent) system environment of a new host. A definition ofrecontextualization is as follows:

Definition. Recontextualization. The autonomousupdating of configuration for individual components of anapplication and supporting software stack during runtimefor the purpose of adapting to a new environment [6].

In this definition, a new environment is considered tobe a change in the underlying physical or virtual hard-ware, for example when a VM ismigrated from one host toanother. In addition, changes in infrastructure or platformlevel services that are in active use by a cloud applicationwould also be considered to be a new environment.An analogy to recontextualization can be made with

printers and printer drivers. Imagine a laptop user movingfrom one physical location to another (i.e. a new envi-ronment) wanting to access a printer at the new location.Instead of manually installing a driver for an associatedprinter and having to configure the driver before the print-ing device is usable, the environment itself could detectthat the laptop has entered the printer domain, and supplythe needed software and settings to the laptop operatingsystem automatically.Using recontextualization, VM instances can be auto-

matically offered settings and context data to adapt toa new execution environment. Without the support ofrecontextualization, adapting the instances to their envi-ronment may require a time-consuming manual processthat limits the flexibility and scalability of the cloud.Whenmigrating VM instances, parts of the virtual infrastructure(e.g., virtual networks, storage areas, databases) may haveto be migrated as well. For example, assume that a cloudservice is running on the resources of an IP and that itemploys a network based storage service offered by thatprovider. When migrating to another IP, there are threemain tasks; migrating the VM itself, relocating the dataon the network based storage service to the correspond-ing service offered by the new IP (to avoid cross-networktransfer costs), and ensuring that the VM is able to com-municate with the new storage system without manualintervention. Recontextualization can be used to achievethe latter of these three.

The key benefits of our approach to recontextualizationare: i) minimal changes to the existing cloud infrastruc-ture, i.e. there is no need to make alterations to thehypervisor and ii) the preservation of security through theselection of a recontextualization mechanism that gatherscontextualization data from a secured source. In addi-tion to these benefits, there are a number of challengesthat must be overcome before recontextualization canreach widespread adoption. These are due in part to alack of IP interoperability and the difficulties in creatingan approach to recontextualization that can be appliedto the wide diversity of applications deployed into cloudcomputing environments.

ChallengesA motivational factor behind the need for runtimerecontextualization stems from VM migration in clouds[29, 30]. Using migration, a VM can be transferred fromone physical host to another without explicitly shuttingdown and subsequently restarting the VM [31]. The entirestate of the VM, including e.g., memory pages, are trans-ferred to the new host and the VM can resume itsexecution from its state prior to migration. As a con-sequence of this, no contextualization is triggered againwhen the VM is resumed, as the level of abstraction pro-vided by virtualization is insufficient for platform services.In this research migration from and to identical hyper-visor technology is considered. The topic of hypervisorinteroperability for migration is out of scope but is dis-cussed in work by Liu et al. [32]. The idea of reconfiguringcomputing services is by all means not a new subjectarea. Mohamed et al. [33] present work on reconfigura-tion of Web Services during runtime. In their approach,remote APIs for modifying values in running servicesare compiled into Java-based Web Services and are madeaccessible using remote method invocation.As presented by Ferrer et al. [4], there are several differ-

ent cloud scenarios that present a number of challenges todevelopment and deployment of an application. The abil-ity to perform VM migration is a necessity in all thesecloud scenarios, e.g., for the purpose of consolidatingresources and maintaining levels of QoS. Three of thesescenarios are cloud bursting, cloud federations, and bro-kered cloud deployment. For each scenario, the ability tomigrate VMs during runtime is important:

• Bursting - The partial or full migration of anapplication to a third party IP. This may occur whenlocal resources are near exhaustion.

• Federation - The migration of an applicationsworkload between a group of IPs. This normallyoccurs when a single IP’s resources are insufficientfor maintaining the high availability of an applicationthrough redundancy.


• Brokering - The automated migration of anapplication’s VMs across IPs. This is normally donefor the purpose of maintaining an agreed Quality ofService (QoS) in the case of an end-user utilizing abroker to select an IP given a set of selection criteria.

These scenarios have also been used to guide the defin-ing of requirements for any potential recontextualizationmechanism. In the bursting scenario, if an IaaS provideris not obligated to divulge third party providers used foroutsourcing of computational resources, an applicationmay end up deployed on to a third party’s infrastructurethat requires use of their local infrastructure services. Adynamic federation of IaaS providers created during nego-tiation time that alters during the operation phase requiresinfrastructure services to be discovered dynamically. Thesame is applicable in the case of a broker, knowledge ofa provider’s local infrastructure services is not availableduring deployment until after the broker has selected aprovider.The following general requirements have been extracted

from the scenarios and are considered as imperative:

i. A triggering mechanism for recontextualization onVMmigration or other events.

ii. A secure process to gather and recreatecontextualization data after migration or otherevents.

iii. A hypervisor agnostic solution that maintains IaaSprovider interoperability.

iv. An approach that is non-pervasive and minimizesmodifications at the IaaS level.

The lack of knowledge on the attributes of an IaaSprovider’s local infrastructure service available duringdeployment time further motivates this research. Anexample of such a service that exhibits configurationissues after resource migration is application-level moni-toring and is discussed in detail in our previous work [6].

A recontextualization mechanismWith the requirements in mind, we have consideredseveral approaches for mechanisms that would supportrecontextualization [6]. An approach using dynamic vir-tual device mounting is found to be the most promisingsolution for recontextualization due to inherent inter-operability and support in all major operating systems.Dynamic virtual device mounting is based on dynami-cally mounting virtual media containing newly generatedcontent in a running VM via the reuse of existing hypervi-sor interfaces and procedures. Interoperability is achievedby reusing existing drivers for removable media such asUSB disks or CD-ROM drives. Recontextualization canbe detected by the guest OS by reacting to events trig-gered when new USB or CD-ROMmedia is available. The

ability to manage virtual devices is also offered by the lib-virt API [34], inferring that there is fundamental supportfor these operations in most major hypervisors.The suggested approached has been implemented and

the performance has been assessed to confirm the feasi-bility of the approach in a real cloud infrastructure. Forall tests, libvirt version 0.9.9 is used to monitor and man-age the VMs. QEMU-KVMversion 1.0.50 andXen version4.0.0 are used as hypervisors, both running on the samehardware using CentOS 5.5 (final) with kernel version2.6.32.24. The hosts used in these tests are on the samesubnet, have shared storage and are comprised of a quadcore Intel Xeon X3430 CPU 2.40 GHz, 4 GB DDR3 @1333 MHz, 1 GBit NIC and a 250 GB 7200 RPM WDRE3 HDD.The results of the evaluation are shown in Fig. 1. The

first set of bars illustrate the time to migrate a VM fromone host to another with recontextualization running andcontext data attached. The second set of columns illus-trate the same migrations with recontextualization turnedoff and no virtual devices mounted. The third columnillustrates the time spent within the recontextualizer soft-ware during the tests from the first column, measuredfrom when the event for migration was received in therecontextualizer until the device had been removed andreattached. The values shown are the averages from tenruns, and all columns have error bars with the (marginal)standard deviations which are all in the 0.03 to 0.07 secondrange.Based on the evaluation we conclude that the recon-

textualization process adds about an 18% overhead usingeither hypervisor compared to normal migrations [6]. ForKVM, most of the extra time required for recontextualiza-tion is spent outside the bounds of our component. Thedelay is likely associated with processing events and extraoverhead imposed by preparing migration with virtualdevices attached. In the case of Xen the device manage-ment functionality in libvirt proved unreliable and wetherefore had to bypass the libvirt API. We instead had torely on sub-process calls from the recontextualizer to Xenusing the xm utility. This workaround increases the timeneeded for recontextualization in the Xen case. The inter-nal logic of the recontextualizer is discussed in full detailas part of Section ‘Design and architecture’ and withinProcedure 1.There are four major phases associated with the recon-

textualization process. First, information about the VMcorresponding to the event is resolved using libvirt whenthe migration event is received. In the second phase,any current virtual contextualization device is identifiedand detached. Third, new contextualization informationis prepared and bundled into a virtual device (ISO9660)image. Finally, the new virtual device is attached to theVM. A detailed breakdown of the time spent in different


Fig. 1 Time measurements of recontextualization

phases of recontextualization is presented in Fig. 2. Theabove mentioned workaround for Xen interactions affectsthe second and fourth phase (detaching and attachingof devices), most likely increasing the time required forprocessing. In the first and third phases Xen requires sig-nificantly longer time than KVMdespite running the sameinternal logic for recontextualization, using the same callsin the libvirt API. This indicates performance flaws eitherin the link between libvirt and Xen or in the core of Xenitself.

Contextualization versus recontextualizationAlthough contextualization and recontextualization sharemany similarities in that they help adapt services torunning in the cloud, they do however differ in one

fundamental way. Contextualization can only be used dur-ing deployment time to configure an application to aspecific IP’s environment. Recontextualization, however,enables an application to be migrated freely between dis-similar environments during runtime through the use ofan additional level of abstraction. One could considerrecontextualization to be an extension of contextualiza-tion, and base contextualization of services during deploy-ment (or development) is also needed to enable runtimerecontextualization.

Context-aware lifecycle managementAs discussed in Section ‘Service lifecycle’, a cloud serviceis prepared with configuration data built in during thedefinition phase. Complementing contextualization data,

Fig. 2 Breakdown of time spent during recontextualization


either generated or read from a repository, is injected bythe infrastructure during deployment. Parts of the con-textualization data may also be recontextualized duringruntime. In this work, we strive to create a model andmechanism capable of managing any kind of configura-tion and contextualization data in a fail-safe manner thatappears seamless to the software running inside as part ofthe service.To make the approach generally applicable we con-

sider several classes of data used for configuration/contextualization, where the classification is related to theentity from where it originates. For example:

• Web server configuration data is normally providedby the service developer, so this data would belong tothe service class.

• WAN network data is by necessity provided by theinfrastructure, and would belong to the infrastructureclass.

Other classes of data may include, e.g., legislative datathat depends on the current legislation in which the ser-vice is hosted, or data injected by a broker during anadvanced service deployment.Defining a complete ontology of service classes and their

relations is out of scope at this point, but is an impor-tant part of future work. The model presented in thispaper supports an arbitrary number of service classes,and relies on an internal prioritization of the classes todetermine which class should take precedence if the samedata is available from multiple sources. The feasibility ofthe approach is illustrated using a use-case featuring adistributed file system. The use-case employs data fromservice and infrastructure classes, and infrastructure-classdata is configured to have precedence in case of overlap-ping datasets.

Practical applicationsA generic approach with support for several classes of dataenables a service to be designed for generic cloud deploy-ment with a set of default settings. These default settingsmay be complemented and partly replaced with settingsprovided by, e.g., the infrastructure to which the service isdeployed. Through future formalization of the type of dataoffered by different actors, dynamic services with inheritsupport for self-* operations, e.g. self-configuration, canbe constructed and deployed to the cloud.For example, in previous work on recontextualiza-

tion [6], a monitoring use case was used to illustrate howthe infrastructure can update a setting used for inter-nal processes in the VM during runtime. In this work,we illustrate how the procedure can be used at the ser-vice level to reconfigure the internal connections of adistributed file system, adapting its operation to a new

geographic layout resulting from migration of VMs (seeSection ‘Functional evaluation’).Further use cases related to other aspects of self-* man-

agement are part of future work. For self-protection, theability to change the security level of the software exe-cuting inside the VM depending on, e.g., the geographicallocation of the current IP is an interesting area of research.This could include adjusting the level of encryption of datastreams passing in and out of the service component tomanage the balance between security and performance. Ifthe hosted service contains data only allowed to be hostedwithin certain legislations, recontextualization could beused to ensure that the operations of the service compo-nent is temporary suspended if the VM is (erroneously)migrated to a disallowed environment.

Design and architectureAsdescribed in Section ‘A recontextualizationmechanism’,earlier work explored several approaches to passing databetween the hypervisor and the processes running insidethe VM. The work in this paper retains the use of vir-tual devices as a transport mechanism, due to its nativesupport in major hypervisors and operating systems, anddoes not depend on network access. This is a key feature,since network access is one of the primary things that con-textualized settings can be used to enable. As previouslymentioned, the core idea of our suggested approach is todynamically generate customized ISO images which aremade available to the running VM instance. As the ISOimages can be freely changed (and re-mounted) duringrun-time, the context data can be updated at any point inthe VM lifecycle.Our proposed solution contains two distinct parts; tools

and services for contextualization running as part of thecloud controlling software on the infrastructure side, anda minimalistic process running inside each VM. Thecode running inside the VM runs a small virtual filesystem (described in Section ‘Flexible file system’) thatencapsulates the complexity of dealing with potentiallyoverlapping and conflicting sets of context data of dif-ferent classes. The software required for the file systemis made available during contextualization, and has min-imal OS dependencies. An overview of the componentsdesigned to run on the infrastructure side is shown inFig. 3, and a description of the roles of each componentfollows.

• Contextualizer offers API-level integration with thesurrounding cloud control system to integrate thecontextualization process in the workflow executedprior to deployment. The result of thecontextualization call is an ISO image file customizedto suit the running hypervisor with the necessarycontext data. Once completed the file is uploaded to a


Fig. 3 Overview of unified contextualizer architecture

data repository from where it can be fetched laterduring the service deployment procedure.

• Image service contains the code used for imagegeneration that is shared between contextualizationand recontextualization. This includes thecoordination of calls to image creation, fabrication,and conversion.

• ISO image creatormanipulates a set of templateISO images. In addition, this sub-component isresponsible for the creation of ISO images and theembedding of context data. The ISO Image Creatorhas access to a single set of context data processingscripts that are agnostic of a VM’s operating system,embedded in the ISO image and responsible forreading context data from the ISO image at run time.An internal interface provides access tocontextualization scripts embedded in the VM image.

• Image fabricatormanipulates VM images, passed toit by the VM Contextualizer, using underlying systemtools. This sub-component installs context dataoriginating from a manifest. A set of prefabricatedoperating system specific contextualization scripts,from a data store, are embedded for each operatingsystem with foreseen use at the IP level. The mainfunction of these scripts are to set the context ofoperating system level components such asconfiguring the network for DHCP access, orconnecting to a service-level VPN.

• Image converter transforms images from oneformat to another for the purpose of supportinginteroperability between IPs using differenthypervisor technology. Depending on the hypervisorand operating system, conversion can require thechanges made by the Image Fabricator to be revertedand reapplied. The Image Converter supports Xen,KVM, VMware, and VirtualBox hypervisors and hasbuilt-in support for a range of different image formats.

• Recontextualizer is a stand alone component thatmonitors events related to VM domains during

runtime. The recontextualizer is responsible fortriggering the creation and association of newinfrastructure class context data when applicabledomains are migrated to the infrastructure. Therecontextualizer is integrated with libvirt, and relieson libvirt’s unified approach to domain and devicemanagement to support runtime reactive virtualdevice management across a multitude of differenthypervisors.

Figure 3 also includes the order in which componentsare called. From the figure it can be seen that the Contex-tualizer component is invoked by the VM Manger duringapplication deployment (step 1) to create ISO images(steps 2, 3), create VM images (steps 4, 5) and/or manip-ulate VM images (steps 6, 7). After images have beencreated and/or manipulated, they are stored in a local datarepository (step 8) for deployment by the VM Manager.During operation, if an event from the underlying hyper-visor indicates that a VM has been stopped, started ormigrated (step 9), alterations to the existing ISO imagesare made (steps 10, 11) and reinserted into the VM’svirtual device (step 12).The flow of logic through the contextualizer compo-

nent is as follows: context data is gathered from a rangeof sources, it is processed into a usable fashion for usewithin a VM, stored within an ISO image and finallyassociated with the virtual hardware of a domain for useduring booting. The recontextualization mechanism (i.e.the internal logic), outlined in Procedure 1, registers inter-est with libvirt in a VM’s lifecycle by means of a callbackfunction before beginning its operation. When an eventis registered in the callback function it is classified andappropriate action taken. The exact events used to rep-resent a VM stopping or starting as a result of migrationmay differ depending on the underlying hypervisor. In theexample shown we use vmStop and vmStart events to alsocover migration, as these are the only events available withthe XEN hypervisor and libvirt.


If a stop event is detected the previous device contain-ing context data is detached and the device change iscommitted via libvirt, which proceeds to propagate thevirtual hardware change at the hypervisor level. In the caseof a start event being detected, infrastructure class con-text data is generated then packaged into an ISO image.The recontextualization mechanism interacts with libvirtto create a new virtual device with the contents of thedynamically generated ISO image. A failed VM migrationwill not affect recontextualization as the correspondingevents are only sent after a migration has been successful.

Procedure 1 Recontextualization Mechanism InternalLogic

connection = libvirt.open(‘URL’)libvirt.EventRegister(Callback())while true do

if connection.event thenfunction CALLBACK(event, domain)

if event.vmStop thendevice = getDeviceDef(domain)detachDevice(device)updateDevices()

end ifif event.vmStart then

contextData=createContextData(domain)makeIso(contextData)attachDevice(device)updateDevices()

end ifend function

end ifsleep()

end while

Although not shown in the illustration, the infrastruc-ture can trigger recontextualization in response to anyevent, not just migration. This enables the infrastructureto update the contents of the virtual device by gener-ating new context data and detaching and re-attachingthe virtual device. Using this construct, infrastructurespecific settings can be changed during runtime at theconvenience of the provider.

Flexible file systemFlexible File System (FFS) is a lean, read-only file sys-tem implementation that allows separate directory treesto be mounted into a single location. The resulting filesystem looks and acts like a single unified directory struc-ture while retaining all file contents and properties in theunderlying directory trees.FFS can be seen as a layered stack of file-sets, each set

comprised of different files and directories. When a user

attempts to read a file in the unified structure, FFS willattempt to fetch a file from the topmost (highest priori-tized) layer. If the file cannot be found at this layer, thecall will be delegated to lower layer(s) until it is found, orreturn an error if the file cannot be found in any layer. Thisprocess is illustrated in Fig. 4. In this example, there aretwo set of files (Layer 1 and Layer 2), and files in Layer 2have precedence. FFS will ensure that the two file sets aredisplayed and presented to the user in a coherent way, andthe user will not be able to distinguish which files are fromwhich file-set.In essence, the FFS file system solves many of the com-

plications of dealing with file-sets from different sources,as files from one set can overshadow a file from anotherset, without making permanent changes to either ofthe files. In the example shown in Fig. 4, the file ’F’from Layer 1 will not be visible to the user as it hasthe same name and path as a file from another file-set(Layer 2), which has precedence. If the Layer 2 file-setis removed (as can happen due to recontextualization,see Section ‘Recontextualization using FFS’), file ’F’ fromLayer 1 would be visible to the user, and the runningapplications are able to reconfigure to use the availablesettings.FFS is implemented using Filesystem in Userspace

(FUSE) [35], a kernel module that allows custom filesys-tem implementations to run in userspace without theneed for any changes in kernel space. The kernel moduleis available for most Unix-like system, including OpenSo-laris and OS X, and was merged into the main Linux ker-nel tree in 2011. Work on FUSE compatible technologiesfor Windows is ongoing [36].Creating a read-only file system requires four method

calls to be implemented:

• readdir(path) List all items in a path. In this case,FFS returns the union of listings from all layers.

• getattr(path) List attributes for the file or folderindicated by the path. FFS will return the actual fileattributes, with the attributes at the highest layertaking precedence if the path exists in more than onelayer.

• open(path, flags) Similarly to getattr(), the accessflags for the file with the highest precedence willapply.

• read(path, size, offset) Reads size bytes startingfrom offset in the file indicated by path, again beingresolved to the file located at the layer with thehighest precedence if more than one layer exists.

The required logic for managing several classes of datais implemented within these method calls, creating avirtual file structure based on the set of files currentlyavailable.


Fig. 4 Overview of Flexible File System layering. Calls from the operating system are rerouted by FFS to the topmost layer containing the file, orreturn File not found if neither layer contains the file

Recontextualization using FFSThe file system is initialized and started during thedeployment phase of the cloud service (see Table 1), withthe required files being part of the context data classoriginating from the service manifest. If multi-layeredcontextualization is not required for a particular service,the associated files can simply be omitted from the setof files specified in the manifest. When other layers ofcontext data (such as infrastructure specific settings) areavailable they will be made available as a separate layer inthe FFS stack. The order of the layers (configurable as partof the initial context files) determine the priority of files incase of overlapping datasets.Since layers can be added and removed during runtime,

recontextualization is natively supported by this approach.In the following section, we show results of testing usingthis setup to replace infrastructure specific data aftermigration to a new environment.

Functional evaluationEarlier in the paper we discussed how virtualization inval-idates some basic assumptions of server hosting, suchas the physical hardware constitution of the executingenvironment (vertical elasticity), or the physical locationof the system (migration). A similar behavior can alsobe observed at the application level inside the VMs. Forexample, distributed file systems such as Hadoop FS [37]perform optimization during initialization to ensure thatthe system exchanges data with a nearby server node tomaximize throughput and reduce latency. This approachassumes that the geographical location where the sys-tem is being hosted remains unchanged throughout theuptime of the service. This is normally a reasonableassumption when using physical hosting but one easily

invalidated in virtualized hosting as a result of VMmigra-tion. As a consequence, the performance of applicationssuch as Distributed File Systems (DFS) may be degradedpost-migration until the system is rebooted and a newinitialization phase optimization can take place. This sce-nario is illustrated in Fig. 5 where a client receives aconsiderable performance penalty for accessing a DFS’scache at a geographically remote location after migrationhas occurred. In this scenario, the contextualization andrecontextualization data is the IP address that points tothe local cache of the DFS and is modified in the con-figuration file of the DFS client running within the VM.

Fig. 5 Distributed File System operation post-migration. As a result ofprevious settings, client data is exchanged with a remote server node(a), instead of a nearby node after recontextualization (b)


For example, before recontextualization this IP could be192.168.1.1 and after 192.168.2.1.As the use of virtualized hosting becomes more

widespread, application-level systems need to be updatedto better respond to previously unexpected changes inthe hosting environment. For example, the degraded per-formance could in theory be detected by internal self-optimization techniques during runtime. However, fromthe perspective of the individual VM a performanceloss as a result of migration would be hard to distin-guish from a loss of performance due to heavy load onthe network. This is one factor that makes application-level self-optimization approaches more challenging todesign.By supporting recontextualization, the proposed con-

textualization framework offers unambiguous means oftriggering internal system events as a result of externalevents such as VMmigration or a change in the surround-ing hosting infrastructure. In the distributed file systemcase, recontextualization can be used to trigger a newoptimization phase post-migration, either by calling des-ignated functions in the file system client (if supported),or simply by restarting the client process.The above scenario has been used to illustrate the fea-

sibility of the suggested approach through a series oftests. The tests were performed on host machines withquad core Intel i7-920 CPU @ 2.66GHz, 24GB DDR3@ 1333MHz, 1GBit NIC and two 1500GB 7200RPMHDDs in RAID1. The following software inclusive ofversion numbers were used: Debian 6 (Kernel 2.6.32-5-xen-amd64), XEN 4.0.1, Libvirt 1.0.5 and GlusterFS 3.3.2.Three paravirtualized VMs were created, two acting asGluster servers serving a “brick” each as a replicated vol-ume and a third as a Gluster Client where the tests wereperformed on the exported file system stored within thevolume. In these tests, traffic shaping techniques (man-aged via the Linux Kernel Traffic Control command tc)have been used to simulate network delays and laten-cies between different hosts. The tests show how networkdelay and latencies affect the I/O performance of the Glus-ter FS distributed file system. The remote host in the testscenario is limited to 25Mbit of bandwidth, with an aver-age 10ms latency. The latency has a 2% variance followinga normal distribution and 25% correlation with the previ-ous traffic to simulate network fluctuations. The local hostis connected with a 500Mbit connection and a measuredaverage latency of 1.02ms (0.5% variance). These settingscorrespond to typical network conditions of WAN andLAN networks, respectively. The I/O testing is performedby running a series of tests using the Bonnie++ I/O testingframework [38]. Results from the tests are shown in Figs. 6and 7.It is important to note that the performance results are

strongly correlated with the traffic shaping settings, and

Fig. 6 Throughput per second of I/O operations when using a localfile system cache compared to a remote cache

the numerical results shown in the figures should not beemphasized. The purpose of these tests are to illustratethe functional capabilities of the suggested approach, anddemonstrate that contextualization and recontextualiza-tion can be used to adapt a running VM to changingexecution environments.As illustrated using these tests, considerable perfor-

mance gains can be achieved by optimizing the setupof application-level systems such as distributed file sys-tems during runtime. This is achieved by using recon-textualization to update the application with new settingscontaining details of what server node to use for its inter-actions. This demonstrates how the suggested approachcan be used as a corner stone in application-level self-*operations.

Fig. 7 Number of file operations per second of I/O operations whenusing a local file system cache compared to a remote cache


Conclusions and future workIn this work we have suggested a contextualizationapproach that supports several classes of data. The datacan originate from different sources, e.g. data related tothe service the VM instance is part of or data related tothe platform on which the instance is running. Data ofdifferent classes are layered on top of each other using alean virtual file system implementation, making it possibleto add or remove data layers during runtime. For exam-ple, the platform specific class of data can be replaced bythe infrastructure as a response to, e.g., a migration of theVM instance to a new executing environment. This way,the suggested contextualization solution is the first knownapproach to natively support recontextualization. Recon-textualization offer means to reconfigure the VM instanceas a result of external events or changes in the executionenvironment.Recontextualization can be used as a trigger for self-*

operations that cannot misinterpret events. This is incontrast to a VM trying to analyse when an event hadoccurred via its own internal procedures, for examplebased on when its external IP address changes. A dis-tributed file system use case demonstrated the feasibilityof our approach. In the use case recontextualization isused to reconfigure the VM to recover from performancedegradation experienced as a result of VM migration.Although the degradation is partly synthetic and corre-lated to the network settings used, we demonstrate thatperformance gains can be achieved by runtime optimiza-tion triggered by recontextualization.The limitations of our research are constrained to

the self-configuration property of autonomic comput-ing. Future work includes evaluating further use casesrelated to other self-* aspects such as self-protection.This includes the ability to adjust the security level andfunctionality of the service component depending on thecurrent geographical location.Additionally, we have mostly limited our research to

IaaS level applications of contextualization and recon-textualization. We touch upon using these technologiesalso for accessing platform specific functionality, suchas network based storage, offered as a service by IPs.There is great potential for employing these techniqueswithin PaaS systems, for example enabling dynamiccode replacement where software libraries (JAR files,DLLs, etc.) can be made available by the infrastruc-ture for execution within the service. This would allowfor arbitrary recontextualization also at the applicationlevel.Future technical work includes formalizing and stan-

dardizing the use of different classes of context data andtheir semantics. A common approach to contextualiza-tion is key to enable wide-spread and compatible sup-port across cloud boundaries. A unified representation

and interpretation of contextualization meta-data in man-ifests and service definitions also needs to be furtherdeveloped.

Competing interestsThe authors declare that they have no competing interests.

Authors’ contributionsDA and DE conducted the design, analysis and experiments ofcontextualization and recontextualization system within the paper. All authorsdrafted, read and approved the final manuscript.

AcknowledgementsThe research that led to these results is partially supported by the EuropeanCommission’s Seventh Framework Programme (FP7/2001-2013) under grantagreement numbers 257115 (OPTIMIS) and 610874 (ASCETiC). The authorswould also like to thank Tomas Forsman for technical assistance and expertise.

Author details1School of Computing, Faculty of Engineering, University of Leeds, LS2 9JTLeeds, UK. 2Department of Computing Science, Umeå University, SE-901 87Umeå, Sweden.

Received: 31 March 2015 Accepted: 30 June 2015

References1. Mell P, Grance T (2011) The NIST definition of cloud computing. NIST Spec

Publ 800:1452. Keahey K, Freeman T (2008) Contextualization: Providing One-Click Virtual

Clusters. In: Proceedings of the 4th IEEE International Conference onEScience (ESCIENCE ’08), Washington, DC, USA. pp 301–308

3. Armstrong D, Djemame K, Nair S, Tordsson J, Ziegler W (2011) Towards aContextualization Solution for Cloud Platform Services. In: CloudComputing Technology and Science (CloudCom), 2011 IEEE ThirdInternational Conference on. IEEE. pp 328–331

4. Ferrer A. J, Hernández F, Tordsson J, Elmroth E, Ali-Eldin A, Zsigri C, SirventR, Guitart J, Badia R. M, Djemame K, Ziegler W, Dimitrakos T, Nair S. K,Kousiouris G, Konstanteli K, Varvarigou T, Hudzia B, Kipp A, Wesner S,Corrales M, Forgó N, Sharif T, Sheridan C (2011) OPTIMIS: a HolisticApproach to Cloud Service Provisioning. Futur Gener Comput Syst28:66–77

5. Rochwerger B, Caceres J, Montero RS, Breitgand D, Elmroth E, Galis A,Levy E, Llorente IM, Nagin K, Wolfstha Y (2009) The Reservoir model andarchitecture for open federated cloud computing. IBM J Res Dev 53(4)

6. Armstrong D, Espling D, Tordsson J, Djemame K, Elmroth E (2013)Runtime Virtual Machine Recontextualization for Clouds. In: Caragiannis I,Alexander M, Badia R, Cannataro M, Costan A, Danelutto M, Desprez F,Krammer B, Sahuquillo J, Scott S, Weidendorfer J (eds). Euro-Par 2012:Parallel Processing Workshops. Lecture Notes in Computer Science.Springer Berlin Heidelberg, Heidelberger Square 3, 14197 Berlin, GermanyVol. 7640. pp 567–76

7. Barham P, Dragovic B, Fraser K, Hand S, Harris T, Ho A, Neugebauer R, PrattI, Warfield A (2003) Xen and the art of virtualization. SIGOPS Oper Syst Rev37(5):164–177

8. Popek GJ, Goldberg RP (1974) Formal requirements for virtualizable thirdgeneration architectures. Commun ACM 17(7):412–421

9. Dawoud W, Takouna I, Meinel C (2012) Elastic virtual machine forfine-grained cloud resource provisioning. In: Global Trends in Computingand Communication Systems. Springer Berlin Heidelberg, HeidelbergerSquare 3, 14197 Berlin, Germany. pp 11–25

10. Kalyvianaki E, Charalambous T, Hand S (2009) Self-adaptive andself-configured cpu resource provisioning for virtualized servers usingkalman filters. In: Proceedings of the 6th International Conference onAutonomic Computing. ACM. pp 117–126

11. Galán F, Sampaio A, Rodero-Merino L, Loy I, Gil V, Vaquero LM (2009)Service specification in cloud environments based on extensions to openstandards. In: Proceedings of the Fourth International ICST Conference onCommunication System Software and Middleware. ACM. p 19


12. Aiello R, Sachs L (2010) Configuration Management Best Practices:Practical Methods that Work In the Real World. 1st edn. Addison-WesleyProfessional, Boston, USA

13. CFEngine 3 - Configuration Management Software for Agile SystemAdministrators. http://aws.amazon.com. Online (Accessed: March 2015)

14. Puppet - IT Automation for System Administrators. http://puppetlabs.com/. Online (Accessed: March 2015)

15. Chef - A Systems Integration Framework. https://www.chef.io/chef/.Online (Accessed: March 2015)

16. Kephart JO, Chess DM (2003) The Vision Of Autonomic Computing.Computer 36(1):41–50

17. Dautov R, Paraskakis I, Stannett M (2014) Utilising stream reasoningtechniques to underpin an autonomous framework for cloud applicationplatforms. J Cloud Comput 3(1):13

18. Karakostas B (2014) Towards Autonomic Cloud Configuration andDeployment Environments. In: International Conference on Cloud andAutonomic Computing (ICCAC). pp 93–96

19. Fargo F, Tunc C, Al-Nashif Y, Akoglu A, Hariri S (2014) AutonomicWorkload and Resources Management of Cloud Computing Services. In:International Conference on Cloud and Autonomic Computing (ICCAC).pp 101–110

20. Maurer M, Brandic I, Sakellariou R (2012) Adaptive resource configurationfor Cloud infrastructure management. Futur Gener Comput Syst

21. Wood T, Shenoy P, Venkataramani A, Yousif M (2009) Sandpiper:Black-box and gray-box resource management for virtual machines.Comput Netw 53(17):2923–2938

22. Shrivastava V, Zerfos P, Lee K-w, Jamjoom H, Liu Y-H, Banerjee S (2011)Application-aware virtual machine migration in data centers. In:INFOCOM, 2011 Proceedings IEEE. IEEE. pp 66–70

23. Athreya AP, DeBruhl B, Tague P (2013) Designing for self-configurationand self-adaptation in the Internet of Things. In: Collaborative Computing:Networking, Applications and Worksharing (Collaboratecom), 2013 9thInternational Conference Conference on. IEEE. pp 585–592

24. Microsoft: Windows Azure. http://www.windowsazure.com. Online(Accessed: March 2015)

25. Microsoft: Windows Azure’s Role Environment Class. http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.aspx. Online (Accessed: March 2015)

26. Gong Z, Gu X, Wilkes J (2010) PRESS: PRedictive Elastic ReSource Scalingfor cloud systems. In: Proceedings of the 6th International Conference onNetwork and Service Management (CNSM ’10), Piscataway, NJ, USA.pp 9–16

27. Krishnan S, Counio JC (2010) Pepper: An Elastic Web Server Farm forCloud Based on Hadoop. In: Proceedings of the 2nd IEEE InternationalConference on Cloud Computing Technology and Science(CloudCom ’10), Los Alamitos, CA, USA. pp 741–747

28. Vaquero LM, Rodero-Merino L, Caceres J, Lindner M (2009) A break in theclouds: towards a cloud definition. SIGCOMM Comput Commun Rev39(1):50–55

29. Bradford R, Kotsovinos E, Feldmann A, Schiöberg H (2007) Live wide-areamigration of virtual machines including local persistent state. In:Proceedings of the 3rd International Conference on Virtual ExecutionEnvironments. ACM. pp 169–179

30. Wood T, Ramakrishnan KK, Shenoy P, van der Merwe J (2011) CloudNet:dynamic pooling of cloud resources by live WAN migration ofvirtual machines. In: Proceedings of the 7th ACM SIGPLAN/SIGOPSInternational Conference on Virtual Execution Environments. ACM.pp 121–132

31. Clark C, Fraser K, Hand S, Hansen JG, Jul E, Limpach C, Pratt I, Warfield A(2005) Live migration of virtual machines. In: Proceedings of the 2ndConference on Symposium on Networked Systems Design &Implementation-Volume 2. USENIX Association. pp 273–286

32. Liu P, Yang Z, Song X, Zhou Y, Chen H, Zang B (2008) Heterogeneous livemigration of virtual machines. In: International Workshop on VirtualizationTechnology (IWVT’08)

33. Mohamed M, Belaid D, Tata S (2013) Adding Monitoring andReconfiguration Facilities for Service-Based Applications in the Cloud. In:Advanced Information Networking and Applications (AINA), 2013 IEEE27th International Conference on. pp 756–763

34. Libvirt: The virtualization API. http://libvirt.org/. Online (Accessed: March2015)

35. Szeredi M Filesystem in userspace. http://fuse.sourceforge.net/. Online(Accessed: March 2015)

36. Dokan. http://dokan-dev.net/en. Online (Accessed: March 2015)37. Borthakur D (2007) The hadoop distributed file system: Architecture and

design. Hadoop Project Website 11:2138. Coker R Bonnie++ file-system benchmark. http://www.coker.com.au/

bonnie++. Online (Accessed: March 2015)

Submit your manuscript to a journal and benefi t from:

7 Convenient online submission

7 Rigorous peer review

7 Immediate publication on acceptance

7 Open access: articles freely available online

7 High visibility within the fi eld

7 Retaining the copyright to your article

Submit your next manuscript at 7 springeropen.com

http://aws.amazon.com

http://puppetlabs.com/

http://puppetlabs.com/

https://www.chef.io/chef/

http://www.windowsazure.com

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.aspx



http://libvirt.org/

http://fuse.sourceforge.net/

http://dokan-dev.net/en

http://www.coker.com.au/bonnie++

http://www.coker.com.au/bonnie++

journal of cloud computing - advances, systems and...

Documents