System and method for performing live migration from a source host to a target host - Patents.com

Abstract

To perform live migration when a source host and a target host are located in a vehicle and / or in an embedded system.SOLUTION: A processor of a system is configured to determine workload data and an available live migration candidate host for an active workload that utilizes a source host, and select a target host from the live migration candidate host based on workload requirement information and configuration data of the live migration candidate host. Once the target host is selected, the system determines and executes a migration routine for migration of an active workload from the source host to the target host.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] The subject matter described herein relates generally to systems and methods for performing live migration from a source host to a target host, and more specifically, to systems and methods for performing live migration when the source and target hosts are located in a vehicle and / or an embedded system. [Background technology]

[0002] The background discussion provided is intended to generally provide a context for the present disclosure. The inventors' work to the extent described in this Background section, and aspects of the description that may not be admitted as prior art at the time of filing, are not admitted, expressly or impliedly, as prior art against the present technology.

[0003] Live migration is the process of transferring a live virtual machine from one physical host to another without interrupting normal operations. Live migration allows for the migration of virtual machines and is performed in a planned manner to minimize operational downtime. In some cases, live migration may be performed when a host or an application run by the host requires maintenance, an update, etc.

[0004] In one example of live migration, data stored in the virtual machine's memory is transferred to the target host. Once the memory copy process is complete, a working resource state consisting of processor, memory, and storage is created on the target host. The virtual machine is then suspended on the original host, copied, and started on the target host and its installed applications. In general, this process requires minimal downtime, making it a good choice for updating servers that require minimal interruption, such as web-based servers. Summary of the Invention [Problem to be solved by the invention]

[0005] Live migration performed on a server is usually fairly straightforward since the host and target servers typically have the same hardware configuration with the same inputs and outputs (e.g., Ethernet-based connections). Embedded systems, such as those typically found in vehicles, pose unique challenges when performing upgrades. Furthermore, different embedded systems may have different requirements, such as different safety integrity levels, processor expansion requirements, and / or different I / O requirements. For example, one embedded system may not be available as a target host for another embedded system when performing a live migration because the embedded system may not have the appropriate safety integrity level, processor expansion requirements, and / or appropriate I / O requirements. [Means for solving the problem]

[0006] This section is intended to provide a general overview of the disclosure, but is not an exhaustive description of its entire scope or all of its features.

[0007] In one embodiment, a system for performing live migration from a source host to a target host includes a processor and a memory in communication with the processor and storing instructions. When executed by the processor, the instructions cause the processor to determine workload data for an active workload utilizing the source host. In one example, the workload data includes workload requirement information indicating hardware support requirements for executing the active workload, such as a safety level, a processor extension type, and / or input / output mapping information.

[0008] The instructions then cause the processor to determine available live migration candidate hosts and select a target host from the live migration candidate hosts based on the workload requirement information for the active workload and configuration data of the live migration candidate hosts. Once selected, the instructions cause the processor to determine and execute a migration routine for migrating the active workload from the source host to the target host.

[0009] In another embodiment, a method for performing a live migration from a source host to a target host includes determining workload data for an active workload utilizing the source host. As previously described, the workload data includes workload requirement information indicating hardware support requirements for executing the active workload, such as a safety integrity level, a processor enhancement type, and / or I / O mapping information. The method further includes determining available live migration candidate hosts and selecting a target host from the live migration candidate hosts based on the workload requirement information for the active workload and configuration data of the live migration candidate hosts. Once selected, the method determines and executes a migration routine for migrating the active workload from the source host to the target host.

[0010] In yet another embodiment, a non-transitory computer-readable medium includes instructions that, when executed by a processor, cause the processor to determine workload data for active workloads utilizing a source host. Again, as discussed above, the workload data includes workload requirement information indicating hardware support requirements for executing the active workloads, such as a safety level, a processor extension type, and / or I / O mapping information.

[0011] The instructions then cause the processor to determine available live migration candidate hosts and select a target host from the live migration candidate hosts based on the workload requirement information for the active workload and configuration data of the live migration candidate hosts. Once selected, the instructions cause the processor to determine and execute a migration routine for migrating the active workload from the source host to the target host.

[0012] Further areas of applicability and various ways of enhancing the disclosed technology will become apparent from the description provided. The description and specific examples in this summary are for purposes of illustration only and are not intended to limit the scope of the present disclosure. [Brief description of the drawings]

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be understood that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the figures represent one embodiment of a boundary. In some embodiments, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component, and vice versa. Additionally, elements may not be drawn to scale.

[0014] [Figure 1] 1 illustrates an example vehicle incorporating a system for performing live migration from a source host to a target host. [Diagram 2] FIG. 2 shows a more detailed view of the vehicle of FIG. 1; [Diagram 3] 1 illustrates an example of a host that performs live migration. [Figure 4] 1 illustrates an example of workload data for active workloads utilizing a host. [Diagram 5]1 shows an example of configuration data from available live migration candidate hosts. [Figure 6] 1 shows a block diagram of performing a live migration from a source host to a target host. [Figure 7] 1 illustrates an example of a method for performing a live migration from a source host to a target host. [Figure 8] An example of executing a migration routine will now be described. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Described herein are systems and methods for performing live migration between a source host and a target host. Performing live migration of embedded systems, especially embedded systems in automobiles, presents unique challenges not found in traditional live migration approaches for server-based live migration. In addition, embedded systems typically have different types of processors with enhanced capabilities and safety integrity levels. Furthermore, these embedded systems typically have different input / output (I / O) for each embedded system. These differences complicate live migration between different embedded systems.

