[go: up one dir, main page]

WO2012118849A1 - Migration de groupement de machines virtuelles - Google Patents

Migration de groupement de machines virtuelles Download PDF

Info

Publication number
WO2012118849A1
WO2012118849A1 PCT/US2012/027007 US2012027007W WO2012118849A1 WO 2012118849 A1 WO2012118849 A1 WO 2012118849A1 US 2012027007 W US2012027007 W US 2012027007W WO 2012118849 A1 WO2012118849 A1 WO 2012118849A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
source
pool
virtual machines
master image
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2012/027007
Other languages
English (en)
Inventor
Harold C. SIMONSEN
Ashton R. SNELGROVE
Thomas S. MCCULLAGH
David E. YOUNGBERG
Chris R. FEATHERSTONE
Peter Bookman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
V3 Systems Holdings Inc
Original Assignee
V3 Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/250,836 external-priority patent/US9542215B2/en
Application filed by V3 Systems Inc filed Critical V3 Systems Inc
Publication of WO2012118849A1 publication Critical patent/WO2012118849A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G06F9/5088—Techniques for rebalancing the load in a distributed system involving task migration
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5011—Pool

Definitions

  • the desktop environment may include an intuitive visualization of various icons, windows, and other tools that that user may interact with to manipulate the various applications and environments offered by the desktop environment.
  • desktop virtualization involves the offloading of the desktop processing to a location other the client (hereinafter referred to as a "centralized desktop location"), which location is perhaps even remote from the client. That offloaded location may be a server, a server cluster, or a server cloud.
  • the centralized desktop location maintains a virtual machine for each supported desktop environment.
  • the virtual machine has access to all of the desktop state necessary to construct an image for how the desktop environment should appear.
  • the virtual machine also manages the processing that serves up desktop images to the corresponding client, which are rendered by the client as they are received.
  • the client interacts with the displayed desktop image
  • that client input is transmitted to the centralized desktop location.
  • the corresponding virtual machine at the centralized desktop location interprets the client input, and processes the desktop.
  • the virtual machine changes the state of the desktop if appropriate. If this changed state results in a change in how the desktop appears, the virtual machine constructs a different desktop image, and causes the centralized desktop location to transmit the altered desktop image to the client. From the user's perspective, this occurs often fast enough that the displayed desktop at the client is substantially immediately responsive to the user input at the client.
  • the desktop as is exists on the centralized desktop location is often referred to as a "virtual desktop", and the application-level logic on the centralized desktop that is used to process the desktop is often referred to a "virtual machine”.
  • the centralized desktop location may manage a number of virtual desktops for a corresponding number of clients. In some cases, the centralized desktop location may manage hundreds of virtual desktops. In some cases, the centralized desktop location is a physical machine, which is referred to herein as a "physical appliance".
  • the physical appliance provides software and data support (hereinafter referred to as the "support resources") to the virtual machine(s). For instance, the operating system and certain applications may be provided by the physical appliance. Supporting data may also be included within the support resources. For instance, user data (such as persistent preference information) may also be stored by the physical appliance.
  • All of the software and data support resources are conventionally located on the physical machine itself.
  • An alternative conventional solution occurs when an organization has multiple physical appliances. To provide backup, the organization will provide access to a storage area network (SAN) to multiple physical appliances, and store the software and data support resources on the SAN. If a failure were to occur with a physical appliance, the support resources are still available on the SAN from the other physical appliance. Thus, an instance of the physical machine may be constructed on the other physical appliance, and mapped to the corresponding software and data storage resources on the SAN, thereby effecting recovery.
  • SAN storage area network
  • At least one embodiment described herein relates to the migration of a pool of virtual machines from a source physical support environment to a target physical support environment.
  • the source physical support environment operates a pool of virtual machines.
  • the virtual machines were all provisioned into an initial state using a source master image. Thereafter, at least some user changes to the state were reflected in corresponding user delta collections for each of the virtual machines.
  • a pool is allocated on the target physical support environment. This allocation may be performed before the migration is determined to occur in a pre-allocation embodiment, or may be performed after the migration is determined to occur in a dynamic pool allocation embodiment.
  • the target pool is associated with a target master image.
  • the virtual machines in the source pool may be disconnected from the user delta collections to avoid corruption of the user delta collections.
  • the virtual machines are provisioned within the target pool based on the target master image.
  • the virtual machines in the target pool are then connected to the corresponding user delta collection.
  • Figure 2 illustrates a virtual machine environment that includes a single physical support environment supporting multiple virtual machines
  • Figure 3 illustrates a virtual machine in conjunction with internal and external soft support resources
  • Figure 4A illustrates an initial state of a network environment in the case of a dynamic allocation embodiment in which the target pool is not allocated until after a decision on migration;
  • Figure 4B illustrates a state of the network environment in the case of a dynamic allocation embodiment in which the target pool is allocated and associated with a target master image, or shows an initial state of the network environment in the case of a pre-allocation embodiment in which the target pool is already established at the time of the migration decision;
  • Figure 4C illustrates a state of the network environment after the target virtual machines are provisioned
  • Figure 4D illustrates a state of the network environment after the user delta collections are unlocked to the corresponding target virtual machines
  • Figure 5 illustrates a flowchart of a method for setting up the source virtual machines at the source physical support environment
  • Figure 6 illustrates a flowchart of a method for operating a source virtual machine after the virtual machine is provisioned in the source physical support environment
  • Figure 7 illustrates a flowchart of a method for migrating source virtual machines from a source physical support environment to a target physical support environment
  • Figure 8 illustrates a network environment in which two source pools are migrated from a single source physical support environment to a single target physical support environment
  • Figure 9 illustrates a network environment in which two source pools are migrated from different source physical support environment to a single target physical support environment; and Figure 10 illustrates a more complex network environment in which a target physical support environment serves as a migration backup support for a number of source physical support environments.
  • migration of a pool of virtual machines to a target physical support environment is described.
  • the virtual machines were all provisioned into an initial state using a source master image. Thereafter, at least some user changes to the state were reflected in corresponding user delta collections for each of the virtual machines.
  • a pool is allocated on the target physical support environment.
  • the target pool is associated with a target master image as the source pool.
  • the virtual machines are provisioned within the target pool based on the target master image.
  • the virtual machines in the target pool are then connected to the corresponding user delta collection.
  • the target physical support environment may be a master service provider.
  • Computing systems are now increasingly taking a wide variety of forms.
  • Computing systems may, for example, be hand-held devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, or even devices that have not conventionally been considered a computing system.
  • the term "computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by the processor.
  • the memory may take any form and may depend on the nature and form of the computing system.
  • a computing system may be distributed over a network environment and may include multiple constituent computing systems.
  • the memory 100 typically includes at least one processing unit 102 and memory 104.
  • the memory 104 may be physical system memory, which may be volatile, non- volatile, or some combination of the two.
  • the term “memory” may also be used herein to refer to non- volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.
  • the term “module” or “component” can refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads).
  • embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions.
  • An example of such an operation involves the manipulation of data.
  • the computer-executable instructions (and the manipulated data) may be stored in the memory 104 of the computing system 100.
  • Computing system 100 may also contain communication channels 108 that allow the computing system 100 to communicate with other message processors over, for example, network 110.
  • Computer storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
  • a "network" is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium.
  • Transmissions media can include a network and/or data links which can be used to carry or desired program code means in the form of computer- executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
  • Figure 2 illustrates a virtual machine operation environment 200.
  • the operation environment includes a physical support environment 201 in which a set of virtual machines 210 operate.
  • the physical support environment 201 may be, for example, the computing system 100 of Figure 1, or any other device, system, or combination thereof that is capable of providing physical resources to assist in the operation of virtual machines.
  • the physical support environment 201 may be a centralized location that manages many virtual machines.
  • Each virtual machine manages state (e.g., a desktop state) for a corresponding client that may perhaps be remotely located.
  • the virtual machine provides an image representing a desktop image to the corresponding client, and alters the image or other desktop state in response to detected events, such as, for example, a user interfacing with the current desktop image.
  • the corresponding virtual machine interprets the client input, and processes the client input. In response to this input, or in response to some other detected event, the virtual machine changes the state of the virtual desktop if appropriate. If this changed state results in a change in how the desktop appears, the virtual machine constructs and transmits another desktop image to the client. From the user's perspective, this occurs often fast enough that the displayed desktop is substantially immediately responsive to the user input.
  • Each virtual machine needs resources in order to operate properly.
  • the physical support environment 201 provides a variety of support resources for each of the virtual machines 210.
  • some of that support includes hard (physical) support resources such as processing resources, memory resources, storage resources, network access resources, and the like.
  • each virtual machine also uses soft support resources, such as software and data.
  • soft support resources such as software and data.
  • the virtual machine may use an operating system, one or more applications, and/or one or more other software modules.
  • the physical support environment 201 may host some or all of data that is used by the virtual machine in order to operate, such as user preference data, and other application state.
  • the "soft" support resources are so named because the resources (such as software and data) are capable of being copied from one location to another, or accessed remotely over a network.
  • Figure 4A illustrates a network environment 400A that includes a source physical support environment 410 and a target physical support environment 420.
  • Figures 4B through 4D describe different states of this network environment 400A.
  • the network environment 400A of Figure 4A will be described in further detail.
  • the source physical support environment 410 includes a pool 411 that contains a number of virtual machines 412 A, 412B and 412C.
  • the ellipses 412D represent that there may be any number of virtual machines operating within the pool 411. For instance, there may be tens, hundreds, or even thousands of virtual machines running in the pool.
  • the virtual machines 412A, 412B, 412C and 412D may be referred to hereinafter collectively as "virtual machines 412".
  • the term "source” may be used to modify elements that operate within the source physical support environment 410.
  • the virtual machines 412 may also be referred to as “source virtual machines 412”
  • the pool 411 may also be referred to as a "source pool 411"
  • the source physical support environment 410 is modified by the term "source” because in this example, the environment 410 is the source of the migration. However, that is not to say that the source physical support environment 410 might not be a target of migration in other contexts.
  • the physical support environment 420 is also provided, and is a target for the migration of the source virtual machines 412 in this example. Accordingly, for purposes of this example, the physical support environment 420 is modified with the term "target”. Furthermore, throughout this description, elements that operate within the target physical support environment 420 may also be modified with the term "target”.
  • the source physical support environment 410 includes a monitoring agent 413 that monitors the performance of the source physical support environment 410, and reports to the migration decision agent 430.
  • the target physical support environment 420 includes a communication agent 423 that permits communication with a migration decision agent 430.
  • the communication agent 423 may also serve as a monitoring agent and report regarding performance of the target physical support environment to the migration decision agent 430,
  • the migration decision agent 430 determines whether to migrate the source virtual machines 412 to the target physical support environment 420 based on reports from the monitoring agent 413. If the migration decision agent 430 determines that a migration is to occur, the migration decision agent 430 notifies the target physical support environment 420 via the communication agent 423. In one embodiment, the communication agent 423 may also monitor performance of the target physical support environment 420.
  • the source pool 410 is associated with a master image 441 from which each of the source virtual machines 412 is initially provisioned into an initial state.
  • a pool is a pool that is capable of instantiating multiple virtual machines and provisioning those pools in a common initial state using a master image.
  • the target physical support environment 420 also includes a master image 442.
  • the target master image 442 may be the same as the source master image 441 in the case in which the virtual machines after migration are to mirror the state of the virtual machines before migration. However, there may also be cases in which the target master image 442 may be different than the source master image 441 , in cases in which there are to be differences between the virtual machines before migration and the virtual machines after migration, as described further below.
  • the migration decision agent 430 contains pool information 470 that may be used to allocate a target pool on the target physical support environment 420. Alternatively, the pool information 470 may be located elsewhere or distributed across multiple components.
  • the source physical support environment 410 and the target physical support environment have shared storage 450.
  • the shared storage 450 may be a single storage device, or may be multiple storage devices in the case of a Storage Area Network.
  • the shared storage may also be multiple storage devices located in a large area network in which case data may be replicated across storage nodes in that large area network.
  • both the source physical support environment 410 and the target physical support environment 420 have access to the user delta collections 461.
  • the master images 441 and 442 may likewise be at least partially stored within the shared storage 450 although not required.
  • Each user delta collection captures perhaps all, but at least some, changes to state of the corresponding source virtual machine made by the user since the corresponding source virtual machine was initially provisioned within the source pool 411.
  • the corresponding user delta collections are exclusively available to the corresponding source virtual machine, and locked to other components. This exclusive lock is represented collectively for all source virtual machines by connection 481.
  • the user delta collections represent examples of the external soft support resources described above with respect to Figure 3, as the user delta collections are not kept on the source physical support environment 410, but rather are kept externally in the shared storage 450.
  • the user delta collections may each be the corresponding user data disk associated with their corresponding source virtual machine.
  • Figure 5 illustrates a flowchart of a method 500 for setting up the source virtual machines at the source physical support environment 410.
  • the method 500 will be described with frequent reference to the network environment 400A of Figure 4A.
  • the source pool is allocated (act 501) on the source physical support environment.
  • the source pool 411 is allocated on the source physical support environment 410.
  • This allocation involves instantiating an instance of a pool and configuring the pool. For instance, resources may be made available to the pool, and a number of supportable virtual machines may be identified. For instance, the pool may be configured to operate up to a certain number (e.g., perhaps 100) of virtual machines.
  • Figure 6 illustrates a flowchart of a method 600 for operating a source virtual machine after the virtual machine is provisioned in the source physical support environment.
  • the method 600 may be performed independently for each source virtual machine 412 in the source pool 411 to generate a different state represented in the corresponding user delta collection.
  • Each source virtual machine initially begins operation in the initial state (act 601) since they were each provisioned into that initial state. Then, as the source virtual machine continues operation (act 602), if there is not a state change caused by the user (No in decision block 603), then the source virtual machine continues operation (act 602) without updating the corresponding user delta collection. However, as the source virtual machine operates (act 602), the user may cause a change in the virtual machine state ("Yes" in decision block 603). In at least some, and perhaps all, of those occasions, the corresponding user delta collection is updated (act 604). For instance, in the case of a change in state of source virtual machine 412A, the user delta collection 461 A is updated. In the case of a change in state of source virtual machine 412B, the user delta collection 46 IB is updated, and so forth for all other source virtual machines.
  • Figure 7 illustrates a flowchart of a method 700 for migrating source virtual machines from a source physical support environment to a target physical support environment.
  • the method 700 includes detecting that source virtual machines that operate in a source physical support environment are to be migrated from the source physical support environment (act 701). In the embodiment of Figure 4A, this detection is made by migration decision agent 430, which determines whether or not to migrate based on information received from the monitoring agent 413. If migration is to occur, the migration decision agent 430 informs the communication agent 423 of the same.
  • the decision to migrate may be based on, for example, any number of factors without departing from the more general principles described herein. Several examples of such factors will be described in this paragraph.
  • the decision may be based on any one of such factors, or on a combination of factors, although the principles described herein are not limited to these factors nor does the decision require consideration of any of these factors.
  • the decision may be based at least in part upon deterioration of performance or perhaps even cessation of all operation of the source physical support environment 410.
  • the decision may also be based at least in part upon movement of the user to a location that is more remote from the source physical support environment 410.
  • the decision may also be based at least in part upon the resource usage of the source physical support environment 410, or upon load balancing considerations comparing the resource usage of the physical support environment 410 to other physical support environments.
  • the decision might also be based at least in part upon user preferences or instructions.
  • the decision might also be based at least in part upon some type of migration policy.
  • the target physical support environment allocates a target pool (act 703) on a target physical support environment.
  • Figure 4B illustrates a state 400B of the network environment of Figure 4A after the target pool 421 is established.
  • a target pool 421 is allocated within the target physical support environment 420.
  • the target pool 421 is associated (act 704) with the target master image 442.
  • the target pool 421 matches the source pool 411.
  • the target pool 421 does not match the source pool 411.
  • the pools may be non-matching in the sense that the number of virtual machines they support may be different.
  • the target pool 421 is large enough and has enough resources to serve as a target for migration of several source pools including the source pool 411.
  • the source pool 411 is larger than the target pool 421 such that the source virtual machines from the source pool 411 are divided amongst several target pools including the target pool.
  • the pools might be non-matching in the sense that they assign slightly different virtualized hardware to the virtual machine.
  • source virtual machine 412 A runs a virtualized processor of one type as assigned by the source pool 411
  • target virtual machine 422A runs a virtualized processor of a different type as assigned by the target pool 412.
  • source virtual machine 412 A has more or less Random Access Memory (RAM) as assigned by the source pool 411 as compared to the RAM assigned to the target virtual machine 422A as assigned by the target pool 421.
  • RAM Random Access Memory
  • the difference may be caused by an administrator setting policy
  • the establishment of the target pool (acts 703 and 704) are shown in parallel with the migration decision (act 701) because the target pool may be established before or after the migration.
  • the target pool is established (acts 703 and 704) after the decision to migrate (act 701).
  • the migration decision agent 430 uses the pool information 470 to establish the target pool 421 of Figure 4B.
  • the decision to migrate occurs while the network environment has the state 400A of Figure 4A.
  • the target pool is established (acts 703 and 704) before the decision to migrate (act 701).
  • the decision to migrate occurs while the network environment has the state 400B of Figure 4B.
  • the state 400B of Figure 4B has been achieved.
  • FIG. 4C illustrates a state 400C of the network environment after the target virtual machines have been provisioned.
  • the target virtual machines 422A, 422B, 422C were provisioned within the target pool 421 using the target master image 442.
  • Each of the target virtual machines 422 corresponds to a respective one of the source virtual machines 412.
  • target virtual machine 422A corresponds to source virtual machine 412A
  • target virtual machine 422B corresponds to source virtual machine 412B
  • target virtual machine 422C corresponds to source virtual machine 412C
  • so forth as represented by ellipses 422D for additional virtual machines if there are other source virtual machines as represented by ellipses 412D.
  • migration of source virtual machine 412 A to target physical support environment 420 occurs by instantiating a corresponding target virtual machine 422A, placing that virtual machine 422A in the same state as the source virtual machine 412A was at the time of migration, and making that new target virtual machine 422 A available to the user of the source virtual machine 412A. From the user's perspective, the migration may even be transparent.
  • the migration decision agent 430 may even be a connection broker that channels client communications that previously went to the source virtual machine 412 A instead to the target virtual machine 422A. The same may be said of target virtual machine 422B with respect to the corresponding source virtual machine 412B, and the target virtual machine 422C with respect to the corresponding source virtual machine 412C.
  • the target virtual machines are only at this point provisioned into an initial state based on the master image (act 705).
  • the act of provisioning may be performed by configuring the target pool 421 such that when the target pool 421 is enabled, the corresponding target virtual machines are automatically provisioned.
  • FIG 4D illustrates a state 400D of the network connection after the user delta collections 461 have been unlocked to the target virtual machines 422 as represented by the connection 482.
  • target virtual machine 422A now has access to the user delta collection 461 A, and thus now has the same state as the source virtual machine 412A had at the time of the migration.
  • target virtual machine 422B now has access to the user delta collection 46 IB, and thus now has the same state as the source virtual machine 412B had at the time of the migration.
  • target virtual machine 422C now has access to the user delta collection 461B, and thus now has the same state as the source virtual machine 412B had at the time of the migration.
  • the target virtual machines 422 may continue operating (act 707) in the manner described with respect to Figure 6 by continuing to make changes to the respective user delta collection, and interacting with the client.
  • the target pool 421 may be made to match the source pool 411 as in the case of the matching pool embodiments.
  • match means one of more of the following: 1) the target pool has the same hardware resources as the source pool, 2) the target pool has the same operating system as the source pool, 3) the target pool has the same configuration as the source pool, and/or 4) the target pool has the same number of virtual machines allocated in the target pool as there were allocated in the source pool.
  • the pool information 470 may contain sufficient information regarding the source pool 411 to allow the target physical support system 420 to set up such a matching target pool 421.
  • the target master image 442 may be different than the source master image 441.
  • the target master image 442 may have a different (perhaps upgraded) operating system as compared to the source master image 441.
  • the target master image 442 may have additional, removed, and/or upgraded applications as compared to the source master image 441.
  • the virtual machines may be migrated and upgraded at the same time. In this case, the decision to migrate may be based on an additional possible factor that the virtual machine instance is to be upgraded.
  • Figures 4A through 4D illustrated a circumstance in which a single pool is migrated from a source physical support environment to a target physical support environment using a single application of the method 700 of Figure 7.
  • the method 700 may be performed multiple times to facilitate multiple migration operation of multiple pools.
  • Figure 8 illustrates a network environment 800 that is similar to the network environment of Figures 4A through 4D in that the method 700 is applied to cause source pool 411 (having master image 441) having source virtual machines 412 to be migrated from the source physical support environment 410 to the target physical support environment 420 to form target pool 421 (having master image 442) having target virtual machines 422.
  • the method 700 may be applied again to migrate the source pool 811 having a different master image 841 to the target pool 821 having master image 842.
  • the target master image 842 may be the same as or different than the source master image 841.
  • the target virtual machine 822A may be set up to have the same state as the source virtual machine 812A
  • target virtual machine 822B may be set up to have the same state as the source virtual machine 812B
  • target virtual machine 822C may be set up to have the same state as the source virtual machine 812C
  • so forth as represented by ellipses 812D and 822D the target pool 421 may match the source pool 411
  • the target pool 821 may match the source pool 811.
  • the target pools 421 and 821 may be a single larger target pool, and the virtual machines from each source pool 411 and 811 are consolidated into that larger target pool.
  • the source pools 411 and 811 may a single source pool, and a portion of the source virtual pool set may be migrated to each of the target pools 421 and 821.
  • the target master image 842 may be different from the source master image 841 in cases in which the target virtual machines are to have different and/or upgraded operating systems and/or applications available after migration.
  • Figure 9 illustrates a network environment 900 that is similar to the network environment of Figures 4A through 4D in that the method 700 is applied to cause source pool 411 (having master image 441) having source virtual machines 412 to be migrated from the source physical support environment 410 (referenced in Figure 9 as "Source A") to the target physical support environment 420 to form target pool 421 (having master image 442) having target virtual machines 422.
  • the method 700 may be applied again to migrate the source pool 911 having a master image 941 and on a different source physical support environment 910 (reference in Figure 9 as "Source B") to the target pool 921 having the master image 942 on the target physical support environment 420.
  • the target master image 942 may be the same as or different than the source master image 941.
  • the target virtual machine 922A may be set up to have the same state as the source virtual machine 912 A
  • target virtual machine 922B may be set up to have the same state as the source virtual machine 912B
  • target virtual machine 922C may be set up to have the same state as the source virtual machine 912C
  • so forth as represented by ellipses 912D and 922D The source physical support environment 910 has a monitoring agent 913 which notifies the migration decision agent 430 about the performance of the source physical support environment 910.
  • the target pool 421 may match the source pool 411, whereas the target pool 921 may match the source pool 911.
  • the target pools 421 and 921 may be a single larger target pool, and the virtual machines from each source pool 411 and 911 are consolidated into that larger target pool.
  • the target master image 942 may be different from the source master image 941 in cases in which the target virtual machines are to have different and/or upgraded operating systems and/or applications available after migration.
  • Figure 10 illustrates a more complex network environment 1000.
  • the target physical support environment 1080 acts as a master service provider that provides migration backup services to multiple source physical support environments.
  • the supported source physical support environments are illustrated as including five physical support environments 1001 through 1005, although the ellipses 1006 represents that the target physical support environment 1080 may serve additional physical support environments as well.
  • the master service provider may serve as a migration backup service to hundreds, or even thousands, of source physical support environments.
  • the target physical support environment 1080 may support a different number of pools.
  • the target physical support environment 1080 may support migration backup services for pools 1011 and 1012 on source 1001 , pool 1021 on source 1002, pools 1031, 1032 and 1033 on source 1003, pool 1041 on source 1004, and pools 1051 and 1052 on source 1005.
  • the target physical support environment 1080 has enough storage access to be able to store each corresponding master image for each supported pool.
  • the target 1080 either stores the pool information (in the dynamic allocation embodiment), or allocates a pool (in the pre-allocation embodiment) for each of the supported pools.
  • the supported pools are only migrated in a limited set of circumstances such as reduced performance or cessation of operation of the corresponding source. Accordingly, not all of the supported pools are going to be migrated onto the target 1080. Accordingly, the target 1080 does not need to have enough processing power to perform operate all of the virtual machines supported by each of the supported pools. For instance, perhaps the target 1080 is only capable of operating virtual machines from a limited number of pools (three in the illustrated example) at a given time. This capability is represented by elements 1091, 1092 and 1093. However, having this lesser processing capability may be well more than enough to guaranty the migration backup services for a larger number of supported pools since a limited number of the supported pools are going to actually be migrated. Furthermore, since such migration does not occur all at one time for all supported pools, there is likely suitable time to augment the target 1080 with additional processing capability if needed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention porte sur la migration d'un groupement de machines virtuelles vers une machine physique cible. Les machines virtuelles ont toutes été provisionnées dans un état initial à l'aide d'une image maître. Ensuite, des modifications apportées à l'état ont été reflétées dans des collections delta d'utilisateur correspondantes pour chacune des machines virtuelles. En préparation à la migration vers la machine physique cible, un groupement est attribué sur la machine cible. Le groupement cible est associé à la même image maître que le groupement source. Les machines virtuelles sont provisionnées dans le groupement cible sur la base de l'image maître. Les machines virtuelles dans le groupement cible sont ensuite connectées à la collection delta d'utilisateur correspondante, permettant aux machines virtuelles de continuer dans le même état dans la machine cible que celui dans lequel elles fonctionnaient pendant qu'elles fonctionnaient en dernier dans la machine source. La machine cible peut jouer le rôle de fournisseur de services maître.
