JP6534399B2 - System and method for live migration of a virtualization network stack - Google Patents

Description

This application is a continuation of US patent application Ser. No. 14 / 310,492 filed Jun. 20, 2014, the disclosure of which is incorporated herein by reference.

Background Live migration is the act of moving a running virtual machine from one host machine to another while maintaining virtual machine connectivity, network connectivity and virtual machine health status reporting. . During migration, performance may be impacted, for example, by pausing the virtual machine to copy memory, or by establishing a connection between the virtual machine and the new host.

SUMMARY One aspect of the present disclosure provides a method of facilitating live migration by a virtualized network device. The method comprises the steps of: sending a packet to the migrating guest on the source host by the virtualization network device; forwarding the packet to the target host by the source host; and transmitting the packet from the migrating guest on the target host via the source host The steps of receiving, determining whether migration of the migration guest from the migration source host to the migration destination host has been completed by the virtualization network device, and virtualizing the packet if it is determined that the migration has been completed Sending directly from the network device to the migrating guest on the target host. The step of determining whether migration of the migration guest has been completed may include, at the virtualization network device, directly receiving one or more packets from the guest on the target host, and based on the received one or more packets. And confirming that the migration is complete.

  Another aspect of the present disclosure provides a system. The system comprises a source host, a migrating guest operating on the source host, a target host communicating with the source host, and other virtualized network devices communicating with the migrating guest on the source host. The source host is configured to forward traffic received from another network device to the target host and forward traffic received from the target host to the other network device. The target host is configured to send packets directly to other network devices upon completion of migration guest migration. The other network device is configured to determine the time of receiving the packet directly from the target host and, in response, to send the packet directly to the migrating guest on the target host. The system further comprises a network controller configured to provide tokens to other virtualized network devices for direct communication with the migrating guest on the target host. In some examples, the migrating guest may be configured to be notified of the transition before initiating the transition and to change its state in response to the notification. For example, a migrating guest can transition to a mode that keeps existing connections and rejects future processing requests. As another example, the migration guest can communicate with another system, which allows another system to direct future processing requests to other resources on the network during the migration.

  Yet another aspect of the present disclosure provides a method. The method includes receiving, by the migrating guest on the source host, an indication from the source host to migrate the migrating guest to the target host. The transition guest takes a predetermined action in response to receiving the instruction. In addition, migration guests are copied from the source to the target. The source host forwards traffic received from another network device to the target host, and forwards traffic received from the target host to the other network device.

FIG. 1 illustrates an exemplary system in accordance with aspects of the present disclosure. FIG. 6 is a block diagram illustrating components of the system of FIG. 1 in accordance with aspects of the present disclosure. FIG. 7 illustrates another exemplary system in accordance with aspects of the present disclosure. FIG. 5 is a block diagram illustrating components of the system of FIG. 3 in accordance with aspects of the present disclosure. FIG. 7 is a flow diagram illustrating an exemplary method in accordance with an aspect of the present disclosure. FIG. 7 is a flow diagram illustrating another exemplary method according to aspects of the present disclosure.