[0016] The systems and methods described herein determine workload data for active workloads utilizing a source host. The workload data includes information indicative of hardware support requirements for executing the active load, such as safety level, instruction set, number of cores, processor extensions, I / O mapping information, and other information. The systems and methods also identify live migration candidate hosts and receive configuration data from these candidate hosts indicative of performance characteristics of the candidate hosts. The configuration data may include information similar to the workload data indicative of each candidate host's safety level, instruction set, number of cores, processor extensions, I / O mapping information, and the like.

[0017] A target host is selected from the candidate hosts based on the configuration data and the workload data. Once the target host is selected, a migration routine is prepared and executed to transfer the active workload from the source host to the target host. If the source and target hosts have non-common I / O terminations, a tunneling agent can operate on the source and target hosts to enable the target host to access the non-common I / O by the source host.

[0018] 1, an example of a vehicle 100 traveling on a road 10 is shown. The vehicle 100 includes hosts 200A-200C. As will be described in more detail below, the hosts 200A-200C are computers or other devices that can communicate with each other and / or with other hosts over a network. The hosts 200A-200C can provide computing and storage capabilities to support one or more applications that utilize the computer resources of the hosts 200A-200C.

[0019] The hosts 200A-200C may provide computational support for running applications that provide multiple functions for the vehicle 100. For example, the hosts 200A-200C may assist in running applications related to vehicle safety, entertainment, propulsion systems, etc. In this example, the hosts 200A-200C are mounted within the vehicle 100 and may be one or more embedded systems. Also, although the vehicle 100 is shown as having only three hosts 200A-200C, it should be understood that the vehicle 100 may have any number of hosts.

[0020] Situations may arise that require the applications executed by the hosts 200A-200C to be transferred. In some cases, the transfer may be due to the implementation of an update that improves security, functionality, or other features of the applications executed by the hosts 200A-200C. The hosts 200A-200C may apply the transfer in response to a scheduled upgrade or a determination of poor behavior, including, but not limited to, dynamically detected risks, performance degradation, warnings from monitoring mechanisms (e.g., intrusion detection systems, firewalls, anti-tamper / anti-tamper features, etc.), loss of system / safety integrity, failure due to natural causes (component aging, electromagnetic interference, etc.), or failure due to human causes (physical damage, cyber-attack, etc.). For example, the cloud-based server 12 may include one or more upgrades 14 that may be communicated to the vehicle 100 via the network 16. In some situations, the host may be taken offline to perform the application upgrade. However, in other situations, such as those described above, it may not be possible to take the host offline. In such situations, as described in more detail below, a live migration may be performed which involves moving a virtual machine (VM) running on a source host to a target host without disrupting normal operations or causing downtime or other adverse effects to end users.

[0021] Referring to FIG. 2, a block diagram of a vehicle 100 is shown. As used herein, "vehicle" refers to any form of motorized transportation. In one or more embodiments, the vehicle 100 is an automobile. Although configurations are described herein with respect to automobiles, it will be understood that the embodiments are not limited to automobiles. In some embodiments, the vehicle 100 may be any robotic device or motorized transportation. Additionally, it should be understood that the live migration systems and methods described in this disclosure may be applied to non-vehicle type applications, particularly in embedded systems.

[0022] Vehicle 100 also includes various elements. It will be understood that in various embodiments, vehicle 100 may not necessarily have all the elements shown in FIG. 2. Vehicle 100 may have any combination of the various elements shown in FIG. 2. Furthermore, vehicle 100 may have additional elements to those shown in FIG. 2. In some configurations, vehicle 100 may be implemented without one or more elements shown in FIG. 2. Although various elements are shown in FIG. 2 as being located within vehicle 100, it will be understood that one or more of these elements may be located outside vehicle 100. Furthermore, the elements shown may be physically remote and may be provided as a remote service (e.g., a cloud computing service).

[0023] Some of the possible elements of the vehicle 100 are shown in FIG. 2 and described in conjunction with subsequent figures. However, a description of most of the elements of FIG. 2 is provided following the description of FIGS. 2-8 for purposes of brevity of this description. In addition, it will be understood that, where appropriate, reference numerals are repeated among the different figures to indicate corresponding or similar elements for simplicity and clarity of description. Furthermore, the description outlines many specific details to provide a thorough understanding of the embodiments described herein. It will be understood that the embodiments described herein may be implemented using various combinations of these elements.

[0024] In either case, vehicle 100 includes hosts 200A-200C that provide hardware resources (computation, storage, connectivity, or other) for executing various applications that enable the functionality of vehicle 100, as previously described. For example, host 200A may execute application 202A that provides safety-related functionality, such as lane departure warning, lane keeping assist, emergency braking, semi-autonomous and / or autonomous driving functionality, anti-lock braking, etc. For example, application 202A executed by host 200A may receive information from sensor system 120, determine response plans, and function vehicle systems 130. Hosts 200B and / or 200C provide hardware resources to applications 202B and 202C, respectively, that may provide overlapping or other vehicle functionality, such as passenger entertainment, engine / transmission / propulsion management, etc.

[0025] The hosts 200A-200C can communicate with each other and / or with various other vehicle systems using the bus 110. In addition to the bus 110, the hosts 200A-200C can also use other I / O communication methods that may not be common to one another. For example, the hosts 200A and 200B may have common I / O using the bus 110, but may also have non-common I / O that is not shared. In such situations, a tunneling agent may be utilized to provide access to the non-common I / O, as described below.