PCT/US2012/027007 2011-02-28 2012-02-28 Migration de groupement de machines virtuelles Ceased WO2012118849A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201161447564P 2011-02-28 2011-02-28
US61/447,564 2011-02-28
US13/250,836 2011-09-30
US13/250,836 US9542215B2 (en) 2011-09-30 2011-09-30 Migrating virtual machines from a source physical support environment to a target physical support environment using master image and user delta collections

Publications (1)

Publication Number Publication Date
WO2012118849A1 true WO2012118849A1 (fr) 2012-09-07

Family

ID=45814686

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/027007 Ceased WO2012118849A1 (fr) 2011-02-28 2012-02-28 Migration de groupement de machines virtuelles

Country Status (1)

Country Link
WO (1) WO2012118849A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9483316B2 (en) 2014-05-29 2016-11-01 International Business Machines Corporation Managing a virtual machine instance

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006044701A1 (fr) * 2004-10-15 2006-04-27 Emc Corporation Configuration, controle et/ou gestion de groupes de ressources comprenant une machine virtuelle

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006044701A1 (fr) * 2004-10-15 2006-04-27 Emc Corporation Configuration, controle et/ou gestion de groupes de ressources comprenant une machine virtuelle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KRSUL I ET AL: "VMPlants: Providing and Managing Virtual Machine Execution Environments for Grid Computing", SUPERCOMPUTING, 2004. PROCEEDINGS OF THE ACM/IEEE SC2004 CONFERENCE PITTSBURGH, PA, USA 06-12 NOV. 2004, PISCATAWAY, NJ, USA,IEEE, 6 November 2004 (2004-11-06), pages 7 - 7, XP010780332, ISBN: 978-0-7695-2153-4, DOI: 10.1109/SC.2004.67 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9483316B2 (en) 2014-05-29 2016-11-01 International Business Machines Corporation Managing a virtual machine instance