DETAILED DESCRIPTION Overview The present disclosure provides systems and methods for live migration of a virtualization network stack.

  Live migration provides migration without disrupting network connectivity between the first virtualized or non-virtualized network computing device and the virtual network stack being migrated. The first virtualized or non-virtualized network computing device may be a virtual machine, a switch, a host, or any network device. The virtual network stack may be a virtual machine, a Linux® container, or another type of virtual network stack. In the following example, the first virtualized or non-virtualized network computing device is called a first device, and the virtual network stack to be migrated is called a virtual machine. It should be understood that these examples are not limiting. Furthermore, it should be understood that these examples are merely exemplary, and the concepts described may be applied to various scenarios. For example, the plurality of first devices can communicate with the virtual machine to be migrated using the techniques described below.

  The first device communicates with a virtual machine located on the source host. The first device continuously communicates with the virtual machine on the source host during migration. Until migration is complete, the source virtual machine and the target virtual machine transfer (for example, bidirectional transfer or one-way transfer) temporarily stored traffic. For example, the source virtual machine temporarily stores all incoming traffic from the first device and forwards the stored traffic to the target virtual machine. The target virtual machine is configured to accept temporarily stored input traffic as well as temporarily store all outgoing traffic through the source virtual machine. Such bi-directional transfer can be performed continuously from the point of transition of the virtual machine from the source to the target until the associated node on the network is reprogrammed. The centralized virtual network programming controller notifies the first device that the virtual machine has been migrated to the target host, so that the first device can resume communication with the virtual machine on the target host . In addition, the controller can also notify other machines in the network of the change.

  According to one example, the "other" virtual machine (VM) communicates temporarily with both the controller and the target host, temporarily storing all traffic at the source, instead of or in addition to doing bi-directional forwarding. , To facilitate seamless transition. For example, the target VM host subscribes for network updates by communicating with the controller. The controller provides the token for communicating directly with the virtual machine on the target host to another VM. Other virtual machines, source hosts and target hosts can perform three-way routing, for example, from when the virtual machines are migrated to the target host until the network is updated. For example, another virtual machine sends traffic to the source VM host until it receives an incoming packet from the target VM host, and this traffic is forwarded to the target VM host. At this point, other virtual machines use the token received from the controller to authenticate and specify the delivery path to send packets directly to the virtual machine on the target host. As another example, if another VM host receives a packet from an unrecognized source, it queries the controller so that it can switch to send the packet directly to the target virtual machine.

  In any of the above examples, to support smooth migration from source host to target host, install one or more rules on the network device, for example on the source and / or host of the "other" virtual machine be able to. These rules may, for example, be installed by the controller. The rules are specific stages of migration, eg brownout (ie transition destination started and state of virtual machine transition from source host to target host), blackout (ie VM restart on target To suspend the virtual machine and move the remaining VM state from source to target), post blackout (ie, the transition is complete and the target does all processing) And cancellation (i.e., a state in which all settings related to migration are deleted) can be provided.

  During brownout, the virtual machine is located on the source host. The migration source can transmit and receive traffic to and from other virtual machines (VMs). Also, any other virtual machine can also receive traffic from the source, but can only send traffic to the source. Similarly, the controller modifies the forwarding table of the migration source, and installs the migration table on the migration source to forward traffic. Both the source host and the target host have host agent processes running locally or host agent processes running as part of a virtual machine manager process that assists in reprogramming the network. The source host agent can be activated to switch forwarding of traffic from local forwarding to the destination.

  During blackout, all network states that need to move from source to target (eg, stateful firewall state) are migrated. Only the source host agent is involved in switching. The controller does not have to do anything. In some implementations, switching may occur at the beginning of the blackout period. In other implementations, traffic is not forwarded until it becomes post-blackout, in preparation for cancellation of the transition before or during blackout.

  During post blackout, the controller provides a route that points to the destination. In addition, traffic from the source continues to be forwarded to the destination. For example, the source host and target host can perform bi-directional forwarding, uni-directional forwarding, or three-way routing. As a result, most flows on the migration source are uninstalled except for the migration transfer flow. Furthermore, in the case of three-way routing, in contrast to forwarding traffic through the source host, responses from the destination are sent directly to the first device, which is a virtual machine on the target host. Can communicate directly with.

  Cancellation takes place when canceling the transition. For example, during a blackout or blackout period, the migration may be canceled by the target host crashing or encountering other events. During cancellation, the controller deletes all flows set for migration. For example, the rules on the first device that enable the first device to receive packets from either the source host or the target host are reprogrammed to support only the rules corresponding to the source. All network programs on the target host are deleted, and all programs associated with the transfer on the source host are also deleted.

  According to some examples, the blackout period can be reduced by starting execution on the target before all virtual machine states are transferred. For example, during the brownout phase, the state of the virtual machine may be pre-copied, and during the subsequent blackout the task execution of the virtual machine may be transferred to the target host and the remaining state may or may not be transferred. May be Also, after blackout, a post copy brownout stage may be provided to copy the remaining state.

  One aspect of the present disclosure can allow guest virtual machines to take action by exposing an impending live migration to the guest virtual machines. One such action is to change the health state of the guest virtual machine prior to migration. For example, a guest virtual machine can transition to the "lame duck" state. In this state, the guest virtual machine communicates with other systems to complete tasks already in progress but not accept new tasks or connections. Thus, guest virtual machines can, for example, remove themselves from the load balancing pool and keep existing connections. This facilitates load balancing across the network and can be particularly useful for blackout delay sensitive customers such as online gaming systems.