[0026] An example of a host 200 similar to hosts 200A-200B is shown in FIG. 3. Host 200 may include, as its major components, hardware resources 210, operating system 212, hypervisor 214, and virtual machines 216A-216C. Hardware resources 210 provide appropriate hardware for operation of operating system 212 and hypervisor 214. It should be understood that host operating system 212 may be optional. For example, if hypervisor 214 is a type 1 hypervisor, operating system 212 may not be present. Conversely, if hypervisor 214 is a type 2 hypervisor, operating system 212 may be present. More specifically, a type 1 hypervisor is referred to as a native or bare metal hypervisor and runs directly on hardware resources 210 of host 200. A type 2 hypervisor is referred to as a hosted hypervisor and runs on a traditional operating system such as operating system 212.

[0027] Hardware resources 210 may vary from host to host. In this example, hardware resources 210 include one or more processors 230. In this example, processor 230 includes three processors 232-236. It should be understood that hardware resources 210 may include any one of a number of different processors. Additionally, processors 232-236 may be substantially similar to one another or may be different from one another. For example, processor 232 may have a different security level, a different instruction set, and / or different processor extensions than processor 234. Similarly, processor 236 may be the same as or different from processors 232 and / or 234. One or more processors 230 may be part of host 200, or host 200 may access processor(s) 230 via a data bus or another communication path. In one or more embodiments, processor(s) 230 are application specific integrated circuits capable of performing various functions as described herein.

[0028] The hardware resources 210 may include an I / O interface 240 that communicates with the processor(s) 230. The I / O interface 240 may include any hardware and / or software necessary to enable the host 200 to communicate with other devices via a connection 242. The connection 242 may be common, non-common, or a combination thereof with respect to other hosts. For example, referring to the example of FIG. 2, the host 200A may communicate with one set of systems and subsystems of the vehicle 100. In contrast, the host 200B may communicate with another set of systems and subsystems of the vehicle 100. Additionally, some systems and subsystems of the vehicle 100 may communicate with the hosts 200A and 200B.

[0029] Hardware resources 210 may also include memory 250 that stores instructions 252 and / or memory pages 254 used by virtual machines 216A-216C and workloads 218A-218C. Memory 250 may be random access memory (RAM), read-only memory (ROM), a hard disk drive, flash memory, or other suitable memory for storing instructions 252 and / or memory pages 254. Instructions 252 are, for example, computer-readable instructions that, when executed by processor(s) 230, cause processor(s) 230 to perform various functions disclosed herein. Memory pages 254 may be fixed-length contiguous blocks of virtual memory described by a single entry in a page table.

[0030] Additionally, in one embodiment, hardware resources 210 include one or more data stores 260. In one embodiment, data store 260 is an electronic data structure, such as a database, stored in memory 250 or another memory and configured with routines that may be executed by processor(s) 230 to analyze, present, and organize the stored data. Thus, in one embodiment, data store(s) 260 store data used by instructions 252 in performing various functions. In one embodiment, data store(s) 260 include workload requirement information 262 and configuration data 264, which are described later in this description and shown in Figures 4 and 5, respectively.

[0031] Returning to the virtual machines 216A-216C, it should be understood that the host 200 can have any one of a number of different virtual machines running thereon. In this example, each of the virtual machines 216A-216C has a workload 218A-218C running thereon. The virtual machines 216A-216C may be virtualizations / emulations of computer systems. The virtual machines 216A-216C are based on computer architectures and can provide the functionality of a physical computer. Their implementation may include specialized hardware, software, or a combination thereof.

[0032] Workloads 218A-218C may include operating systems 222A-222C that execute applications 220A-220C, respectively. Essentially, each of virtual machines 216A-216C executes a different application that provides different functionality to vehicle 100. For example, application 220A associated with workload 218A may execute a safety-related application, such as an advanced driver assistance system (ADAS), while application 220B associated with workload 218B may execute an entertainment-related application. The implementation of applications 220A-220C may also be containerized or unikernel-based.

[0033] As previously mentioned, the instructions 252, when executed by the processor(s) 230, may cause the processor(s) 230 to perform any of the methods described herein. In particular, the instructions 252 may cause the processor(s) 230 to perform a live migration from a source host to a target host by taking into account the workload requirement information 262 and the configuration data 264. For example, with reference to FIG. 6, consider an example in which a live migration is performed from host 200A to host 200B. As previously mentioned, host 200A and / or host 200B may be similar to host 200 shown and described in FIG. 3. In this example, host 200A may be referred to as a source host and host 200B may be considered a target host.

[0034] In this example, instructions 252 cause processor(s) 230 of source host 200A (or possibly another processor and / or the entire host) to determine workload data for active workloads 218A-218C in the form of workload requirement information 262. Workload requirement information 262 may include information regarding the needs of applications 220A-220C running on virtual machines 216A-216C. An example of workload requirement information 262 is shown in FIG.

[0035] In the example shown in FIG. 4, the workload requirement information may include information about the specific requirements of the application, such as safety integrity level (Automotive Safety Integrity Level (ASIL)), processor instruction set information, number of cores, various processor enhancement types, processor accelerators, I / O mapping information, average / spare load, and performance information (instructions per second, floating point operations per second, I / O operations per second, etc.). The safety integrity level information, such as ASIL, may be related to a risk classification system defined by a standard. Some applications require hardware with a higher safety integrity level depending on their criticality, such as safety. For example, safety-related automotive systems typically require a higher safety integrity level, while entertainment-related systems may have lower requirements.

