Handoff of virtual machines based on security requirements

Examples disclosed herein provide systems, methods, and software to handoff virtual machines between hypervisors. In one implementation, a method of transitioning a virtual machine from a first hypervisor to a second hypervisor includes identifying a request to transition the virtual machine from the first hypervisor to the second hypervisor. The method further provides determining security trust requirements for the virtual machine, and exchanging trust information between the first hypervisor and the second hypervisor. The method further provides determining if the second hypervisor can support the virtual machine based on the security trust requirements and the trust information, and transitioning the device to the second hypervisor if the second hypervisor can support the virtual machine.

TECHNICAL BACKGROUND

A virtual machine is a software implementation of a computer that includes its own guest operating system to execute one or more applications and processes. A host computing system allocates a certain amount of its resources to each of the virtual machines, and multiplexes the underlying hardware platform among the virtual machines. Each virtual machine is then able to use the allocated resources, such as processing cycles, memory, and the like to execute its own guest operating system and applications. The software layer providing the virtualization is commonly referred to as a hypervisor, which abstracts the underlying hardware of the host computer and provides the abstracted hardware to each of the individual virtual machines.

During execution of the virtual machines on the host computing systems, virtual machines may require a handoff from a first hypervisor to a second hypervisor to provide the proper operations. This handoff requirement may occur as a result of updates to a host computing system, updates to a hypervisor on a host computing system, a new host computing system becoming available for the virtual machine, or any other reason.

In some implementations, virtual machines may be distributed across multiple host computing systems and hypervisors to provide various data services. These virtual machines, sometimes referred to as virtual network elements, forward data packets for the data services, wherein the different data services are associated with a particular subset of virtual network elements. For example, a first set of virtual network elements may be associated with a first data service, while a second set of virtual network elements are associated with a second data service. These network elements include, but are not limited to, a: Mobility Management Entity (MME), Service Gateway (S-GW), Packet Data Network Gateway (P-GW), Policy Charging and Rules Function (PCRF), Home Subscriber System (HSS), Baseband Processing Unit (BBU), Radio Resource Control (RRC) processor, Radio Link Control (RLC) processor, Packet Data Convergence Protocol (PDCP) processor, Media Access Control (MAC) processor, Residential Gateway (R-GW), Set-Top Box (STB), Dynamic Host Control Protocol (DHCP) server, Network Address Translation (NAT) firewall, Border Controller (BC), Load Balancer (LB), media server, and network accelerator.

Overview

Examples described herein provide enhancements to the handoff process for a virtual machine from a first hypervisor to a second hypervisor. In one implementation, a method of transitioning a virtual machine from a first hypervisor to a second hypervisor includes identifying a request to transition the virtual machine from the first hypervisor to the second hypervisor. The method further provides determining security trust requirements for the virtual machine and exchanging trust information between the first hypervisor and the second hypervisor. The method also provides determining whether the second hypervisor is capable of supporting the virtual machine based on the trust information and the security trust requirements for the virtual machine and, if the second hypervisor is capable of supporting the virtual machine, initiating a handoff of the virtual machine from the first hypervisor to the second hypervisor.

DETAILED DESCRIPTION

FIG. 1illustrates a computing environment100to transition virtual machines between hypervisors based on security requirements of the virtual machines. Computing environment100includes host computing systems110-111, which further comprises hypervisors115-116and virtual machines120-123. Host computing systems110-111communicate over communication link140. Host computing systems110-111may each comprise a server computer, desktop computer, laptop computer, or any other similar computing system capable of executing virtual machines120-123and hypervisors115-116, including combinations thereof. Host computing systems110-111may each include processing systems, storage systems, communication interfaces, user interfaces, and other similar computing hardware. Communication link140may use metal, glass, optical, air, space, or some other material as the transport media. Communication link may use Time Division Multiplex (TDM), asynchronous transfer mode (ATM), IP, Ethernet, synchronous optical networking (SONET), hybrid fiber-coax (HFC), circuit-switched, communication signaling, wireless communications, or some other communication format, including improvements thereof.