Exemplary System FIG. 1 shows an exemplary system 100 for migrating an operating guest from a source host to a target host. As shown, network computing device 120, source host 130, and target host 160 are components of network 150. The network further includes a network controller 180 in communication with one or more devices in the network 150.

  Network 150 may be a data center including a backplane for interconnecting peripheral devices or various system elements provided on a motherboard, a load balancing server farm, or any other type of computing environment . Network 150 and intervening nodes include various configurations and protocols. As the protocol, Internet, World Wide Web, Intranet, Virtual Private Network, Wide Area Network, Local Network, Private Network using communication protocol unique to one or more companies, Ethernet (802.11, 802) .11b, g, n, or other standard) WiFi® and HTTP, and various combinations of the above.

  Network controller 180 may be connected directly or indirectly to each node of network 150, and may be used to establish a connection between the nodes or to provide information to a particular node. For example, network controller 180 can be used to provide network updates to facilitate the transfer of information from one node to another. In some examples, network controller 180 may store and process information regarding the topology of network 150 or the topology of each of the various other networks that may be connected to network 150. The network controller 180 may be, for example, a conventional network interface controller (NIC) or a dedicated network interface controller. The NIC may be implemented in the network or connected to the network via, for example, an expansion card, a motherboard, an Ethernet chip or other media.

  Network computing device 120 may be a virtualized computing device or may be a non-virtualized computing device. For example, network computing device 120 may be a central processing unit (CPU), a virtual machine, a Linux container, a router, a switch, or any network device capable of sending and receiving packets. Network computing device 120 may communicate with source host 130 and guests 110 by, for example, wired or wireless connections.

  Source host 130 may be any type of computing device or system capable of hosting guest 110. For example, source host 130 may include a hypervisor (not shown) on which one or more virtual machines or other guests are operating. Although only guests 110 are shown in FIG. 1, it should be understood that multiple guests may operate on the source host 130 at any time. In some examples, source host 130 may be virtualized, for example, in a nested virtualization environment. For example, the source host 130 may be a virtual machine, a Linux container, or the like.

  Similar to source host 130, target host 160 may be any type of computing device capable of hosting guest 110. In some examples, the target host may be virtualized.

  The target host 160 communicates with a virtual machine manager (VMM) on the source host 130 to initiate a live migration. For example, VMM tasks can be initiated on target host 160. Such tasks may communicate with the VMM on the source host 130, eg, perform authentication. Thereafter, a blackout phase may be initiated to transfer guest 110 specifications and status from source host 130 to target host 160.

  According to some examples, guest 110 may take predetermined actions in response to being informed (eg, by target 160 or source 130) about the impending transition. An example of such an action is to change the condition, eg normality condition. For example, the guest 110 can transition to a “lame duck” state, which can be recognized in addition to other states such as a normal state or an abnormal state. In the lame duck state, the guest 110 can keep existing connections and remove itself from the load balancing pool. For example, the guest 110 can complete pending tasks but does not accept new tasks.

  When moving guest 110 to target host 160, communication between network computing device 120 and guest 110 may be maintained, for example, via source host 130. Source host 130 may function, for example, as a bi-directional transfer agent between network computing device 120 and target host 160. The target host 160 is configured to receive incoming traffic temporarily stored from the guest 110 on the source 130 and temporarily store outgoing traffic via the source 130.

  Once migration is complete, at least one of the target 160 and the source 130 can notify the network controller 180. Network controller 180 may then change the physical host IP address of guest 110 to correspond to the new location on target 160. Thus, clients wishing to communicate with the guest 110 can send packets to the appropriate physical host machine. Further, in some examples, network controller 180 can notify network computing device 120 and other computing devices in network 150 of a change in location of guest 110. For example, controller 180 can provide the new address of guest 110 to the network device. This allows network computing device 120 and other devices to resume direct communication with guest 110 on target host 160.

  Once the network device 120 begins to communicate with the guest 110 on the target 160, the source 130 may end and the target 160 may discard the inbound transfer configuration and the outbound transfer configuration. For example, transfer rules on source 130 and target 160 may be deleted. According to an example, source 130 and target 160 may wait for a predetermined amount of time, for example, one minute, after the traffic transferred through source 130 decreases to zero before deleting the transfer rule. This waiting time can be adapted to variations in timing of updating the network device with the new address of the guest 110 on the target 160. According to another example, a feedback based mechanism is used. Specifically, the transfer is stopped only when it is clearly understood that all clients have been notified of the change for the target 160.

  FIG. 2 is a block diagram illustrating certain components of system 100 including source 130 and controller 180.

  Source 130 includes memory 132 and one or more processors 139 in communication with memory 132. Memory 132 stores information accessible by processor 139. The information includes instructions 138 executable by processor 139. The memory further includes data 134. The processor can retrieve, manipulate or store these data. The memory may be any type capable of storing information accessible by the processor, such as a hard drive, memory card, ROM, RAM, DVD, CD-ROM, writable memory, and read only memory. May be

  Processor 139 may be any conventional processor, such as a commercially available central processing unit (CPU) or a graphics processing unit (GPU). Alternatively, the processor may be a dedicated part, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other hardware based processor. As another example, processor 139 may be a quantum computer.

  Memory 132 includes data 134 that may be retrieved, manipulated or stored by the processor in accordance with instructions 138. Systems and methods are not limited by the specific data structures. For example, data may be stored in computer registers, and may be stored in a relational database as a table with a plurality of different fields and records, or XML documents. The data may be formatted into a computer readable format, including but not limited to, binary values, ASCII or Unicode. Further, data 134 may be information, such as a number sufficient to identify related information, descriptive text, a special purpose code, pointers or references to data stored in other memories (including other network locations), or related information It can contain information used by the function to calculate data.

  The instructions 138 may be any set of instructions (eg, machine code) executed directly by the processor 139 or any set of instructions (eg, script) executed indirectly. Thus, the terms "instructions", "steps" and "programs" may be used interchangeably herein. These instructions may be stored in object code form for direct processing by a processor, or other computer language including a collection of scripts or independent source code modules which may be translated or precompiled as required May be stored.

  Instructions 138 may be executed by the processor to receive, for example, information related to guest migration from the migration destination. In some instances, a guest can take action in response to receiving information. For example, the guest 110 can update its own state by changing its state of health to a "lame duck" state. In the "Rim Duck" state, the guest can complete the pending task without accepting the new task. The instructions 138 may further define the processing of bi-directional transfer between the network device 120 and the target 160. For example, data 134 may be received from the network device 120 to be migrated and for processing traffic forwarded to the migration guest 110, and for processing traffic received from the target 160 and forwarded to the network device 120. Can include a flow table having one or more forwarding rules. Instruction 138 may further specify cancellation of the connection after the transition is complete. For example, the source 130 may wait at a predetermined time until traffic is low after migration is complete, and then remove the bi-directional forwarding rule from the flow table. As another example, after verifying that all network devices communicating with the migrated guest 110 have been switched to communicate with the target 160, the forwarding rules provided on the source 130 are canceled May be

  Although FIG. 2 functionally illustrates that processor 139 and memory 132 are in the same block, it should be understood that processor and memory are actually stored in the same physical housing Or multiple processors and memories not stored may be included. For example, some of the instructions and data may be stored on a removable CD-ROM, and others may be stored on a read-only computer chip. Some or all of the instructions and data may be physically separated from processor 139 and stored at a location accessible by processor 139. Similarly, processor 139 may actually include a collection of processors that operate or do not operate in parallel. In some examples, memory 132 and / or one or more processors 139 may be part of a hypervisor.

  Similar to source 130, controller 180 includes memory 182 and one or more processors 189. The one or more processors 189 may take any of the forms described above in connection with the source processor 139. Memory 182 includes data 184 and instructions 188. Memory 182 may be of any type and may include any of the functions described above in connection with source memory 132. Instruction 188 specifies detection of live migration completion and updating of the guest's address on the target host. Detecting the completion of live migration may include, for example, receiving a notification from one of source 130 and target 160 indicating that migration is complete. Updating the address can include programming the targets and sources to prepare for the transition, and programming the remaining networks to recognize the sources and targets. The instructions 188 may provide for notifying other network devices, such as the network device 120, that live migration is complete. The notification can include providing the network device with the updated address of the guest on the target.

  FIG. 3 shows another exemplary system 300. Similar to system 100 of FIG. 1, system 300 can include multiple connected network elements, eg, source 330, target 360 and controller 380. Source 330, target 360 and controller 380 may be similar to source 130, target 160 and controller 180 described above in connection with FIGS.

  System 300 may further include “other” guests 325. The “other” guest 325 resides on the “other” host 320 and is communicatively connected to the source 330, the target 360 and the controller 380. As mentioned above, other hosts 320 may perform three-way routing with source 330 and target 360. This three-way routing can be performed, for example, instead of or in addition to the bidirectional transfer described in FIG. 1 above. Like the source and target hosts, other hosts may be any type of virtualized or non-virtualized network device. Although only one other host and one other guest are shown, multiple other hosts and multiple guests can also be implemented.

  In this example, the target host 360 communicates with the controller 380, for example via the illustrated communication 342, to apply for a network update. The controller provides the other host 320 with the token indicated in the illustrated communication 346 in response to the lookup request 344. This token may be utilized to communicate directly with the guest 310 on the target host 360.

  Although the example of FIG. 3 illustrates issuing a lookup request 344, in another example, the flow for communicating with the migration guest 310 on the target host 360 is made to another host before performing transfer. You can push it. For example, flows can be pushed to other hosts during brown out and / or black out.

  The other guest 325 sends traffic 352 to the source host 330, and the sent traffic is forwarded to the target host 360 as indicated by communication 354. Source host 330 continues to forward traffic 354 until another guest 325 receives an incoming packet (shown at 356) from target host 360. When the other guest 325 receives the packet 356 from the guest 310 on the target host 360, it initiates direct communication with the guest 310 on the target 360, as represented by communication 358. For example, the other host 320 uses the token received from the controller 380 to authenticate and designate the delivery path from the other guest 325 to the guest 310 on the target host 360. This allows other guests 325 to "learn" the new location of guest 310 and automatically communicate directly with guest 310 on target 360 after receiving the first incoming packet from guest 310 on target 360. Can be switched.

  FIG. 4 is an exemplary block diagram illustrating another guest 320. As mentioned above, the other guest 325 may be a virtual machine or any virtualized network element. Other guests 320 can operate on a hypervisor residing on any host device in the network.

  Other guests 325 include memory 422, which includes data 424 and instructions 428, and one or more processors 429. These components may be similar to the memory and processor described above in connection with FIG. Instructions 428 may specify the receipt of a token to communicate with the guest on the target host, the sending of traffic to the guest on the source host, and the detection of incoming packets from the guest on the target host. When an incoming packet is detected, instruction 428 uses the received token to authenticate and designate an outgoing path, and sends the packet directly to the guest on the target host along the specified outgoing path. It can be further defined.