[0036] Various processor extension types may be found in processors with extended instruction sets and associated architectures that provide additional features / functionality to a particular processor. Processor accelerator information may include information about the required hardware features of the host, such as the presence of a graphics processing unit, a digital signal processor, a hardware security module, hardware-assisted security measures, cryptographic or neural network accelerators, communication modules, etc.

[0037] The I / O mapping information may include information regarding which systems an application needs to access. For example, an application may need to access one or more systems or subsystems of vehicle 100 and therefore need to access the appropriate bus or other connection. As previously mentioned, in some cases, several hosts may have a common connection, where both hosts access the same system or subsystem, and in other cases, several hosts may have non-common connections, where only one host accesses a particular system or subsystem and the other hosts do not.

[0038] Instructions 252 also cause processor(s) 230 of source host 200A (or possibly another processor and / or the entire host) to determine available live migration candidate hosts and configuration data from the available live migration candidate hosts. For example, the live migration candidate hosts may include any of hosts 200A-200C in vehicle 100. For example, if the source host is host 200A, then the live migration candidate hosts may include hosts 200B and 200C.

[0039] An example of configuration data 264 from live migration candidate hosts is shown in Figure 5. Similar to workload requirement information 262, configuration data 264 also includes information regarding the hardware performance characteristics of each candidate host, such as safety integrity level (e.g., ASIL), processor instruction set information, number of cores, various processor enhancement types, processor accelerators, I / O mapping information, average / excess load, and performance information (e.g., instructions per second, floating point operations per second, and I / O operations).

[0040] Based on workload requirement information 262 and configuration data 264, instructions 252 cause processor(s) 230 (or possibly another processor and / or the entire host) of source host 200A to select a target host from the live migration candidate hosts. In the example shown in Figure 6, host 200B is selected as the target host. During live migration, virtual machine 318A running on host 200A is stopped and recreated as virtual machine 318B running using the hardware of host 200B.

[0041] To minimize disruption and performance, instructions 252 also cause processor(s) 230 of source host 200A (or possibly another processor and / or the entire host) to determine the I / O routing configuration. As previously mentioned, in some cases, the target host and the source host may share the same I / O configuration and have access to the same systems and subsystems. However, in other cases, the target host may not have the appropriate I / O to access certain systems and subsystems accessible by the source host. In the example shown in FIG. 6, hosts 200A and 200B both have common I / O 344. However, they also have non-common I / O 342A (accessible only by host 200A) and non-common I / O 342B (accessible only by host 200B).

[0042] In order for host 200B to properly perform all the functions previously performed by host 200A, the I / O routing configuration includes the functionality of creating tunneling agents 319A and 319B running on hosts 200A and 200B, respectively. Tunneling agents 319A and 319B are essentially lightweight processes run by hosts 200A and 200B, respectively, that allow one host to access the non-common I / O of the other host. In this example, host 200B can access non-common I / O 342A through tunneling agents 319A and 319B via communication path 350. Communication path 350 may be a direct bus between hosts 200A and 200B, or it may be a shared bus utilized by other components.

[0043] The tunneling agent can reside in a memory region separate from the main execution environment of hosts 200A and 200B so that it is protected from tampering / fault (e.g., ROM, boot loader, etc.). The tunneling agent can be instructions executed on a processor or ASIC that performs the function. Thus, if an attacker triggers a live migration to occur, tunneling will function as expected.

[0044] Once I / O tunneling is activated, instructions 252 cause processor(s) 230 of source host 200A (or possibly another processor and / or the entire host) to begin transmitting relevant memory pages 254 from host 200A to host 200B. The memory pages are utilized by an application executed by virtual machine 318B. Once the minimum set of relevant memory pages has been transferred, the workload executed by virtual machine 318B is transmitted from host 200A to host 200B. The transmission of memory pages 254 continues until memory pages 254 have been completely transferred from host 200A to host 200B.

[0045] Instructions 252 then cause processor(s) 230 of source host 200A (or possibly another processor and / or the entire host) to report details of the migration to an incident manager and / or set diagnostic records and enter fail-safe mode.

[0046] Thus, the described system may enable live migration to be performed in embedded environments, particularly in automobiles, where hosts may have different I / O mappings and hardware characteristics. The system enables selection of an appropriate host to act as a target host based on configuration data of the target host and workload requirement information of the workload being executed by the source host. Additionally, in situations where non-common I / O may exist, the system enables creation of a tunneling agent that allows the target host to access the non-common I / O.

[0047] 7 and 8, a method for performing a live migration from a source host to a target host is shown. The method is described from the perspective of the vehicle 100 of FIG 2 and the host 200 of FIG 3. However, it should be understood that this is merely one example of implementing the method shown in FIG 7 and 8.

[0048] As previously discussed, performing a live migration from a source host to a target host may be accomplished by utilizing instructions that, when executed by one or more processors, cause the methods illustrated in Figures 7 and 8 to be performed. In some cases, the instructions and / or processors used to perform the live migration may be found within the source host, the target host, another host that oversees the migration from the source host to the target host, or a combination thereof.