In operation, hypervisors115-116, which may comprise software or firmware, provide a platform from which virtual machines120-123can execute. In particular, hypervisors115-116may abstract the components of host computing systems110-111and provide virtual hardware to the virtual machines. This virtual hardware may include processing systems, storage systems, communication interfaces, user interfaces, and other similar virtually represented hardware that may or may not reflect the physical hardware of host computing systems110-111. Each virtual machine of virtual machines120-123may include an operating system, applications, and other processes to provide a particular operation.

In some implementations, virtual machines120-123may comprise virtual network elements that forward data communication packets for user data services. For example, host computing system110-111may be used to provide wireless communication services to a plurality of end user devices. To provide the services various gateways, routers, and control systems may be used to route and provide the required communications. Here, rather than providing the gateway, routers, and control systems on separate computing systems, host computing systems110-111allow the various network elements to share the resources of an underlying computing system. These resources may include time slices for processing, processing cores, memory, and other similar resources of the underlying computing system.

Although each of the virtual machines may share the resources of a host computing system, each of the virtual machines may be required to migrate to an alternative hypervisor or host to provide a desired operation. For example, virtual machines may migrate because the host machine requires an update, because another physical machine would provide better support for the operation of the virtual machine, because a new host machine has become available, or for any other reason. Prior to migrating a virtual machine, security requirements for the virtual machine are determined, and compared against the security characteristics that can be provided by the new hypervisor and host machine. For example, a virtual machine may require a certain time slice configuration, processing core resources, memory resources, or other similar resources from the host computing system. Further, the virtual machine may require that only particular virtual machines can be co-executing on the same host computing system or hypervisor. For instance, a virtual machine may require that all other virtual machines on the hypervisor belong to the same data service.

In addition to determining the requirements for the virtual machine, hypervisor115may inquire hypervisor116to determine if the security requirements are met for migrating the virtual machine. If the requirements are not met, then hypervisor115may refuse to migrate the virtual machine and, in some examples, may generate a notification for an administrator that the migration of the virtual machine has failed. In contrast, if the hypervisor does provide the necessary security and resources for the virtual machine, then hypervisor115may initiate a migration of the virtual machine from first hypervisor115to second hypervisor116.

FIG. 2illustrates a method200of operating hypervisor115to transition virtual machine120between hypervisors based on security requirements of the virtual machine. The operations ofFIG. 2are referenced parenthetically in the description below. As described inFIG. 1, virtual machines may require transitions between hypervisors and host computing systems for a variety of purposes, including, but not limited to, the current host computing system requiring an update, the initiation of a new host computing system, or the new host computing system providing a better platform for the virtual machine operations.

In the present example, hypervisor115identifies a request to transition virtual machine120from hypervisor115to hypervisor116(201). Although illustrated separate in the present example, it should be understood that hypervisor115and hypervisor116might reside on the same host computing system. In some examples, the notification to transition hypervisors may be generated by an administrator on host computing system110or at an administration console communicatively coupled to host computing system110. However, in other implementations, the request for transitioning the virtual machine to an alternative hypervisor may be generated by an automated process, such as a process that allocates the virtual machines across multiple computing systems and hypervisors.

In response to the request to transition virtual machine110, hypervisor115determines security trust requirements for virtual machine110(202). In some implementations, hypervisor115may inquire virtual machine110for the trust requirements, but may also inquire a database or data structure that stores the security information for the virtual machine. The security requirements may include resource availability requirements, including time slice requirements, processing core availability requirements, memory availability requirements, or any other similar resource availability requirements. In addition to or in place of the resource availability requirements, the security trust requirements may include information about the other virtual machines that are executing on the new host computing system. Referring toFIG. 1, virtual machine120may require that all virtual machines executing on the same hypervisor belong to the same data service. Accordingly, if virtual machine120provided the operations of a packet data network gateway, virtual machine123may be required to provide serving gateway operations, router operations, or other similar operations for the same data service associated with virtual machine120.