Exemplary Method FIG. 5 provides an exemplary flow diagram illustrating a method 500 for live transitioning a virtualization network stack from a source to a target. It should be understood that the operations involved in the following method do not have to be performed exactly in the order described. Rather, the various operations may be processed in different orders or simultaneously, and operations may be added or omitted.

  At block 510, the target sends information about the migration to the source. For example, a virtual machine manager (VMM) can be launched on the target host to initiate live migration. The target VMM can communicate with the source VMM to initiate the migration. According to another example, communication may be initiated by the target host and / or directed to the source host or source guest. Further examples include the source communicating with the target, a third party device communicating with both the source and target, or any other mechanism for initiating a transition.

  At block 520, the source receives information from the target. For example, the source host, source VMM and / or source guest can receive the information. In some instances, this information may serve as a notification to the guests to be migrated.

  In some instances, the guest on the source host can take action in response to being notified of an impending transition. One such action is to change one's normality state, such as transitioning to lame duck mode.

  At block 540, the source forwards traffic received from a virtualized or non-virtualized network device, such as another guest, another host or other device, to the target. For example, the network controller can install forwarding rules in the flow table on the source to forward traffic. Similarly, the target may receive forwarded traffic and forward outgoing traffic designated to the network device to the source (block 550). In this way, the source can receive traffic forwarded from the target and provide the received traffic to the network device.

  At block 560, it may be determined whether the migration is complete. For example, the migration is considered complete when the migration of the guest from the source to the target is complete, or when the network device is updated to communicate with the guest on the target host. According to one example, the source host can detect that the guest has been migrated to the target host. As another example, the source may be notified of the completion of the transition, for example from the network controller. If migration is not yet complete, the source will continue to transfer between the network device and the target.

  If at block 560 it is determined that the migration is complete, then the processing at block 550 is resumed on the target host, and the guest on the target host receives the packet directly from the network device. For example, the controller can enable direct communication by providing the network device with the updated address of the guest on the target host.

  FIG. 6 provides another exemplary flow diagram illustrating a method 600 for live migrating a virtualized network stack promoted by "other" guests. Similar to method 500 of FIG. 5, the operations included in method 600 may be processed in a different order or simultaneously, and operations may be added or omitted.

  At block 610, the other guest receives a token to communicate with the transitioning guest on the target host. The token may be received from the network controller, eg, in response to a lookup request. The token can authenticate and specify the delivery path to the target. For example, tokens can be used to authenticate packets received directly from the target, packets sent directly to the target can be authenticated, and packets on the inbound path from the target to other guests Can be certified.

  At block 620, the other guest sends network traffic to the migrating guest on the source host. The traffic is received at the source (block 630) and forwarded to the target (block 640).

  At block 650, the target receives traffic forwarded from the source and forwards outgoing traffic designated for other guests to the source.

  At block 660, the other guest determines whether it has received an incoming packet from the migrating guest on the target host. If not, the source and target continue to forward traffic with other guests. However, when another guest receives an incoming packet from the target, it may be an indication to other guests about the completion of the migration.

  Thus, at block 670, the other guest sends the packet directly to the migrating guest on the target. For example, other guests use tokens received from the network controller to authenticate and specify the delivery path for communication.

  Method 600 can provide a more seamless transition. This allows other guests to start sending packets to guests on the target after the migration is complete. For example, other guests have already received tokens from the controller to set the delivery path to the target, and therefore do not have to wait for updates from the controller after the migration is complete.

  The aforementioned techniques are further advantageous because the active process of the guest virtual machine can be moved from the source host to the target host with minimal impact on the guest. The guest process may not be delayed or aborted, and may be delayed or aborted minimally. Furthermore, it would be advantageous to expose the transitioning guest to the impending live transition so that the transitioning guest can act accordingly. For example, placing the migration guest in lame duck mode minimizes the impact on load balancing operations and allows for continuous execution of the application. This is particularly advantageous for blackout delay sensitive applications.

  Because these and other variations and combinations of the features described above can be utilized without departing from the subject matter defined by the claims, the foregoing description of the illustrative embodiments is directed to the claims. It is to be understood that the subject matter defined is not intended to be limiting, but rather to exemplify the subject matter defined by the claims. Also, it should be understood that the illustrations (and expressions such as "such as", "for example" and "including") described herein limit the claimed subject matter to the specific embodiments. They should not be construed as, and these illustrations are intended to illustrate only some of the many possible aspects.