[0049] In this example, the method 400 begins when instructions 252 cause the processor 230 to enumerate active workloads 218A-218C that utilize the hardware resources 210 of the source host, as shown in step 402. In one example, the instructions 252 cause the processor(s) 230 of the source host 200A (or possibly another processor and / or the entire host) to determine workload data for the active workloads 218A-218C in the form of workload requirement information 262. The workload requirement information 262 may include information regarding the needs of the applications 220A-220C running on the virtual machines 216A-216C. As previously mentioned, an example of the workload requirement information 262 is shown in FIG. 4. Thus, workload requirement information 262 may include information such as safety integrity level (e.g., Automotive Safety Integrity Level (ASIL)), processor instruction set information, number of cores, different processor enhancement types, processor accelerators, I / O mapping information, average / excess load, and performance information (instructions per second, floating point operations per second, I / O operations per second, etc.) Workload requirement information 262 may be pre-programmed (non-dynamic) or may be cached for faster retrieval.

[0050] In step 404, instructions 252 cause processor(s) 230 to discover available candidate hosts. Candidate hosts are other hosts with which the source host is in communication. For example, the source host may be host 200A, and the candidate hosts may be hosts 200B and 200C. In step 406, instructions 252 cause processor(s) 230 to receive configuration data 264 from the available hosts. Similar to workload requirement information 262, configuration data 264 also includes information regarding hardware performance characteristics of the candidate hosts, such as safety integrity level (e.g., Automotive Safety Integrity Level (ASIL)), processor instruction set information, number of cores, different processor enhancement types, processor accelerators, I / O mapping information, average / excess load, and performance information (instructions per second, floating point operations per second, I / O operations per second, etc.). As mentioned above, an example of configuration data 264 is shown in FIG. 5. The configuration data 264 may be pre-programmed (non-dynamic) or may be cached for faster retrieval.

[0051] In step 408, instructions 252 cause processor(s) 230 to determine a corresponding migration routine. In some cases, the corresponding migration routine may not require live migration and may be performed by taking a particular host offline to perform an upgrade or other type of service. Additionally, if no suitable target host match was found in the previous step, the migration routine may include actions such as reducing system connectivity or functionality. This determination is made in step 410, where instructions 252 cause processor(s) 230 to determine whether live migration is required. If live migration is not required, method 400 may return to step 402. If live migration is required, the method proceeds to step 412, where instructions 252 cause processor(s) 230 to execute the migration routine until the live migration is completed, as shown in step 414. After the determination in step 410, the source host may be disabled, deactivated, or otherwise restricted from affecting the general behavior of vehicle 100. For example, the source host may be disconnected from bus 110, or certain functions of the host may be deactivated. Alternatively, after reaching step 414, the source host may terminate or continue its operation as a honeypot while detecting forensic information, such as in case of a human-caused failure (e.g., a cyber attack).

[0052] Step 412 is described in more detail in Figure 8. Now, in step 500, instructions 252 cause processor(s) 230 to select an optimal target host for each migration of workloads 218A-218C. In the example given in Figure 6, the target host is host 200B and the source host is host 200A. The selection of which host serves as the target host can be based on workload requirement information 262 and configuration data 264. For example, a target host is selected that has an integrity level, in terms of ASIL, equal to or higher than the integrity level of the source host (in other words, the workload requirement information).

[0053] Essentially, the workload requirements information 262 provides the requirements of the workloads 218A-218C. As previously discussed, these requirements may include such things as processor instruction types, processor extensions, I / O mapping requirements, etc. The configuration data 264 provides the hardware characteristics of the candidate hosts. The candidate host that best meets the needs of the workload requirements information 262 is selected to serve as the target host.

[0054] In step 502, instructions 252 cause processor(s) 230 to generate an I / O routing configuration to enable the target host to utilize the appropriate I / O. As previously discussed, situations may arise where the source and target hosts have non-common I / O, where the source host may have access to certain systems and subsystems that the target host would not normally be able to access. When such a situation occurs, a tunneling agent is used to enable the target host to utilize the source host to access the non-common I / O.

[0055] The exchange of information between the source and target hosts may be encrypted and / or protected from manipulation. In one example, as shown in step 504, instructions 252 cause processor(s) 230 to generate an encryption key for message authentication so that messages exchanged between the source and target hosts are protected from spoofing and / or tampering attacks. In step 506, the encryption key is applied. Once message authentication (MAC) protection is initialized, instructions 252 cause processor(s) 230 to activate I / O tunneling, as shown in step 508. As best shown in FIG. 6, tunneling agents 319A and 319B are essentially lightweight processes executed by hosts 200A and 200B, respectively, that allow one host to access the non-shared I / O of the other host. In this example, host 200B can access non-shared I / O 342A via tunneling agents 319A and 319B via communication path 350.

[0056] In step 510, instructions 252 cause processor(s) 230 to begin transmitting the relevant memory pages from the source host to the target host. Once the minimum set has been transferred, as shown in step 512, execution of workloads 318A-318C begins on the target host, as shown in step 514. The transmission of memory pages continues until all required memory pages have been transferred from the source host to the target host, as shown in step 516. In some cases, a situation may arise where an exception is generated when the target host is unable to access the appropriate memory pages because they have not yet been transferred from the source host. If this occurs, the exception may eventually be satisfied once the appropriate memory pages have been transferred from the source host to the target host.

[0057] Once the memory pages are transferred, the instructions 252 may cause the processor(s) 230 to report migration details for migrating the workloads 318A-318C from the source host to the target host, as shown in step 518. These migration details may be provided to an incident manager, who may safely log the incident or report the incident to a manufacturer of the vehicle 100 or a component of the vehicle 100. Finally, in step 520, the instructions 252 may cause the processor(s) 230 to set a diagnostic record and enter a fail-safe mode.