In addition to determining the security trust requirements for virtual machine120, trust information is exchanged between hypervisor115and hypervisor116(203). In some implementations, hypervisor115may query hypervisor116for trust information related to the current operations of virtual machines executing on hypervisor116. This trust information may include information about the number of cores available to provide to virtual machine120, the time slices that could be provided to virtual machine120, the amount of memory that could be provided to virtual machine120, the types and/or operations of virtual machines currently executing on hypervisor116, or any other similar information related to the security trust requirements of virtual machine120.

In some implementations, the exchange of trust information between hypervisor115and hypervisor116may include an exchange of passphrases or hashes that can be used to verify hypervisor116, host computing system111, and the other virtual machines executing on hypervisor116. For example, hypervisor115may provide one or more passphrases or hashes to hypervisor116. In response to receiving the hashes, hypervisor116or a related security module on host computing system111may apply one or more keys to the passphrases to generate response phrases that can then be transferred back to hypervisor115. Once received at hypervisor115, hypervisor115may compare the response phrases with expected results to determine if the new hypervisor and/or host computing system is capable of supporting the transition of the virtual machine.

In some examples, host computing system110and host computing system111may implement trust modules, such as Roots of Trust (RoT), not illustrated inFIG. 1, that are capable of verifying the virtual machines and hypervisors on the host computing systems. Roots of Trust are a set of functions in a separate trusted computing module on the host computing systems, which serve as separate computing processes that control the trust operations for the computing system. For example, to generate the hash between hypervisor115and hypervisor116, the Roots of Trust may generate a particular hash or phrase to be provided to hypervisor116. In response to the phrase, hypervisor116may call a Root of Trust module on host computing system111to apply a key to the provided phrase, and generate a response phrase. The response phrase from the Root of Trust module on host computing system111, may be provided to hypervisor115and the Root of Trust module on host computing system110. The response phrase may then be compared by the Root of Trust module on host computing system110to an expected result, determining if host computing system111is capable of supporting the transition of the virtual machine.

After the exchanging the trust information between the hypervisors, hypervisor115determines whether hypervisor116is capable of supporting virtual machine120based on the exchanged trust information and the security trust requirements for virtual machine120(204). In some implementations, at least a portion of the retrieved information from hypervisor116may be compared to a data structure containing the requirements for virtual machine120. If hypervisor116is capable of supporting virtual machine120, hypervisor115may initiate a handoff of virtual machine120from hypervisor115to hypervisor116(205). This handoff may include ceasing execution of virtual machine120on hypervisor115, and initiating execution of virtual machine120on hypervisor116.

Although illustrated on separate host computing systems in the present example, it should be understood that hypervisors115-116may reside on the same host computing system in some implementations. Further, despite not being illustrated in the example ofFIG. 1, it should be understood that a management system or console may be used to manage the various host computing systems and virtual machines within the computing environment. In this configuration, the management console may initiate the transition of a virtual machine from the first hypervisor to a second hypervisor, as well as provide a variety of other management operations.

FIG. 3illustrates an operational scenario300of transitioning a virtual machine between hypervisors based on security requirements of the virtual machine. Operational scenario300includes host computing systems310-311, and hypervisors315-316that provide a platform for virtual machines320-323.

As illustrated, a transition request is initiated for virtual machine320to transition from host computing system310and hypervisor315to host computing system311and hypervisor316. This transition request may be initiated by an administrator on host computing system310, by an administrator at an administration console communicatively coupled to host computing system310, or by an automated process either locally on host computing system310or on a management system external to host computing system310. In response to the request, hypervisor315determines security trust requirements for virtual machine320. These security trust requirements may include operational requirements for host computing system311, including processing resource requirements for virtual machine320, memory resource requirements for virtual machine320, time slice requirements for virtual machine320, amongst other similar requirements. Further, the security trust requirements may include requirements for other virtual machines that would also be executing on host computing system311and hypervisor316. These other virtual machine requirements may include requirements that the virtual machines provide certain operations, the virtual machines belong to a particular service or network, the virtual machines do not belong to a particular service or network, or other similar virtual machine requirements. For example, virtual machine320may comprise a virtual network element that forwards data packets for a data service. Accordingly, virtual machine320may require that all virtual machines executing on the same hypervisor belong to the same data service.