Claims (14)

A method for facilitating live migration with a virtualized network device, comprising:
Sending a packet by the virtualized network device to a migrating guest on a source host, and forwarding the packet to a target host by the source host;
Informing the transition guest of the transition before starting the transition;
Changing the status of the migration guest in response to the notification;
Receiving packets from the migrating guest on the target host via the source host;
Determining whether migration of the migration guest from the source host to the target host has been completed by the virtualization network device;
Sending the packet from the virtualization network device directly to the migration guest on the target host if it is determined that the migration is complete,
In the step of determining whether migration of the migration guest is completed,
Receiving one or more packets directly from the migrating guest on the target host at the virtualized network device;
Verifying based on the one or more received packets that migration has been completed. Further comprising receiving a token from a network controller at the virtualization network device,
The method according to claim 1, wherein sending the packet directly to the transitioning guest on the target host comprises authenticating and designating a delivery path using the received token. Further comprising transmitting a lookup request from the virtualization network device to the network controller,
The method of claim 2, wherein the token is received at the virtualization network device in response to the lookup request. A system for live migration in a network,
Source host,
A migration guest running on the source host;
A target host in communication with the source host;
And other virtualized network devices in communication with the migration guest on the source host;
The source host is configured to forward traffic received from the other virtualization network device to the target host and forward traffic received from the target host to the other virtualization network device.
The migration guest is notified of the migration before starting the migration;
The migrating guest is configured to change its state in response to the notification;
The target host is configured to send packets directly to the other virtualization network device when the migration guest migration is complete,
The other virtualization network device is configured to determine a time of receiving a packet directly from the target host and, in response, to send a packet directly to the migrating guest on the target host . Further equipped with a network controller,
5. The system of claim 4 , wherein the network controller is configured to provide a token to the other virtualized network device for direct communication with the transitioning guest on the target host. 6. The system of claim 5 , wherein the token is used to authenticate and designate a delivery path from the other virtualization network device. The system according to claim 4 , wherein the migration guest transitions to a mode to keep existing connections and to reject future processing requests. The migration guest communicates with another system,
5. The system of claim 4 , wherein the communication directs the further system to future processing requests to other resources on the network during the transition. The source host is a rule for forwarding traffic received from the other virtualized network device to the target host after the migration is completed, or the other virtualized network device receives traffic received from the target host The system according to any one of claims 4 to 8 , configured to delete rules for forwarding to the forwarding table. 10. The system of claim 9 , wherein the source host waits for a predetermined time before deleting the rule from the forwarding table after the migration is complete. At least one of the source host and the target host receives a notification that network reprogramming for the migration is complete,
The system of claim 9 , wherein the rules for forwarding traffic are deleted in response to the notification. After the live migration is notified to migrate the guest on the source host, the method comprising: receiving an instruction to shift to the target host the migrated guest from the source host by the transition guest on the source host,
Taking a predetermined action in response to receiving the instruction;
Copying the migration guest from the source host to the target host;
Forwarding traffic received from another network device for said migrating guest on said source host to said target host;
Forwarding traffic received from the target host for the migrating guest to the other network device.
The step of taking the predetermined action includes the step of changing the state of the transition guest.
The step of changing the state includes transitioning the transition guest to a mode of completing an existing task without accepting a new task. The step of transitioning the transition guest to the mode includes
Allowing another task to provide a service request during said transition, or
Removing the migration guest from the load balancing pool,
The method of claim 12 , further comprising: A program for causing a computer to execute the method according to any one of claims 1 to 3 , 12 or 13 .