[0058] As mentioned in the Background section, traditional live migration is performed on servers that do not typically have the complexities of embedded systems, such as non-common I / O, various processors, processor extensions, security requirements, etc. The systems and methods described herein enable embedded systems, particularly those systems found in automobiles, to be used for live migration.

[0059] 2 is now described in detail as an exemplary environment in which the systems and methods disclosed herein may operate. In one or more embodiments, vehicle 100 may be non-autonomous, semi-autonomous, or fully autonomous. In one embodiment, vehicle 100 is configured with one or more semi-autonomous operating modes in which one or more computing systems perform a portion of the navigation and / or steering of vehicle 100 along a travel route, and an operator (i.e., a driver) of the vehicle provides inputs to the vehicle to perform a portion of the navigation and / or steering of vehicle 100 along a travel route.

[0060] As mentioned above, the vehicle 100 can include a sensor system 120. The sensor system 120 can include one or more sensors. A "sensor" refers to any device, component, and / or system that can detect and / or sense something. The one or more sensors can be configured to detect and / or sense in real-time. As used herein, the term "real-time" refers to a level of processing responsiveness that a user or system perceives as sufficiently immediate for a particular process or decision to be made, or that allows a processor to keep up with some external process.

[0061] In configurations where the sensor system 120 includes multiple sensors, the sensors may operate independently of one another. Alternatively, two or more sensors may operate in combination with one another. In such cases, the two or more sensors may form a sensor network. The sensor system 120 and / or one or more sensors may be operatively connected to a host 200A-200C or another element of the vehicle 100 (including any of the elements shown in FIG. 2). The sensor system 120 may acquire data of at least a portion of the external environment of the vehicle 100 (e.g., nearby vehicles).

[0062] The sensor system 120 may include any suitable type of sensor. Various examples of different types of sensors are described herein. However, it will be understood that the embodiments are not limited to the particular sensors described. The sensor system 120 may include one or more vehicle sensors 121. The vehicle sensor(s) 121 may detect, determine, and / or sense information about the vehicle 100 itself. In one or more configurations, the vehicle sensor(s) 121 may be configured to detect and / or sense changes in the position and orientation of the vehicle 100, such as, for example, based on inertial acceleration. In one or more configurations, the vehicle sensor(s) 121 may include one or more accelerometers, one or more gyroscopes, an inertial measurement unit (IMU), a dead reckoning system, a global navigation satellite system (GNSS), a global positioning system (GPS), a navigation system 137, and / or other suitable sensors. The vehicle sensor(s) 121 may be configured to detect and / or sense one or more characteristics of the vehicle 100. In one or more configurations, the vehicle sensor(s) 121 may include a speedometer for determining the current speed of the vehicle 100.

[0063] Alternatively or additionally, the sensor system 120 may include one or more environmental sensors 122 configured to obtain and / or sense driving environment data. "Driving environment data" includes data or information regarding the external environment in which the autonomous vehicle is located or one or more portions thereof. For example, the one or more environmental sensors 122 may be configured to detect, quantify, and / or sense obstacles and / or information / data regarding such obstacles in at least a portion of the external environment of the vehicle 100. Such obstacles may be stationary objects and / or dynamic objects. The one or more environmental sensors 122 may be configured to detect, measure, quantify, and / or sense other things in the external environment of the vehicle 100, such as, for example, lane markings, signs, traffic lights, traffic signs, lane markings, crosswalks, curbs near the vehicle 100, off-road objects, etc.

[0064] Described herein are various examples of sensors for sensor system 120. The example sensors may be part of one or more environmental sensors 122 and / or one or more vehicle sensors 121. However, it will be understood that embodiments are not limited to the particular sensors described.

[0065] For example, in one or more configurations, sensor system 120 may include one or more radar sensors 123, one or more LIDAR sensors 124, one or more sonar sensors 125, and / or a camera 126. In one or more configurations, one or more cameras 126 may be high dynamic range (HDR) cameras or infrared (IR) cameras.

[0066] The vehicle 100 may include one or more vehicle systems 130. Various examples of the one or more vehicle systems 130 are shown in FIG. 2. However, the vehicle 100 may include more, fewer, or different vehicle systems. It should be understood that while certain vehicle systems are individually defined, rather each or any of the systems, or portions thereof, may be combined or separated via hardware and / or software within the vehicle 100. The vehicle 100 may include a propulsion system 131, a braking system 132, a steering system 133, a throttle system 134, a transmission system 135, a signal system 136, and / or a navigation system 137. Each of these systems may include one or more devices, components, and / or combinations thereof, now known or later developed.

[0067] Navigation system 137 may include one or more now known or later developed devices, applications, and / or combinations thereof configured to determine a geographic location of vehicle 100 and / or determine a route for travel of vehicle 100. Navigation system 137 may include one or more mapping applications for determining a route for travel of vehicle 100. Navigation system 137 may include a global positioning system, a local positioning system, or a geolocation system.

[0068] Vehicle 100 may include instructions that cause one or more processors onboard vehicle 100 to perform any of the methods described herein. The instructions may be implemented as computer readable program code that, when executed by the processor, performs one or more of the various processes described herein. The instructions may be components of a processor and / or may be executed on and / or distributed among other processing systems.

[0069] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are intended as examples only. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to variously employ the aspects of the present specification in substantially any suitable detailed structure. Furthermore, the terms and phrases used herein are not intended to be limiting, but rather to provide an understandable description of possible examples. Although various embodiments are shown in Figures 1-8, the embodiments are not limited to the structures or applications shown.