In addition to determining the trust requirements for virtual machine320, hypervisor315exchanges trust information with destination hypervisor316. This trust information corresponds to the security trust requirements for the virtual machine. Accordingly, hypervisor315may retrieve or obtain information about the available processing resources, memory resources, time slices, and other similar availability information. Hypervisor315may further obtain information about the other virtual machines currently executing on hypervisor316, including information about virtual machine323, such as the current operations of virtual machine323, the type of data service associated with virtual machine323, or any other similar information.

In some implementations, the trust requirements for virtual machine320may require that host computing system310and hypervisor315verify, or established trust with, host computing system311and hypervisor316before a handoff process can be initiated for the virtual machine. To verify host computing system311and hypervisor316, Root of Trust modules or other similar trust modules located on host computing systems310-311may be used to exchange at least a portion of the trust information between the systems. For example, to verify the machine, a Root of Trust module on host computing system310will generate, using a random value generator, a time based generator, or some other phrase generator, and transfer a phrase to host computing system311. In response to receiving the phrase, a second Root of Trust module located on host computing system311may apply a key to the phrase and send a response to host computing system310. Once received, host computing system310may compare the response to an expected value to determine if host computing system311and hypervisor316can be trusted for the virtual machine. In some implementations, in addition to or in place of verifying the host computing system and the hypervisor, the trust modules may be used to transfer encrypted trust information from host computing system311to host computing system310. Once transferred and received at host computing system310, local trust modules on host computing system310may decrypt the provided trust information, which may include information about resources available to the new virtual machine, information about other virtual machines executing on the hypervisor, or any other similar information.

After the trust information is exchanged with hypervisor316and host computing system311, hypervisor315determines whether hypervisor316and host computing system311are capable of supporting the virtual machine. If they are not capable of supporting the virtual machine, then hypervisor315may prevent the transition of the virtual machine to host computing system311. However, if hypervisor316is approved to support the virtual machine, as is illustrated inFIG. 3, then a process may be initiated to transition virtual machine320from hypervisor315to hypervisor316. This process may include terminating the virtual machine on hypervisor315and initiating the virtual machine on hypervisor316.

FIG. 4illustrates a data structure400for transitioning virtual machines between hypervisors based on security requirements of the virtual machines. Data structure400includes virtual machines410and trust requirements420-421, which include requirements431-438. Data structure400may be stored on a host computing system, on an external resource, or in any other storage location accessible by a hypervisor that provides a platform to virtual machines (VMs)411-414.

In operation, virtual machines may require migration from a first hypervisor to a second hypervisor for a variety of purposes. To migrate a virtual machine, the hypervisor providing the platform for the virtual machine may ensure that the new host and hypervisor includes the required security for the currently executing virtual machine. For example, if virtual machine411were identified to be transitioned, requirement431and requirement435may be recognized by the hypervisor as security pre-requisites for migrating the virtual machine. Once the requisites are identified, and security information is exchanged with the destination hypervisor, the current hypervisor may compare the retrieved security information with the security trust requirements in data structure400to determine if a handoff operation is permitted for the virtual machine. Referring to the previous example of virtual machine411, if the retrieved security information meets requirement431and requirement435, a handoff process may be initiated for virtual machine411.

In some implementations, a large number of security exchanges between the hypervisors and computing systems of an environment may be burdensome on the communication interfaces and processing systems of the host computing systems. Accordingly, when there is a large amount of traffic or when quicker virtual machine migrations are preferred, changes may be made to the security information exchanges. These changes to the security information exchanges may be automated based on the number of migrations required, or may be specified by an administrator of the computing environment. For example, an administrator may specify that the security requirement checks between hypervisors should be eliminated to reduce the overhead associated with verifying hypervisors to support virtual machines. Accordingly, rather than exchanging the security information between hypervisors, the security verification step may be skipped, and the handoff process may be immediately initiated.

FIG. 5illustrates a computing environment500to transition virtual network elements from a first host computing system to a second host computing system. Computing environment500includes host computing systems510-511and hypervisors515-516that provide a platform for virtual network elements520-523. Virtual network elements520-523are configured to forward data packets for a data service, such as a Long Term Evolution communication service. Virtual network elements520-523may comprise gateways and routers for the data service, and may further comprise control systems, such mobility management entities for the data service.