Similar Documents

Publication Publication Date Title
US9542215B2 (en) Migrating virtual machines from a source physical support environment to a target physical support environment using master image and user delta collections
US20230208914A1 (en) Live Migration Of Clusters In Containerized Environments
US7992032B2 (en) Cluster system and failover method for cluster system
US10374978B2 (en) System and method to uniformly manage operational life cycles and service levels
US11934875B2 (en) Method and system for maintaining composed systems
US9733989B1 (en) Non-disruptive load-balancing of virtual machines between data centers
JP5786037B2 (ja) 仮想計算機の制御方法及び仮想計算機システム
US8924969B2 (en) Virtual machine image write leasing
US9977698B2 (en) Virtual machine migration into the cloud
WO2012039053A1 (fr) Procédé servant à gérer les opérations d'un système informatique, système informatique et programme de mémorisation sur support lisible par un ordinateur
US20250045166A1 (en) Automatic nfv service chain failure recovery due to compute node failures
US8959383B2 (en) Failover estimation using contradiction
US12223359B2 (en) Computational offloads for composed information handling systems
WO2012118849A1 (fr) Migration de groupement de machines virtuelles
US20140059538A1 (en) Virtual machine state tracking using object based storage
WO2012158241A1 (fr) Adaptation automatisée d'une politique de groupe
US12086656B2 (en) Automatic graphics processing unit selection
US12236271B2 (en) Method and system for performing state management services for composed information handling systems
US11704159B2 (en) System and method for unified infrastructure architecture
US20220179699A1 (en) Method and system for composed information handling system reallocations based on priority

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12708220

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12708220

Country of ref document: EP

Kind code of ref document: A1