[0070] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions for performing a particular logical function(s). It should also be noted that in some alternative implementations, the functions shown in the blocks may occur out of the order depicted in the figures. For example, two blocks shown in succession may be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved.

[0071] The above-mentioned systems, components, and / or processes can be realized in hardware or a combination of hardware and software, in a centralized manner in one processing system, or in a distributed manner with different elements distributed across several interconnected processing systems. Any kind of processing system or other device adapted to perform the methods described herein is suitable. A typical combination of hardware and software can be a processing system with computer usable program code that, when loaded and executed, controls the processing system to perform the methods described herein. The systems, components, and / or processes can also be incorporated in a computer readable storage, such as a computer program product or other data program storage device, readable by the machine, tangibly embodying a program of instructions executable by the machine to perform the methods and processes described herein. These elements can also be incorporated in an application product that has all the features enabling the execution of the methods described herein, and that can perform these methods when loaded into a processing system.

[0072] Furthermore, the configurations described herein may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied therein, for example, stored thereon. Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The phrase "computer readable storage medium" refers to a non-transitory storage medium. The computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or any suitable combination thereof. More specific examples (non-exhaustive list) of computer readable storage media include portable computer diskettes, hard disk drives (HDDs), solid state drives (SSDs), read only memories (ROMs), erasable programmable read only memories (EPROMs or flash memories), portable compact disc read only memories (CDs), digital versatile discs (DVDs), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0073] Generally, a module as used herein includes a routine, program, object, component, data structure, etc. that performs a particular task or implements a particular data type. In a further aspect, a memory generally stores the described modules. The memory associated with a module may be a buffer or cache built into the processor, RAM, ROM, flash memory, or another suitable electronic storage medium. In yet another aspect, a module contemplated by the present disclosure is realized as an application specific integrated circuit (ASIC), a hardware component of a system on a chip (SoC), a programmable logic array (PLA), or another suitable hardware component that is built with a defined configuration set (e.g., instructions) to perform the disclosed functions.

[0074] The program code embodied in the computer readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wired, fiber optic, cable, RF, etc., or any suitable combination thereof. The computer program code for performing the operations of the aspects of the present configuration may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as java, smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may be executed as a standalone software package, entirely on the user's computer, partially on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider).

[0075] The terms "a" and "an," as used herein, are defined as one or more, not one. The term "plurality," as used herein, is defined as two or more, not two. The term "another," as used herein, is defined as at least a second or more. The terms "including" and / or "having," as used herein, are defined as inclusive (i.e., open language). The phrase "and at least one of," as used herein, refers to and encompasses any and all possible combinations of one or more of the associated listed items. By way of example, the phrase "at least one of A, B, and C" includes A only, B only, C only, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0076] Aspects of the present specification may be embodied in other forms without departing from the spirit or essential characteristics thereof, and reference should accordingly be made to the following claims, rather than the foregoing specification, as indicating the scope of the present specification. [Explanation of symbols]

[0077] 12: Server, 14: Upgrade, 16: Network, 100: Vehicle, 110: Bus, 120: Sensor system, 121: Vehicle sensor, 122: Environmental sensor, 123: Radar sensor, 124: LIDAR sensor, 125: Sonar sensor, 126: Camera, 130: Vehicle system, 131: Propulsion system, 132: Brake system, 133: Steering system, 134: Throttle system, 135: Transmission system, 136: Signal system, 137: Navigation system, 200: Host, 210: Hardware resource, 212: Operator operating system, 214: hypervisor, 216A-216C: virtual machines, 218A-218C: workloads, 220A-220C: applications, 222A-222C: operating systems, 230: processors, 240: I / O interfaces, 250: memory, 252: instructions, 254: memory pages, 260: data stores, 262: workload requirement information, 264: configuration data, 318A-318B: virtual machines, 319A-319B: tunneling agents, 342A-342B: uncommon I / O, 344: I / O, 350: communication paths

Claims

1. 1. A system for performing live migration from a source host to a target host, comprising: A processor; a memory in communication with the processor having instructions; The instructions, when executed by the processor, cause the processor to: determining workload data for active workloads utilizing the source host; the workload data includes workload requirements information indicating hardware support requirements for executing active workloads; determining available live migration candidate hosts and configuration data from the available live migration candidate hosts; the configuration data being indicative of one or more performance characteristics of the candidate host; selecting the target host from the live migration candidate hosts based on the workload requirement information for active workloads utilizing the source host and the configuration data of the live migration candidate hosts; determining a migration routine for migrating active workloads from the source host to the target host; and executing the migration routine to migrate active workloads from the source host to the target host; the workload requirement information for active workloads and the configuration data of the live migration candidate host include at least one of a safety level, a processor enhancement type, and input / output mapping information; The memory further includes instructions, which when executed by the processor, cause the processor to select the target host from the live migration candidate hosts based on at least one of a security level, a processor extension type, and input / output mapping information of the live migration candidate hosts; A system, wherein the instructions for selecting the target host are instructions for selecting the target host from the live migration candidate hosts based at least on a security level, and the security level of the target host is equal to or higher than the security level of the source host.