In operation, virtual network elements520-523are deployed on host computing systems510-511to provide data services for connecting end user devices. During execution on the hypervisors, an administrator or an automated process may determine that virtual network element520requires a handoff from a hypervisor515to hypervisor516. This determination may be made directly on host computing system510, or may be registered via an administration console communicatively coupled to the host computing system.

In response to transition request for virtual network element520, hypervisor515determines security requirements for virtual network element520. These security requirements include, but are not limited to, processing and memory resources that are required for the network element, verification of the new host computing system, or requirements for the co-executing virtual machines on the new host computing system. Here, hypervisor515is required to verify host computing system511and hypervisor516to support virtual network element520. To verify the new system for virtual network element, a security software module, such as a Root of Trust module on host computing system510may generate a security phrase and transfer the phrase to host computing system511. Once received, hypervisor511may use a security software module located on the system to generate a response phrase, and transfer the response phrase to host computing system510. Once received, hypervisor515with the assistance of the security software module may compare the response phrase to an expected result. If the response phrase does not match the expected result, hypervisor515may refuse the handoff to hypervisor516. However, if the response phrase does match the expected result, hypervisor515may initiate a handoff process to hypervisor516and host computing system511. This handoff process may include ceasing execution of virtual network element on hypervisor515, and initiating execution of the virtual network element on hypervisor516. The process may also include, in some implementations, a transfer of the virtual volume containing the virtual network element data to host computing system511, wherein the virtual volume may comprise a virtual machine disk (VMDK), a virtual hard disk (VHD), or any other similar virtual volume file or files.

Although illustrated in the present example as exchanging phrases to verify the computing system and the hypervisor, it should be understood that other data and information may be exchanged between the hosts and hypervisors. For example, to determine the security trust information, hypervisor515may request and receive various operational information from hypervisor516and host511. This information may include reports about available processing resources for virtual network element, memory resources for virtual network element, information about other virtual machines executing on the host computing system, or any other similar information. Once received from host computing system511, hypervisor515may compare the received data with the trust requirements for the virtual machine to determine whether to allow the transfer of virtual network element520.

As an example, virtual network element520may require that co-executing virtual network elements on the same host computing system belong to the same data service. Accordingly, hypervisor516may provide hypervisor515with information corresponding to the operations of virtual network element523. If virtual network element523belonged to a second data service different from the data service for virtual network element520, then virtual network element520may be prevented from migrating to host computing system511. In contrast, if the operational information from hypervisor516indicated that virtual network element523corresponded to the same data service, then hypervisor515may initiate the handoff process for virtual network element520.

Although illustrated inFIGS. 1-5as using a hypervisor to determine whether to handoff a virtual machine between hypervisors, it should be understood that other processes executing on the host computing systems may assist in determining whether to handoff a virtual machine. For example, one or more software modules on a host computing system may be used to identify the transition request for the virtual machine, determine security trust requirements for the virtual machine, or any other similar process described herein. Further, in some implementations, the operations described herein may be implemented at least partially by a hypervisor manager for the computing environment. Referring to the example ofFIG. 1, a hypervisor manager, which may be a separate computing system communicatively coupled to host computing systems110-111, may be configured to identify a request to transition virtual machine120from hypervisor115to hypervisor116, identify security trust requirements for virtual machine120, and identify at least a portion of the security information from hypervisor116. Accordingly, rather than providing all of the handoff operations within the host computing systems, at least a portion of the handoff determination operations may be initiated or executed within a hypervisor manager.

FIG. 6illustrates a computing system600capable of transitioning a virtual machine from a first hypervisor to a second hypervisor. Computing system600is representative of any computing system or systems with which the various operational architectures, processes, scenarios, and sequences disclosed herein for transitioning virtual machines may be implemented. Computing system600is an example of host computing systems110,310, and510, although it should be understood that other examples may exist. Computing system600comprises communication interface601, user interface602, and processing system603. Processing system603is linked to communication interface601and user interface602. Processing system603includes processing circuitry605and memory device606that stores operating software607. Computing system600may include other well-known components such as a battery and enclosure that are not shown for clarity. Computing system600may be a personal computer, server, or some other computing apparatus—including combinations thereof.

Communication interface601comprises components that communicate over communication links, such as network cards, ports, radio frequency (RF) transceivers, processing circuitry and software, or some other communication devices. Communication interface601may be configured to communicate over metallic, wireless, or optical links. Communication interface601may be configured to use Time Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format—including combinations thereof. In some implementations, communication interface601may be configured to communicate with one or more host computing systems capable of hosting virtual machines.

User interface602comprises components that interact with a user to receive user inputs and to present media and/or information. User interface602may include a speaker, microphone, buttons, lights, display screen, touch screen, touch pad, scroll wheel, communication port, or some other user input/output apparatus—including combinations thereof. User interface602may be omitted in some examples.

Processing circuitry605comprises microprocessor and other circuitry that retrieves and executes operating software607from memory device606. Memory device606comprises a non-transitory storage medium, such as a disk drive, flash drive, data storage circuitry, or some other memory apparatus. Processing circuitry605is typically mounted on a circuit board that may also hold memory device606and portions of communication interface601and user interface602. Operating software607comprises computer programs, firmware, or some other form of machine-readable processing instructions. Operating software607includes request module608, requirement (req) module609, exchange module610, and determine module611, although any number of software modules may provide the same operation. Operating software607may further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. Although not illustrated in the present example, it should be understood that software607may include at least one hypervisor configured to provide a platform for one or more executing virtual machines. When executed by processing circuitry605, operating software607directs processing system603to operate computing system600as described herein.

In particular, request module608, when executed by processing system603, directs processing system603to identify a request for to handoff a virtual machine from a first hypervisor to a second hypervisor. In response to the request to handoff the virtual machine, requirement module609directs processing system603to determine security trust requirements for the virtual machine. These security trust requirements may include resources requirements for the virtual machine, such as processing resources for the virtual machine, memory resources for the virtual machine, time slice resource requirements, or any other similar requirement. Further, the security trust requirements may include requirements for other processes and virtual machines executing on destination host computing system. For example, a virtual machine may require all virtual machines executing on a host computing system to represent network elements for the same data service.

In addition to determining the security requirements for the virtual machine associated with the handoff request, exchange module610is configured to exchange trust information with the destination host computing system and/or hypervisor. In particular, exchange module610may be configured to retrieve various security information from the destination host and hypervisor, including the processing support that can be provided to the virtual machine, the memory that can be allocated to the virtual machine, the time slices that could be provided to the virtual machine, or information about other virtual machines executing via the destination hypervisor. In addition to or in place of the previously mentioned security information, in some implementations, computing system600may be configured to exchange one or more hashes or security phrases that can be used to verify the destination hypervisor and computing system.

Once the trust information is exchanged between the computing system600and the destination computing system and hypervisor, determine module611directs processing system603to determine whether the destination hypervisor is capable of supporting the handoff of the virtual machine. If the destination hypervisor is incapable of providing the required security for the virtual machine, the computing system600may prevent the handoff of the virtual machine. However, if the destination hypervisor is capable of supporting the virtual machine, determine module611may direct processing system603to initiate a handoff process of the virtual machine to the destination hypervisor. In some implementations, this may include ceasing execution of the virtual machine on computing system600and directing the destination hypervisor to initiate execution of the virtual machine.

In some implementations, the virtual machines that are executing on computing system600comprise virtual network elements configured to provide a data service to one or more end user devices. These virtual network elements may provide gateways, routers, and other control functions within a data network, such as a Long Term Evolution (LTE) network. As a result, in some examples, the security trust requirements for the virtual machines may correspond to the data service with which the virtual network elements belong. As an illustrative example, the virtual machine to be transitioned from computing system600may belong to a first data service, and may be associated with a trust requirement that requires all other virtual machines on the same hypervisor to belong to the first data service. Consequently, if a handoff request were initiated to a hypervisor executing a second virtual network element associated with a second data service, computing system600may refuse to handoff the device.