2. A system for performing live migration from a source host to a target host, comprising: A processor; a memory in communication with the processor having instructions; The instructions, when executed by the processor, cause the processor to: determining workload data for active workloads utilizing the source host; the workload data includes workload requirements information indicating hardware support requirements for executing active workloads; determining available live migration candidate hosts and configuration data from the available live migration candidate hosts; the configuration data being indicative of one or more performance characteristics of the candidate host; selecting the target host from the live migration candidate hosts based on the workload requirement information for active workloads utilizing the source host and the configuration data of the live migration candidate hosts; determining a migration routine for migrating active workloads from the source host to the target host; and executing the migration routine to migrate active workloads from the source host to the target host; The memory, when executed by the processor, causes the processor to: An instruction to determine non-common inputs / outputs; The non-common input / output is an input / output that is seen by the source host but not by the target host; and The system further includes instructions for initiating a tunneling agent on the source host to enable the target host to use the non-common input / output through the source host.

3. The memory, when executed by the processor, causes the processor to: instructions for securely transmitting memory pages from the source host to the target host; and The system of claim 1 or 2, further comprising instructions for commencing execution of an active workload on the target host when a minimum set of memory pages has been transmitted from the source host to the target host.

4. The system of claim 1 or 2, wherein the source host and the target host are mounted within a vehicle.

5. 1. A method for performing a live migration from a source host to a target host, comprising: determining workload data for active workloads utilizing the source host; the workload data includes workload requirements information indicating hardware support requirements for executing active workloads; determining available live migration candidate hosts and configuration data from the available live migration candidate hosts; the configuration data being indicative of one or more performance characteristics of the candidate host; selecting the target host from the live migration candidate hosts based on the workload requirement information for active workloads utilizing the source host and the configuration data of the live migration candidate hosts; determining a migration routine for migrating active workloads from the source host to the target host; and executing the migration routine to migrate active workloads from the source host to the target host; the workload requirement information for active workloads and the configuration data of the live migration candidate host include at least one of a safety level, a processor enhancement type, and input / output mapping information; The step of selecting the target host further comprises: selecting the target host from the live migration candidate hosts based on at least one of a security level, a processor extension type, and input / output mapping information of the live migration candidate hosts; A method according to claim 1, wherein in the step of selecting a target host, the target host is selected from the live migration candidate hosts based at least on a security level, the security level of the target host being equal to or higher than the security level of the source host.

6. A method for performing a live migration from a source host to a target host, comprising: determining workload data for active workloads utilizing the source host; the workload data includes workload requirements information indicating hardware support requirements for executing active workloads; determining available live migration candidate hosts and configuration data from the available live migration candidate hosts; the configuration data being indicative of one or more performance characteristics of the candidate host; selecting the target host from the live migration candidate hosts based on the workload requirement information for active workloads utilizing the source host and the configuration data of the live migration candidate hosts; determining a migration routine for migrating active workloads from the source host to the target host; and executing the migration routine to migrate active workloads from the source host to the target host; The step of executing the migration routine includes: determining non-common inputs / outputs; The non-common input / output is an input / output that is seen by the source host but not by the target host; and The method includes initiating a tunneling agent on the source host to enable the target host to use the non-common input / output through the source host.

7. The step of executing the migration routine includes: securely transmitting memory pages from the source host to the target host; and 7. The method of claim 5 or 6, comprising commencing execution of an active workload on the target host when a minimum set of memory pages has been transmitted from the source host to the target host.

8. The method of claim 5 or 6, wherein the source host and the target host are mounted in a vehicle.

9. When executed by a processor, the processor: instructions to determine workload data for active workloads utilizing the source host; the workload data includes workload requirements information indicating hardware support requirements for executing active workloads; instructions for determining available live migration candidate hosts and configuration data from the available live migration candidate hosts; the configuration data being indicative of one or more performance characteristics of the candidate host; instructions for selecting a target host from the live migration candidate hosts based on the workload requirement information for active workloads utilizing the source host and the configuration data of the live migration candidate hosts; instructions for determining a migration routine for migrating active workloads from the source host to the target host; and instructions to execute the migration routine to migrate active workloads from the source host to the target host; the workload requirement information for active workloads and the configuration data of the live migration candidate host include at least one of a safety level, a processor enhancement type, and input / output mapping information; instructions that, when executed by the processor, cause the processor to select the target host from the live migration candidate hosts based on at least one of a security level, a processor extension type, and input / output mapping information of the live migration candidate hosts; A non-transitory computer-readable medium, wherein the instructions for selecting the target host are instructions for selecting the target host from the live migration candidate hosts based at least on a security level, the security level of the target host being equal to or higher than the security level of the source host.

10. When executed by a processor, the processor instructions to determine workload data for active workloads utilizing the source host; the workload data includes workload requirements information indicating hardware support requirements for executing active workloads; instructions for determining available live migration candidate hosts and configuration data from the available live migration candidate hosts; the configuration data being indicative of one or more performance characteristics of the candidate host; instructions for selecting a target host from the live migration candidate hosts based on the workload requirement information for active workloads utilizing the source host and the configuration data of the live migration candidate hosts; instructions for determining a migration routine for migrating active workloads from the source host to the target host; and instructions to execute the migration routine to migrate active workloads from the source host to the target host; When executed by the processor, the processor An instruction to determine non-common inputs / outputs; The non-common input / output is an input / output that is seen by the source host but not by the target host; and The non-transitory computer-readable medium further comprising instructions for initiating a tunneling agent on the source host to enable the target host to use the non-common input / output through the source host.

11. When executed by the processor, the processor instructions for securely transmitting memory pages from the source host to the target host; and 11. The non-transitory computer-readable medium of claim 9 or 10, further comprising instructions for commencing execution of an active workload on the target host when a minimum set of memory pages has been transmitted from the source host to the target host.

Images