WO2012152326A1 - System und verfahren zum bereitstellen und betreiben von einer oder mehreren echzeitfähigen virtuellen maschinen auf einem mehrkern hoch-rechner - Google Patents

System und verfahren zum bereitstellen und betreiben von einer oder mehreren echzeitfähigen virtuellen maschinen auf einem mehrkern hoch-rechner Download PDF

Info

Publication number
WO2012152326A1
WO2012152326A1 PCT/EP2011/057631 EP2011057631W WO2012152326A1 WO 2012152326 A1 WO2012152326 A1 WO 2012152326A1 EP 2011057631 W EP2011057631 W EP 2011057631W WO 2012152326 A1 WO2012152326 A1 WO 2012152326A1
Authority
WO
WIPO (PCT)
Prior art keywords
real
host
time
host system
virtual machine
Prior art date
Application number
PCT/EP2011/057631
Other languages
English (en)
French (fr)
Inventor
Rene Graf
Wolfgang Hartmann
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to PCT/EP2011/057631 priority Critical patent/WO2012152326A1/de
Publication of WO2012152326A1 publication Critical patent/WO2012152326A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals

Definitions

  • the invention relates to a host system, in particular a host system for a virtual machine. Furthermore, the invention relates to a method for operating a host system for a virtual machine. In addition, be ⁇ hits the invention, a program element and a computer-readable medium.
  • VT virtualization technology
  • ⁇ play multi-core processors or multi-core which are divided by the VT into virtual processors with only one or a few cores are.
  • memory that is physically present only once can be divided appropriately so that each virtual Pro ⁇ cessor gets allocated a fixed share of memory. This division can be static, but can also be carried out dynamically, ie a change in the assignment during the runtime can be permitted.
  • peripherals such as hard drives, network ports and ähnli ⁇ ches.
  • VM virtual machine
  • a physical computer with corresponding resources can thus operate or provide virtually any number of VMs.
  • the physical computer itself is referred to as a host computer. While operating the virtual Machines, the host computer or host itself must be active, namely, if a hardware in a VM has no physical counterpart, but this is only emulated. Especially with peripheral devices that are only physically present once, the host computer may have to emulate them several times in order to make a copy available to each VM.
  • An important example of this is the system timer, which is not installed in the processor, but usually in the chipset of the multi-core system or implemented and thus exists only once. The system timer offers several individual timers that can be used individually by the virtual machines, but the
  • Access to the hardware ie the physical, system timer, is only permitted for one instance, namely the host computer or the host system.
  • the respective timer in the virtual machines or virtual hardware must thus be emulated and therefore operates karbe ⁇ dingt not deterministic, ie it can not at all times be ensured that a maximum access time is guaranteed.
  • timer in an x86 architecture is the timer of the "Local APIC", which is individually assigned to the individual cores. Nevertheless, this timer can only be addressed via an emulation, which leads to significantly measurable jumps in the course of the clock, which should actually run equidistantly. Thus, no deterministic time within a virtual machine is to be ensured by means of this timer.
  • time can be corrected by means of time synchronization at regular intervals, but are too coarse granular for a real-time application.
  • KVM Kernel
  • Virtual Machine as a kernel driver and the program to use Qemu as an emulator.
  • the kernel driver provides for the configuration and use of the virtualization technology of the processor and the chipset, while the emulator provides for the emulation of the necessary peripherals.
  • the emulator is a process of the host operating system, which is subject to its scheduling behavior and thus is not deterministic.
  • Fig. 3 shows a standard host system 300 with virtual
  • Machines in particular a host system, which uses Linux as the host operating system. While it may be possible to install a real-time operating system into a virtual machine (VM), this will only work as well as the quality of the emulated timer and emulated peripherals allow.
  • VM virtual machine
  • the host system 300 includes physical host hardware 301, which is shown schematically as cores or cores 302, 303, 304, and 305.
  • the host hardware is running
  • Host operating system 306 which is, for example, a Linux operating system that provides hardware drivers 307 and 308. Further, applications running on the host are shown schematically at block 309 in FIG. Based on the hardware drivers 307 and 308, emulation processes (Qemu) 310 and 311, respectively, which serve for emulating virtual machines 312 and 313, are set up. On the virtual machines 312 and 313 can now run again an operating system and applications that can also use virtual hardware.
  • Qemu emulation processes
  • FIG. 3 shows a configuration in a standard host system with multiple virtual machines.
  • Each machine ne in this example includes a core or core exclu ⁇ sive, but has to rely on the emulation that runs as a normal process of the host operating system, among other applications for certain peripheral incl. System timer.
  • Qemu launches a thread (vCPU thread) for each core that the virtual machine should have, and possibly other threads for emulating various peripherals of the virtual machine.
  • the assignment of the Qemu threads to the physical cores of the host system can only be done manually with the help of management tools (for example, taskset, virsh).
  • management tools for example, taskset, virsh.
  • Qemu is started with the taskset command, whereby the corresponding core is specified as the CPU affinity mask.
  • the operating system scheduler thus knows which physical cores it is allowed to distribute threads to.
  • the program can be allocated a corresponding number of physical cores via the management tools, but the detailed assignment of the threads to the cores is carried out by the Linux scheduler, so that not necessarily a direct assignment the vCPU threads on the physi ⁇ cal cores must emerge.
  • this has the consequence that the computing power of a virtual core is not is predictable and thus no real-time operating system can run deterministically in the virtual machine.
  • a host system for providing a real time capable virtual machine, the host system having a host having a plurality of physical cores, the host having a real time operating system installed thereon.
  • a real-time operating system is allowed to the host by means of providing that virtual machines that are installed on the host, a real-time system ⁇ timer can be provided.
  • a real-time system ⁇ timer can be provided.
  • a method of operating a host system for real-time capable virtual machines wherein the host system comprises a plurality of physical cores, wherein the
  • Method comprises operating a real-time operating system on the host system.
  • a program element is provided which is so incorporated ⁇ oriented such that it when it is ⁇ leads on a processor, a method according to an exemplary aspect of the invention controls.
  • a computer-readable medium having stored thereon a computer program, the computer program being arranged to, when executed on a processor, control a method according to an exemplary aspect of the invention.
  • a basic idea of an exemplary aspect is that a host system is created which enables the realization of real-time capable virtual machines.
  • the host system has a plurality of physical
  • a real-time operating system is implemented on the host system or the associated host. This may be in contrast to the known host systems where a so-called General Purpose Operating System (GPOS) is installed on the host.
  • GPOS General Purpose Operating System
  • RTOS real-time Operating system
  • non-realtime VMs are also optionally installed on the host system, provided that it has a sufficient number of calculation cores. This makes it possible to simulate different devices in a system, whereby the virtual devices can communicate both with each other and with the outside. This scenario is also called virtual commissioning.
  • the host system is arranged such that an emulation process for a real-time capable virtual machine is implemented as a real-time process.
  • the host can be so turned ⁇ oriented such that the emulation process is executed on the host as a real-time process.
  • the emulation process is implemented as a real-time process, it may be possible that it itself is called deterministically by the host operating system. This makes it possible that the determinism in the virtual machine, which is emulated by the Emulationspro ⁇ zesses, is routable.
  • the host system is configured such that an assignment of a virtual core to one of the plurality of physical cores is static.
  • each virtual core and / or each virtual machine can be assigned one or more physical cores statically.
  • the mapping may also be dynamic or a hybrid mapping may be used. In both static, dynamic and hybrid assignments, it may be preferred that only one virtual core or one virtual machine be associated with each physical core. That no physical core is assigned to multiple virtual machines, or in other words, each physical core is exclusive to a virtual one
  • Such an assignment can be a one-to-one relationship insbesonde ⁇ re, that is, each virtual core is assigned to a physical core and each physical core is assigned to a virtual core or a virtual machine.
  • ⁇ re a one-to-one relationship
  • each virtual core is assigned to a physical core and each physical core is assigned to a virtual core or a virtual machine.
  • a virtual machine may have more than one physical core associated with it.
  • no physical core should be associated with multiple virtual machines. In this way, it may be preventable that a dynamic change of virtual CPU threads must take place from one physical core to another physical core.
  • the host system is also set up such that, in addition to one or a plurality of real-time-capable virtual machines, one or a second plurality of non-real-time-capable virtual machines can also be started.
  • non-real-time-capable virtual machines it is then also possible for several non-real-time-capable virtual machines to share a common physical core, but for each real-time-capable virtual machine to be at least one physical one Kern is assigned exclusively. For example, on a host system with four physical cores, two real-time virtual machines, each with one physical core assigned to it, and any number of non-real-time systems, which then share the two remaining physical cores, can be started.
  • the host system is configured to emulate a plurality of virtual machines, wherein the plurality of physical cores is greater than or equal to the plurality of virtual machines.
  • the number of physical cores may be larger than the number of virtual machines.
  • a peripheral it is possible for a peripheral to operate autonomously, as in a real or physical machine, before the periphery prompts a kernel to interrupt running the peripheral software.
  • a kernel it may be possible to implement exactly timers in the emulation, so that a real-time operating system in the virtual machine can also run deterministically and thus implicitly also all applications placed thereon.
  • the host system is configured such that a driver for a virtual machine is implemented as a real-time driver on the host.
  • the driver may be a hardware driver usable for hardware needed by the virtual machine.
  • This makes it possible for additional peripherals to produce the interrupts may be deterministic einbindbar by the driver in the host system, ie by means of the host operating system, just as if ⁇ treated as a real-time driver, so that it is possible that the corresponding emulation process can be notified accordingly fast.
  • the host system is configured such that a plurality of virtual machines can be provided by means of it.
  • the host system is arranged to support one real-time process per core of the host.
  • the method which further comprises starting an emulation process for a virtual machine, wherein in the emulation ⁇ process an assignment of a virtual core is committed to one of the plurality of physical cores.
  • the emulation process can be used as real-time
  • a kernel driver is started.
  • Kernel Virtual Machine in the Linux operating system may be a way to realize a virtual machine.
  • the host system further comprises starting a virtual machine, wherein starting the virtual machine comprises starting a real-time process on the host system associated with the virtual machine real-time process.
  • starting the virtual machine comprises starting a real-time process on the host system associated with the virtual machine real-time process.
  • a plurality of virtual machines may be started on the host system, with each of the
  • Plurality of virtual machines is associated with a real-time process on the host system.
  • a host system is created which allows real-time capable virtual machines
  • the host system or the host computer can have a plurality of cores and be operated with a real-time operating system.
  • a plurality of virtual machines are implemented on the host system, wherein the plurality or number of
  • virtual machines is less than the majority or number of physical cores of the host system. This ensures that no physical core is assigned to multiple virtual machines.
  • drivers for the virtual machine are less than the majority or number of physical cores of the host system. This ensures that no physical core is assigned to multiple virtual machines.
  • drivers for the virtual machine are less than the majority or number of physical cores of the host system. This ensures that no physical core is assigned to multiple virtual machines.
  • the real-time operating system of the host system is in particular a Linux operating system. However, any other real-time operating system that is
  • the KVM may like the configuration and use of the
  • the virtual machine offers the further advantage that the virtual machine can also be restarted if it has become unusable due to an error. The other VMs on this host will remain untouched.
  • Emulation process (QEMU) is called a real-time process
  • the described principle may also extend to the field of the automation world, in today a more or less distributed landscape
  • PLCs Programmable Logic Controllers
  • one or more servers combine the many PLCs.
  • the connected to the respective PLC
  • Field devices are here to the server (s)
  • Fig. 1 shows a schematic representation of a real-time-capable virtual machine according to awhosbei ⁇ game.
  • Fig. 2 shows a schematic representation of a configura ⁇ tion with two real-time virtual machines.
  • FIG. 3 shows a schematic representation of a host system with virtual machines.
  • FIG. 1 shows a schematic representation of a real-time-capable virtual machine according to astrasbei ⁇ game.
  • FIG. 1 shows a host system 100 which uses Linux as a host operating system and which uses a real time operating system (RTOS) instead of a general purpose operating system (GPOS).
  • RTOS real time operating system
  • GPOS general purpose operating system
  • the host system 100 includes physical host hardware 101, which is shown schematically as physical cores or cores 102, 103, 104 and 105.
  • a host real-time operating system 106 which is for example an RT-Linux operating system with a kernel driver, eg Kernel Virtual Machine (KVM) and an emulator (Qemu).
  • the RT host operating system provides a real time timer (RT timer) 107 and a hardware driver (HW driver) 108 per virtual machine. For the sake of clarity, only one virtual machine is shown in FIG.
  • applications run on the host, which are schematically represented by block 109 in FIG.
  • an emulation process (Qemu) 110 is started per virtual machine, which emulates a virtual memory
  • Machine 111 is used. On the virtual machine 111 can then run again an operating system and applications that can also use virtual hardware. Thus, the host system 100 can realize real-time virtual machines through real-time hardware emulation.
  • FIG. 1 outlines a system in which, by means of a transparent real-time extension, it may be permitted to up-grade any Linux process to the real-time process, by prioritizing its priority to one of Linux's highest static priorities and secondly, by adding the real-time process to the real-time extension, eg the real-time Linux AuDis the
  • the real-time extension may support a real-time process per core of the host processor.
  • the drivers according to the exemplary embodiment of FIG. 1 for the hardware required in the virtual machine (VM) and the timers part of the real-time operating system run on the host. Accordingly, the emulation process communicates only with these and runs itself on one or the use of threads to decouple the individual hardware parts on several real-time priorities.
  • Combined Linux with KVM and QEMU is known only as a game in exemplary embodiment ⁇ .
  • the basic principle for the realization of real-time capable virtual machines is identical when using other programs and operating systems.
  • Such virtualization may be particularly advantageous in the server environment, because this may lead to a consolidation of physical computers. Although a large number of servers can logically be made available, only a few computers are visible. The large number of servers only exists virtually.
  • the principle shown may also extend to the field of the automation world, in today a more or less distributed landscape
  • PLCs Programmable Logic Controllers
  • one or more servers may combine the many PLCs.
  • the field devices connected to the respective PLC may be connected to the server (s)
  • virtual machines of multiple servers are synchronized without the systems in the VMs having to communicate with each other.
  • VMs of the type described enable deterministic operation, it may be possible for legacy operating systems to be usable. Thus, it may even be possible to use the same disk image in which the operating system and applications are stored both for a real hardware and within the VM, which simplifies a deployment process and the
  • Means such as semaphores, message queues, shared memory
  • too virtual communication channels are created between VMs, beyond which even a deterministic one
  • each thread of the emulation which represents a core or a periphery, may be fixed to one
  • peripheral threads may run either on the same core or, if available, on another so that the quality of real-time behavior may continue to improve.
  • FIG. 2 shows a schematic representation of a configuration of a host computer 200 with two real-time capable virtual machines 201 and 202.
  • a configuration may be valid both for a PLC server and for an integration scenario.
  • the two virtual machines 201 and 202 are started.
  • As hardware are in the
  • Host computer 200 built two fieldbus cards 203 and 204, which are controlled or controlled by drivers on the real-time side of the host computer 200. Based on this, two emulation processes in their respective virtual machine provide these devices and guide them
  • Timers in the virtual machines are triggered by one and the same real-time trigger in the host computer, so that the times in the VMs are always strictly synchronous.
  • Hypervisor Hypervisor
  • the embodiment of the invention is not limited to these applications, and the above-mentioned Systemkonfigurati ⁇ ones, but also in a variety of

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Gemäß einem exemplarischen Aspekt wird ein Host-System zum Bereitstellen einer echtzeitfähigen virtuellen Maschine geschaffen, wobei das Host-System einen Host aufweist, welcher eine Mehrzahl von physikalischen Kernen aufweist, wobei auf dem Host ein Echtzeit-Betriebssystem installiert ist.

Description

Beschreibung
SYSTEM UND VERFAHREN ZUM BEREITSTELLEN UND BETREIBEN VON EINER ODER MEHREREN ECHZEITFÄHIGEN VIRTUELLEN MASCHINEN AUF EINEM
MEHRKERN HOCH-RECHNER Die Erfindung betrifft ein Host-System, insbesondere ein Host-System für eine virtuelle Maschine. Ferner betrifft die Erfindung ein Verfahren zum Betreiben eines Host- Systems für eine virtuelle Maschine. Darüber hinaus be¬ trifft die Erfindung ein Programmelement und ein computer- lesbares Medium.
Stand der Technik
Im Stand der Technik ist die sogenannte Virtualisierungs- technik (VT) bekannt, welche im Wesentlichen der Aufteilung einer Hardware in kleinere Teile dient. Populärstes Bei¬ spiel sind Mehrkern-Prozessoren oder Multi-Core Prozesso¬ ren, die mittels der VT in virtuelle Prozessoren mit nur einem oder wenigen Kernen zerteilt werden. Ebenso kann der Arbeitsspeicher, der nur einmal physikalisch vorhanden ist, entsprechend geteilt werden, so dass jeder virtuelle Pro¬ zessor einen festen Anteil an dem Arbeitsspeicher zugeordnet bekommt. Diese Aufteilung kann statisch sein, aber auch dynamisch durchgeführt werden, d.h. eine Veränderung der Zuweisung während der Laufzeit kann zugelassen sein. Ähnliches gilt für die im gesamten Rechnersystem vorhandene Peripherie wie Festplatten, Netzwerkanschlüsse und ähnli¬ ches . Das System oder Konglomerat aus virtuellen Prozessoren, anteiligen Speicher und zugeordneter Peripherie wird als virtuelle Maschine (VM) bezeichnet. Ein physikalischer Rechner mit entsprechenden Ressourcen kann somit quasi eine beliebige Anzahl an VMs betreiben oder zur Verfügung stel- len. Der physikalische Rechner selber wird dabei als Host- Rechner bezeichnet. Während des Betreibens der virtuellen Maschinen muss der Host-Rechner oder kurz Host selbst aktiv werden, wenn nämlich eine Hardware in einer VM kein physikalisches Gegenstück hat, sondern diese nur emuliert wird. Speziell bei Peripherie-Geräten, die physikalisch nur einmal vorhanden sind, muss der Host-Rechner diese ggf. mehrfach emulieren, um jeder VM ein Exemplar zur Verfügung zu stellen. Ein wichtiges Beispiel hierfür ist der Systemtimer, der nicht im Prozessor, sondern in der Regel im Chipsatz des Multi-Core-Systems verbaut oder implementiert ist und damit nur einmal vorhanden ist. Der Systemtimer bietet zwar mehrere einzelne Timer, die von den virtuellen Maschinen individuell genutzt werden können, aber der
Zugriff auf die Hardware, d.h. den physikalischen, System- timer, ist nur für eine Instanz, nämlich dem Host-Rechner oder dem Host-System, gestattet. Die jeweiligen Timer in den virtuellen Maschinen bzw. der virtuellen Hardware müssen somit emuliert werden und arbeitet daher prinzipbe¬ dingt nicht mehr deterministisch, d.h. es kann nicht mehr zu allen Zeiten sichergestellt werden, dass eine maximale Zugriffszeit garantiert wird.
Eine andere Variante eines Timers bei einer x86-Architektur ist der Timer des "Local APIC", der individuell den einzel- nen Kernen zugewiesen ist. Dennoch kann auch dieser Timer nur über eine Emulation angesprochen werden, was zu deutlich messbaren Sprüngen im Ablauf der Uhr führt, die eigentlich äquidistant ablaufenden sollte. Somit ist auch mittels dieses Timers keine deterministische Zeit innerhalb einer virtuellen Maschine sicherzustellen.
Beim Einsatz der Virtualisierung im Server-Umfeld ist dies unkritisch, da hier nur Zeitanforderungen im oberen Millisekunden oder gar Sekundenbereich zu erfüllen sind. Des Weiteren spielen erhöhte Latenzen im Server-Umfeld keine
Rolle, weil die Applikationen typischer Weise keine beson- deren Zeitanforderungen stellen. Zudem kann die Zeit mittels Uhrzeit-Synchronisation in regelmäßigen Abständen korrigiert werden, die aber viel zu grobgranular für eine Echtzeitanwendung sind.
Aus dem Stand der Technik ist beispielsweise bekannt, die virtuelle Maschine mittels einer Kombination des Kernel- Treibers und eines Emulationsprogrammes zu realisieren. Beispielsweise ist bei der Verwendung von Linux als Host- Betriebssystem bekannt, eine sogenannte KVM (Kernel-
Virtual-Machine) als Kernel-Treiber und das Programms Qemu als Emulator zu verwenden. Bei einer solchen Kombination sorgt der Kernel-Treiber für die Konfiguration und Nutzung der Virtualisierungstechnologie des Prozessors und des Chipsatzes, während der Emulator für die Emulation der notwendigen Peripherie sorgt. Damit ist der Emulator ein Prozess des Host-Betriebssystem, der dessen Scheduling- Verhalten unterliegt und somit nicht deterministisch ist. Fig. 3 zeigt ein Standard Host-System 300 mit virtuellen
Maschinen, insbesondere ein Host-System, welches Linux als Host-Betriebssystem verwendet. Es mag zwar prinzipiell möglich sein, ein Echtzeit-Betriebssystem in eine virtuelle Maschine (VM) zu installieren, aber dieses wird nur so gut laufen können, wie es die Qualität des emulierten Timers und der emulierten Peripherie zulässt.
Das Host-System 300 weist physikalische Host-Hardware 301 auf, welche schematisch als Kerne oder Cores 302, 303, 304 und 305 dargestellt ist. Auf der Host-Hardware läuft ein
Host-Betriebssystem 306, welches beispielsweise ein Linux- Betriebssystem ist, welches Hardwaretreiber 307 und 308 zur Verfügung stellt. Ferner laufen auf dem Host Applikationen, welche schematisch mit dem Block 309 in Fig. 3 dargestellt sind. Aufsetzend auf den Hardware-Treibern 307 und 308 werden Emulationsprozesse (Qemu) 310 bzw. 311 aufgesetzt, welche dem Emulieren virtueller Maschinen 312 und 313 dienen. Auf den virtuellen Maschinen 312 und 313 kann dann nun wieder ein Betriebssystem und Applikationen laufen, welche auch virtuelle Hardware nutzen können.
Somit zeigt Fig. 3 eine Konfiguration in einem Standard- Host-System mit mehreren virtuellen Maschinen. Jede Maschi- ne enthält in diesem Beispiel einen Core oder Kern exklu¬ siv, muss aber für bestimmte Peripherie inkl. Systemtimer auf die Emulation zurückgreifen, die als normaler Prozess des Host-Betriebssystems neben anderen Applikationen läuft. Qemu startet für jeden Core, den die virtuelle Maschine haben soll, einen Thread (vCPU-Thread) sowie ggf. weitere Threads für die Emulation verschiedener Peripherien des virtuellen Systems.
Die Zuordnung der Qemu-Threads zu den physikalischen Cores des Host-Systems kann nur manuell mit Hilfe von Management- Tools (z.B. taskset, virsh) erfolgen. Um im obigen Beispiel eine VM einem Core zuzuordnen, wird Qemu mit dem taskset- Kommando gestartet, wobei der entsprechende Core als CPU- Affinity Maske angegeben wird. Damit weiß der Betriebssys- tem-Scheduler, auf welche physikalischen Cores er Threads verteilen darf.
Soll die virtuelle Maschine zwei oder mehr Cores enthalten, können dem Programm über die Management-Tools zwar auch entsprechend viele physikalische Cores zugeteilt werden, aber die detaillierte Zuordnung der Threads auf die Cores wird vom Linux-Scheduler vorgenommen, so dass nicht zwingend eine direkte Zuordnung der vCPU-Threads auf die physi¬ kalischen Cores entstehen muss. Dies hat aber zur Konse- quenz, dass die Rechenleistung eines virtuellen Cores nicht vorhersagbar ist und somit kein Echtzeit-Betriebssystem deterministisch in der virtuellen Maschine laufen kann.
Eine solche Implementierung auf einem Host-System führt somit dazu, dass die virtuelle Maschine keine harten Echt¬ zeitanforderungen erfüllt.
Zusammenfassung der Erfindung Es ist Aufgabe der Erfindung, ein Host-System und ein
Verfahren zum Betreiben eines Host-Systems zu schaffen, welches hinsichtlich EchtZeitanforderungen eine verbesserte Performance erzielt. Dieser Bedarf wird durch ein Host-System, ein Verfahren zum Betreiben eines Host-Systems, ein Computerprogrammelement und durch ein computerlesbares Medium gemäß den unabhängigen Patentansprüchen erfüllt. Weitere Ausgestaltungen sind in den abhängigen Ansprüchen angegeben.
Gemäß einem exemplarischen Aspekt wird ein Host-System zum Bereitstellen einer echtzeitfähigen virtuellen Maschine geschaffen, wobei das Host-System einen Host aufweist, welcher eine Mehrzahl von physikalischen Kernen aufweist, wobei auf dem Host ein Echtzeit-Betriebssystem installiert ist .
Insbesondere wird mittels des Vorsehens eines Echtzeit- Betriebssystem auf dem Host ermöglicht, dass virtuellen Maschinen, die auf dem Host eingerichtet werden, ein Echt¬ zeit-Systemtimer zur Verfügung gestellt werden kann. Somit ist es erreichbar, dass in der virtuellen Maschine ein Echtzeit-System zufriedenstellend laufen kann.
Mit einer solchen Konfiguration, bei dem ein Echtzeit Betriebssystem anstelle eines General-Purpose- Betriebssystems zum Einsatz kommt, ist es möglich, dass ein Emulationsprozess als Echtzeit-Prozess gefahren wird, so dass der Emulationsprozess selbst deterministisch von dem Host-Betriebssystem aufgerufen wird, und diesen Determinis- mus in die virtuelle Maschine weiterleiten kann.
Gemäß einem anderen exemplarischen Aspekt wird ein Verfahren zum Betreiben eines Host-Systems für echtzeitfähige virtuelle Maschinen geschaffen, wobei das Host-System eine Mehrzahl von physikalischen Kernen aufweist, wobei das
Verfahren ein Betreiben eines Echtzeit-Betriebssystems auf dem Host-System aufweist.
Gemäß einem anderen exemplarischen Aspekt der Erfindung wird ein Programmelement geschaffen, welches derart einge¬ richtet ist, dass es, wenn es auf einem Prozessor ausge¬ führt wird, ein Verfahren gemäß einem exemplarischen Aspekt der Erfindung steuert. Gemäß einem anderen exemplarischen Aspekt der Erfindung wird ein computerlesbares Medium geschaffen, auf welchem ein Computerprogramm gespeichert ist, wobei das Computerprogramm derart eingerichtet ist, dass es, wenn es auf einem Prozessor ausgeführt wird, ein Verfahren gemäß einem exemplarischen Aspekt der Erfindung steuert.
Eine Grundidee eines beispielhaften Aspekts ist es, dass ein Host-System geschaffen wird, welches die Realisierung von echtzeitfähigen virtuellen Maschinen ermöglicht. Hierzu weist das Host-System eine Mehrzahl von physikalischen
Kernen oder physikalischen Cores auf. Auf den Host-System bzw. dem dazugehörigen Host ist hierbei ein Echtzeit- Betriebssystem implementiert. Dies mag im Gegensatz zu dem bekannten Host-Systemen stehen, bei denen auf dem Host ein sogenanntes General-Purpose-Betriebssystem (GPOS) installiert ist. Mittels des Vorsehens eines Echtzeit- Betriebssystem (RTOS) mag es möglich sein, auf dem Host- System eine Mehrzahl von virtuellen Maschinen zu starten, welche jeweils echtzeitfähig sind, d.h. ein deterministi¬ sches Zeitverhalten aufweisen.
Neben den echtzeitfähigen VMs sind optional auch weitere, nicht-echtzeitfähige VMs auf dem Host-System installiert, sofern dieses über eine ausreichende Anzahl von Rechencores verfügt. Damit wird eine Simulation verschiedener Geräte in einem System möglich, wobei die virtuellen Geräte sowohl untereinander als auch nach außen kommunizieren können. Dieses Szenario wird auch virtuelle Inbetriebnahme genannt.
Nachfolgend werden exemplarische Ausführungsbeispiele des Host-System beschrieben. Jedoch gelten die entsprechenden Ausgestaltungen und Merkmale auch für das Verfahren zum Betreiben eines Host-Systems, das Computerprogrammelement und das computerlesbare Medium. Gemäß einem anderen Ausführungsbeispiel ist das Host-System derart eingerichtet, dass ein Emulationsprozess für eine echtzeitfähige virtuelle Maschine als Echtzeit-Prozess implementiert ist. Insbesondere kann der Host derart einge¬ richtet sein, dass der Emulationsprozess auf dem Host als Echtzeit-Prozess ausgeführt wird.
Im Falle dass der Emulationsprozess als Echtzeit-Prozess implementiert ist, mag es möglich sein, dass er selber deterministisch von dem Host-Betriebssystem aufgerufen wird. Hierdurch wird es möglich, dass der Determinismus in die virtuelle Maschine, welche mittels des Emulationspro¬ zesses emuliert wird, weiterleitbar ist.
Gemäß einem anderen beispielhaften Ausführungsbeispiel des Host-Systems ist das Host-System derart eingerichtet, dass eine Zuordnung eines virtuellen Kerns zu einem der Mehrzahl von physikalischen Kernen statisch ist.
Insbesondere kann jedem virtuellen Kern und/oder jeder virtuellen Maschine ein oder mehrere physikalische Kerne statisch zugewiesen sein. Alternativ mag die Zuordnung auch dynamisch sein oder es mag eine hybride Zuordnung verwendet werden . Sowohl im statischen, dynamischen als auch in der hybriden Zuordnung mag es bevorzugt sein, dass jedem physikalischen Kern nur ein virtueller Kern oder eine virtuelle Maschine zugeordnet ist. D.h. kein physikalischer Kern ist mehreren virtuellen Maschinen zugeordnet oder anders ausgedrückt, jeder physikalische Kern ist exklusiv einer virtuellen
Maschine zugeordnet. Eine solche Zuordnung kann insbesonde¬ re eine eins-zu-eins Beziehung sein, d.h. jedem virtuellen Kern ist genau ein physikalischer Kern zugeordnet und jeder physikalische Kern ist genau einem virtuellen Kern oder einer virtuellen Maschine zugeordnet. Jedoch mag auch einer virtuellen Maschine mehr als ein physikalischer Kern zugeordnet sein. Bevorzugt sollte jedoch kein physikalischer Kern mehreren virtuellen Maschinen zugeordnet sein. Auf diese Weise mag verhinderbar sein, dass ein dynamischer Wechsel von virtuellen CPU-Threads von einem physikalischen Kern auf einen anderen physikalischen Kern stattfinden muss .
Alternativ ist das Host-System auch derart eingerichtet, dass neben einer oder einer Mehrzahl von echtzeitfähigen virtuellen Maschinen auch eine oder eine zweite Mehrzahl an nicht echtzeitfähigen virtuellen Maschinen gestartet werden kann. Hierbei sei es dann auch möglich, dass sich mehrere nicht echtzeitfähige virtuelle Maschinen einen gemeinsamen physikalischen Kern teilen, während jedoch jeder echtzeit- fähigen virtuellen Maschine zumindest ein physikalischer Kern exklusiv zugewiesen ist. Beispielsweise können auf einem Host-System mit vier physikalischen Kernen somit zwei echtzeitfähige virtuelle Maschinen, welchen jeweils ein physikalischer Kern exklusiv zugewiesen wird, und eine beliebige Anzahl von nicht echtzeitfähigen Systemen, welche sich dann die zwei verbleibenden physikalischen Kerne teilen, gestartet werden.
Gemäß einem anderen Ausführungsbeispiel ist das Host-System eingerichtet, eine Mehrzahl von virtuellen Maschinen zu emulieren, wobei die Mehrzahl von physikalischen Kernen größer oder gleich der Mehrzahl von virtuellen Maschinen ist. Anders ausgedrückt mag die Anzahl von physikalischen Kernen größer als die Anzahl von virtuellen Maschinen sein.
Insbesondere bedeutet dies, dass einem oder jedem Emulati¬ onsprogramm für virtuelle Maschinen mehrere physikalische Kerne zuweisbar sind. Auf diese Art ist es möglich, dass eine Peripherie wie in einem realen oder physikalischen Rechner autark agiert, bevor die Peripherie einem Kern per Interrupt auffordert, die zur Peripherie gehörende Software zu starten. Hierdurch mag es möglich sein, exakt genaue Timer in der Emulation zu realisieren, so dass auch ein Echtzeit-Betriebssystem in der virtuellen Maschine deterministisch laufen kann und damit implizit auch alle darauf aufgesetzten Applikationen.
Gemäß einem anderen Ausführungsbeispiel ist das Host-System derart eingerichtet, dass ein Treiber für eine virtuelle Maschine als Echtzeit-Treiber auf dem Host implementiert ist .
Insbesondere mag der Treiber ein Hardware-Treiber sein, welcher für eine Hardware, die von der virtuellen Maschine benötigt wird, verwendbar ist. Hierdurch ist es möglich, dass zusätzliche Peripherie, die Interrupts produzieren mag, deterministisch einbindbar ist, indem der Treiber im Host-System, d.h. mittels des Host-Betriebssystems, eben¬ falls als Echtzeit-Treiber behandelt wird, so dass es möglich ist, dass der korrespondierende Emulationsprozess entsprechend schnell benachrichtigt werden kann. Dieser wiederum löst in der virtuellen Hardware den passenden Interrupt aus, so dass das ganze System deterministisch arbeitet . Gemäß einem anderen Ausführungsbeispiel ist das Host-System derart eingerichtet, dass mittels ihm eine Mehrzahl von virtuellen Maschinen bereitstellbar ist.
Gemäß einem anderen Ausführungsbeispiel ist das Host-System derart eingerichtet, dass ein Echtzeit-Prozess pro Kern des Hosts unterstützbar ist.
Nachfolgend werden exemplarische Ausführungsbeispiele des Verfahrens zum Betreiben eines Host-Systems beschrieben. Jedoch gelten die entsprechenden Ausgestaltungen und Merkmale auch für das Host-System, das Computerprogrammelement und das computerlesbare Medium.
Gemäß einem anderen Ausführungsbeispiel des Verfahrens, welches ferner ein Starten eines Emulationsprozesses für eine virtuelle Maschine aufweist, wobei in dem Emulations¬ prozess eine Zuordnung eines virtuellen Kernes zu einem der Mehrzahl von physikalischen Kernen festgeschrieben wird. Insbesondere kann der Emulationsprozess als Echtzeit-
Prozess auf dem Host-System gestartet werden. Neben einem Emulationsprozess wird ein Kernel-Treiber gestartet. Die Kombination aus einem Emulationsprozess, z.B. dem sogenannten Qemu Emulator, und einem Kernel-Treiber, z.B. dem
Kernel-Virtual-Machine, beim Betriebssystem Linux mag eine Möglichkeit sein, eine virtuelle Maschine zu verwirklichen. Gemäß einem anderen Ausführungsbeispiel weist das Host- System ferner ein Starten einer virtuellen Maschine auf, wobei das Starten der virtuellen Maschine das Starten eines Echtzeit-Prozesses auf dem Host-System aufweist, welcher Echtzeit-Prozess der virtuellen Maschine zugeordnet ist. Insbesondere mögen eine Mehrzahl von virtuellen Maschinen auf dem Host-System gestartet werden, wobei jedem der
Mehrzahl von virtuellen Maschinen ein Echtzeit-Prozess auf dem Host-System zugeordnet ist.
Zusammenfassend wird ein Host-System geschaffen, welches zulässt, echtzeitfähige virtuelle Maschinen zu
verwirklichen. Hierzu kann das Host-System oder der Host- Rechner eine Mehrzahl von Kernen aufweisen und mit einem Echtzeit-Betriebssystem betrieben werden. Bevorzugt wird auf dem Host-System eine Mehrzahl von virtuellen Maschinen implementiert, wobei die Mehrzahl oder Anzahl von
virtuellen Maschinen geringer ist als die Mehrzahl oder Anzahl von physikalischen Kernen des Host-Systems. Somit wird sichergestellt, dass kein physikalischer Kern mehreren virtuellen Maschinen zugeordnet wird. Vorteilhafterweise werden Treiber für die von der virtuellen Maschine
benötigte Hardware sowie die Timer als Teil des Echtzeit- Betriebssystems auf dem Host betrieben. Entsprechend werden Emulationsprozesse für die Implementierung der virtuellen Maschinen nur mit dem Host kommunizieren und selber auf einer, oder bei der Verwendung von Threads zur Entkoppelung der einzelnen Hardware-Teile auf mehreren, Echtzeit- Prioritäten laufen. Das Echtzeit-Betriebssystem des Host- Systems ist insbesondere ein Linux Betriebssystem. Jedoch ist jedes andere Echtzeit-Betriebssystem, welches das
Bereitstellen von virtuellen Maschinen ermöglich, geeignet. Dabei bleibt das oben beschriebene Grundprinzip erhalten. Im Falle des Verwendens eines Linux Betriebssystems für den Host oder Server, wird eine Kombination aus einem Kernel- Treiber, beispielsweise einer Kernel-Virtual-Machine (KVM) und eines Emulationsprogrammes oder Emulators,
beispielsweise das sogenannte "Qemu" verwendet, um die virtuellen Maschinen zu realisieren. Hierbei mag sich die KVM um die Konfiguration und Nutzung der
Virtualisierungstechnologie des Prozessors und des
Chipsatzes sorgen, während Qemu für die Emulation der notwendigen Peripherie sorgt. Auf einem Server bietet die virtuelle Maschine den weiteren Vorteil, dass der virtuelle Rechner auch neu gestartet werden kann, wenn er durch einen Fehler unbenutzbar geworden ist. Die anderen VMs auf diesem Host bleiben davon unberührt.
Gerade bei der Emulation von Hardware kann die Verwendung eines RTOS im Host-Rechner einen Vorteil bringen. Der
Emulationsprozess (Qemu) wird als Echtzeit-Prozess
gefahren, so dass er selbst deterministisch von dem Host- Betriebssystem aufgerufen wird und diesen Determinismus in die virtuelle Maschine weiterleiten bzw. weitergeben kann.
Das beschriebene Prinzip mag sich auch auf den Bereich der Automatisierungswelt ausdehnen lassen, in der heute eine mehr oder wenige verteilte Landschaft aus
speicherprogrammierbaren Steuerungen (SPS) existiert, die in einer großen Anlage ihren Dienst verrichten mögen.
Mittels der Einrichtung mehrere echtzeitfähiger, virtueller Maschinen vereinen ein oder mehrere Server die vielen SPS in sich. Die an die jeweiligen SPS angeschlossenen
Feldgeräte sind hierbei an den bzw. die Server
angeschlossen, und es wird ein Netzwerk-Interface der entsprechenden VM zugewiesen, in der die dazugehörigen SPS als Software laufen. Die oben erläuterten und weiteren Aspekte und
Ausführungsbeispiele werden dem Fachmann durch die
nachfolgend erläuterten exemplarischen Ausführungsbeispiele klarer verständlich werden. Ferner sollte bemerkt werden, dass Merkmale, welche oben im Zusammenhang mit einem bestimmten Aspekt oder Ausführungsbeispiel beschrieben wurden, auch mit anderen Aspekten und Ausführungsbeispielen kombiniert werden können. Kurzbeschreibung der Figuren
Fig. 1 zeigt eine schematische Darstellung einer echtzeit- fähigen virtuellen Maschine gemäß einem Ausführungsbei¬ spiel .
Fig. 2 zeigt eine schematische Darstellung einer Konfigura¬ tion mit zwei echtzeitfähigen virtuellen Maschinen.
Fig. 3 zeigt eine schematische Darstellung eines Host- Systems mit virtuellen Maschinen.
Die Darstellungen in den Figuren sind schematisch. Gleiche oder ähnliche Bauteile oder Elemente in den verschiedenen Figuren sind mit gleichen oder ähnlichen Bezugszeichen versehen.
Fig. 1 zeigt eine schematische Darstellung einer echtzeit- fähigen virtuellen Maschine gemäß einem Ausführungsbei¬ spiel. Insbesondere zeigt die Fig. 1 ein Host-System 100, welches Linux als Host-Betriebssystem verwendet und bei welchem ein Echtzeit-Betriebssystem (RTOS) anstelle eines General-Purpose-Betriebssystem (GPOS) verwendet wird.
Das Host-System 100 weist physikalische Host-Hardware 101 auf, welche schematisch als physikalische Kerne oder Cores 102, 103, 104 und 105 dargestellt ist. Auf der Host- Hardware läuft ein Host-Echtzeit-Betriebssystem 106, welches beispielsweise ein RT-Linux-Betriebssystem mit einem Kernel-Treiber, z.B. Kernel-Virtual-Machine (KVM) und einem Emulator (Qemu) ist. Das RT-Host-Betriebssystem stellt einen Echtzeit-Timer (RT-Timer) 107 und einen Hardware- Treiber (HW-Treiber) 108 je virtueller Maschine zur Verfügung. Zum Zwecke der Übersichtlichkeit ist in Fig. 1 nur eine virtuelle Maschine dargestellt. Ferner laufen auf dem Host Applikationen, welche schematisch mit dem Block 109 in Fig. 1 dargestellt sind.
Aufsetzend auf den Hardware-Treiber 108 und den RT-Timer 107 wird je virtuelle Maschine ein Emulationsprozess (Qemu) 110 gestartet, welcher dem Emulieren einer virtuellen
Maschine 111 dient. Auf der virtuellen Maschine 111 kann dann wieder ein Betriebssystem und Applikationen laufen, welche auch virtuelle Hardware nutzen können. Somit kann das Host-System 100 echtzeitfähige virtuelle Maschinen mittels Echtzeit-Hardware-Emulation verwirklichen.
In Fig. 1 ist ein System skizziert, in welchem es mittels einer transparenten Echtzeit-Erweiterung erlaubt sein mag, einen beliebigen Linux-Prozess zum Echtzeit-Prozess hochzu- stufen, indem zum einen seine Priorität auf einer der höchsten statischen Prioritäten von Linux gehoben wird und zum anderen, indem der Echtzeit-Prozess sich bei der Echtzeit-Erweiterung, z.B. dem Echtzeit-Linux AuDis der
I IA&DT ATS 11), registriert. Dies mag dafür sorgen, dass der Prozess nicht weiter von Linux geschedult wird, sondern von dem Echtzeit-Kernel . Damit wird der Prozess sofort deterministisch aktiv, sobald der Timer-Tick oder ein
Interrupt einer der Emulation zugeordneten Hardware auftritt. Die Echtzeit-Erweiterung mag einen Echtzeit-Prozess pro Core des Host-Prozessors unterstützen. Im Unterschied zum System, welches in Fig. 3 dargestellt ist, laufen die Treiber gemäß dem exemplarischen Ausführungsbeispiel der Fig. 1 für die in der virtuellen Maschine (VM) benötigte Hardware sowie die Timer Teil des Echtzeit- Betriebssystems auf dem Host. Entsprechend kommuniziert der Emulationsprozess nur mit diesen und läuft selbst auf einer oder bei der Verwendung von Threads zur Entkopplung der einzelnen Hardware-Teile auf mehreren Echtzeit-Prioritäten . Die oben im Zusammenhang mit der Fig. 1 angesprochene
Kombination Linux mit KVM und Qemu wird nur als ein bei¬ spielhaftes Ausführungsbeispiel genannt. Das Grundprinzip zur Realisierung echtzeitfähiger virtueller Maschinen ist bei der Verwendung anderer Programme und Betriebssystem identisch.
Eine solche Virtualisierung mag insbesondere im Server- Umfeld vorteilhaft sein, weil diese zu einer Konsolidierung der physikalischen Rechner führen mag. Obwohl logisch eine Vielzahl von Servern zur Verfügung gestellt werden können, sind jedoch nur wenige Rechner sichtbar. Die Vielzahl an Servern existiert nur virtuell.
Das gezeigte Prinzip mag sich auch auf den Bereich der Automatisierungswelt ausdehnen lassen, in der heute eine mehr oder wenige verteilte Landschaft aus
speicherprogrammierbaren Steuerungen (SPS) existiert, die in einer großen Anlage ihren Dienst verrichten mögen.
Mittels der Einrichtung mehrere echtzeitfähiger, virtueller Maschinen mögen ein oder mehrere Server die vielen SPS in sich vereinen. Die an die jeweiligen SPS angeschlossenen Feldgeräte mögen hierbei an den bzw. die Server
angeschlossen und ein Netzwerk-Interface der entsprechenden VM zugewiesen werden, in der die dazugehörige SPS als
Software läuft. Ein Vorteil bei der Verwendung innerhalb eines Servers mag sich implizit aus der möglichen Nutzung eines
physikalischen Systemstimers zur Triggerung von emulierten Timern für einzelne virtuelle Maschinen ergeben. Deren Uhrzeiten mögen hierdurch implizit immer synchronisiert sein und können prinzipbedingt nicht auseinanderlaufen, da die Cores aller VM ebenfalls an einen zentralen Takt angeschlossen sind. Somit mag im Vergleich zur dezentralen SPS-Lösung sogar eine höhere Qualität bei weniger
Kommunikationsaufwand erreichbar sein. Über die
Synchronisation der Host-Systeme können somit auch
virtuelle Maschinen mehrerer Server synchronisiert werden, ohne dass die Systeme in den VMs miteinander kommunizieren müssen .
Dieser Vorteil mag sich ebenfalls bei einem anderen
Anwendungsfall ergeben, nämlich der Integration mehrerer bislang getrennter Geräte in einem System. Hier sind vorwiegend sogenannte Legacy-Betriebssysteme (auch mit Echtzeit) im Einsatz, die nicht für den Betrieb in einer virtuellen Maschine entwickelt wurden, sondern eine
deterministische Hardware für den Betrieb voraussetzen. Da die echtzeitfähigen VMs der beschriebenen Bauart einen deterministischen Betrieb ermöglichen, mag es möglich sein, dass Legacy-Betriebssysteme verwendbar sind. Damit mag es sogar möglich sein, ein und dasselbe Diskimage, in dem Betriebssystem und Applikationen gespeichert sind, sowohl für eine reale Hardware als auch innerhalb der VM zu nutzen, was einen Deploy-Prozess vereinfachen und den
Testaufwand reduzieren mag.
Die einzelnen Emulationsprozesse mögen zwar getrennt auf verschiedenen Cores laufen, sind aber alle Prozesse des gleichen Host-Betriebssystems, so dass sie mit dessen
Mitteln, z.B. Semaphoren, Message-Queues, Shared-Memory) untereinander kommunizieren können. Damit mögen auch virtuelle Kommunikationskanäle zwischen VMs geschaffen werden, über welche sogar eine deterministische
Kommunikation möglich sein mag. Zusätzlich mag jeder Thread der Emulation, der einen Core oder eine Peripherie darstellt, fest an einen
physikalischen Core des Host-Systems gebunden sein, so dass er deterministisch arbeiten kann, auch in Hinblick auf das Cache-Verhalten. Die Peripherie-Threads mögen entweder auf dem gleichen Core oder falls verfügbar auf einem weiteren laufen, so dass sich die Qualität des Echtzeitverhaltens weiter verbessern mag.
Neben den echtzeitfähigen VMs mögen optional auch weitere, nicht-echtzeitfähige VMs auf einem Host-System installiert werden, sofern dieses über eine ausreichende Anzahl von Rechencores verfügt.
Fig. 2 zeigt eine schematische Darstellung einer Konfigura- tion eines Host-Rechners 200 mit zwei echtzeitfähigen virtuellen Maschinen 201 und 202. Eine solche Konfiguration mag sowohl für einen SPS-Server als auch für ein Integrationsszenario gültig sein. Basierend auf einem Echtzeit- Betriebssystem des Host-Rechners werden die zwei virtuellen Maschinen 201 und 202 gestartet. Als Hardware sind in dem
Host-Rechner 200 zwei Feldbus-Karten 203 und 204 eingebaut, die durch Treiber auf der Echtzeitseite des Host-Rechners 200 gesteuert oder kontrolliert werden. Darauf aufbauend stellen zwei Emulationsprozesse in ihrer jeweiligen virtu- eilen Maschine diese Geräte zur Verfügung und leiten die
Interrupts bei eingehenden Telegrammen entsprechend deterministisch an das Echtzeit-Betriebssystem in der VM weiter.
Timer in den virtuellen Maschinen werden von ein und dem- selben Echtzeit-Trigger in dem Host-Rechner getriggert, so dass die Zeiten in den VMs immer streng synchron sind. Eine solche Lösung mittels echtzeitfähiger virtueller
Maschinen unterscheidet sich grundlegend von Lösungen, die einen sogenannten Hypervisor (HV) verwenden. Dieser teilt zwar auch das System in mehrere virtuelle Maschinen auf, lässt diese aber getrennt von einander laufen, so dass sich keine implizite Synchronisation ergibt. Ebenso kann der HV nicht das Problem der sogenannten Shared-Ressources lösen, da er nicht über eine Hardware-Emulation verfügt, insbeson- dere über keine echtzeitfähige . Der Hypervisor des Standes der Technik partitioniert stattdessen das System und ordnet jede Peripherie eindeutig einer Partition zu, so dass diese von den Betriebssystemen der anderen Partitionen nicht mehr gesehen werden kann.
Die Ausführung der Erfindung ist nicht auf diese Anwendungsfälle und die weiter oben erwähnten Systemkonfigurati¬ onen beschränkt, sondern ebenso in einer Vielzahl von
Abwandlungen möglich, die im Rahmen fachgemäßen Handelns liegen. Ferner sollte darauf hingewiesen werden, dass
Bezugszeichen in den Ansprüchen nicht als beschränkend aufzufassen sind und dass die Begriffe "aufweisen" bzw. "aufweisend" und ähnliche Begriffe nicht das Vorhandensein von weiteren Elementen oder Schritten ausschließt. Auch schließt ein Aufzählen als mehrere Mittel oder Elemente nicht aus, dass diese Mittel oder Elemente als ein einziges Mittel oder Element ausgebildet werden können.
Bezugs zeichenliste
100 Host-System
101 Host Hardware
102- ■105 Cores
106 Host-Betriebssystem
107 Echtzeit-Timer
108 Hardware-Treiber
109 Host-Applikationen
110 Emulationsprozess
111 Virtuelle Maschine
200 Host-System
201 Virtuelle Maschine
202 Virtuelle Maschine
203 Feldbus Karte
204 Feldbus Karte
300 Host-System
301 Host Hardware
302- ■305 Cores
306 Host-Betriebssystem
307 Hardware-Treiber
308 Hardware-Treiber
309 Host-Applikationen
310 Emulationsprozess
311 Emulationsprozess
312 Virtuelle Maschine
313 Virtuelle Maschine

Claims

Patentansprüche
1. Host-System (100, 200) zum Bereitstellen einer echt- zeitfähigen virtuellen Maschine (111, 201, 202), wobei das Host-System (100, 200) aufweist:
einen Host (101, 201), welcher eine Mehrzahl von physikalischen Kernen (102, 103, 104, 105, 202, 203, 204, 205) aufweist ;
wobei auf dem Host ein Echtzeit-Betriebssystem (106) installiert ist.
2. Host-System (100, 200) gemäß Anspruch 1,
wobei das Host-System (100, 200) derart eingerichtet ist, dass ein Emulationsprozess (110) für eine echtzeitfä- hige virtuelle Maschine als Echtzeit-Prozess implementiert ist .
3. Host-System (100, 200) gemäß Anspruch 2,
wobei das Host-System (100, 200) derart eingerichtet ist, dass eine Zuordnung eines virtuellen Kerns zu einem der Mehrzahl von physikalischen Kernen (102-105, 202-205) statisch ist.
4. Host-System (100, 200) gemäß einem der Ansprüche 1 bis 3,
wobei das Host-System (100, 200) eingerichtet ist eine Mehrzahl von virtuellen Maschinen zu emulieren,
wobei die Mehrzahl von physikalischen Kernen (102-105, 202-205) größer oder gleich der Mehrzahl von virtuellen Maschinen ist.
5. Host-System (100, 200) gemäß einem der Ansprüche 1 bis 4, wobei das Host-System derart eingerichtet ist, dass ein Treiber für eine virtuelle Maschine als Echtzeit- Treiber auf dem Host implementiert ist.
6. Host-System (100, 200) gemäß einem der Ansprüche 1 bis 5,
wobei das Host-System derart eingerichtet ist, dass mittels ihm eine Mehrzahl von virtuellen Maschinen (111, 201, 202) bereitstellbar ist.
7. Host-System (100, 200) gemäß Anspruch 6,
wobei das Host-System derart eingerichtet ist, dass ein Echtzeit-Prozess pro Kern des Hosts unterstützbar ist.
8. Verfahren zum Betreiben eines Host-Systems (100, 200) für echtzeitfähige virtuelle Maschinen (111, 201, 202), wobei das Host-System eine Mehrzahl von physikalischen Kernen (102-105, 202-205) aufweist, wobei das Verfahren aufweist :
Betreiben eines Echtzeit-Betriebssystems (110) auf dem
Host-System.
9. Verfahren gemäß Anspruch 8, welches ferner aufweist:
Starten eines Emulationsprozesses (110) für eine vir- tuelle Maschine (111, 201, 202), wobei in dem Emulations- prozess (110) eine Zuordnung eines virtuellen Kernes zu einem der Mehrzahl von physikalischen Kernen (102-105, 202- 205) festgeschrieben wird.
10. Verfahren gemäß Anspruch 8 oder 9, wobei das Verfahren ferner aufweist:
Starten einer virtuellen Maschine,
wobei das Starten der virtuellen Maschine das Starten eines Echtzeit-Prozesses (107) auf dem Host-System auf- weist, welcher Echtzeit-Prozess der virtuellen Maschine zugeordnet ist.
11. Programmelement, welches derart eingerichtet ist, da es, wenn es auf einem Prozessor ausgeführt wird, ein Verfahren gemäß einem der Ansprüche 8 bis 10 steuert.
12. Computerlesbares Medium, auf welchem ein Computerpro gramm gespeichert ist, wobei das Computerprogramm derart eingerichtet ist, dass es, wenn es auf einem Prozessor ausgeführt wird, ein Verfahren gemäß einem der Ansprüche bis 10 steuert.
PCT/EP2011/057631 2011-05-11 2011-05-11 System und verfahren zum bereitstellen und betreiben von einer oder mehreren echzeitfähigen virtuellen maschinen auf einem mehrkern hoch-rechner WO2012152326A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/057631 WO2012152326A1 (de) 2011-05-11 2011-05-11 System und verfahren zum bereitstellen und betreiben von einer oder mehreren echzeitfähigen virtuellen maschinen auf einem mehrkern hoch-rechner

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/057631 WO2012152326A1 (de) 2011-05-11 2011-05-11 System und verfahren zum bereitstellen und betreiben von einer oder mehreren echzeitfähigen virtuellen maschinen auf einem mehrkern hoch-rechner

Publications (1)

Publication Number Publication Date
WO2012152326A1 true WO2012152326A1 (de) 2012-11-15

Family

ID=44626746

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/057631 WO2012152326A1 (de) 2011-05-11 2011-05-11 System und verfahren zum bereitstellen und betreiben von einer oder mehreren echzeitfähigen virtuellen maschinen auf einem mehrkern hoch-rechner

Country Status (1)

Country Link
WO (1) WO2012152326A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018004499A1 (en) * 2016-06-27 2018-01-04 Tusas- Turk Havacilik Ve Uzay Sanayii Anonim Sirketi A real time operation method
CN108255500A (zh) * 2017-12-14 2018-07-06 广东睿江云计算股份有限公司 一种基于cobbler的兼容虚拟化架构的操作系统自动安装方法
EP3444682A1 (de) * 2017-08-16 2019-02-20 Siemens Aktiengesellschaft Verfahren zum rechnergestützten koppeln eines verarbeitungsmoduls in ein modulares technisches system und modulares technisches system

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "TenAsys Real-time Hypervisor", 1 August 2006 (2006-08-01), pages 1 - 11, XP055018231, Retrieved from the Internet <URL:http://www.tenasys.com/support/files/TenAsysReal-timeHypervisorBackgrounder.pdf> [retrieved on 20120202] *
BILL ALEXANDER ET AL: "Architected for Performance - Virtualization Support on Nehalem and Westmere Processors", INTEL TECHNOLOGY JOURNAL, VOLUME 14, ISSUE 3, 2010, 1 September 2010 (2010-09-01), pages 84 - 103, XP055020418, ISBN: 978-1-93-405333-1, Retrieved from the Internet <URL:http://www.intel.com/technology/itj/2010/v14i3/pdfs/Architected_for_Performance_Virtualization_support.pdf> [retrieved on 20120227] *
JAN KISZKA: "Towards Linux as a Real-Time Hypervisor", 11TH REAL-TIME LINUX WORKSHOP ON 2009, SEPTEMBER 28 TO 30, IN DRESDEN, GERMANY, 28 September 2009 (2009-09-28), pages 1 - 10, XP055018265, Retrieved from the Internet <URL:http://old.lwn.net/lwn/images/conf/rtlws11/papers/proc/p18.pdf> [retrieved on 20120202] *
JUN ZHANG ET AL: "Performance analysis towards a KVM-Based embedded real-time virtualization architecture", COMPUTER SCIENCES AND CONVERGENCE INFORMATION TECHNOLOGY (ICCIT), 2010 5TH INTERNATIONAL CONFERENCE ON, IEEE, 30 November 2010 (2010-11-30), pages 421 - 426, XP031912968, ISBN: 978-1-4244-8567-3, DOI: 10.1109/ICCIT.2010.5711095 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018004499A1 (en) * 2016-06-27 2018-01-04 Tusas- Turk Havacilik Ve Uzay Sanayii Anonim Sirketi A real time operation method
EP3444682A1 (de) * 2017-08-16 2019-02-20 Siemens Aktiengesellschaft Verfahren zum rechnergestützten koppeln eines verarbeitungsmoduls in ein modulares technisches system und modulares technisches system
CN109407604A (zh) * 2017-08-16 2019-03-01 西门子股份公司 处理模块耦合入模块化技术系统的方法和模块化技术系统
CN108255500A (zh) * 2017-12-14 2018-07-06 广东睿江云计算股份有限公司 一种基于cobbler的兼容虚拟化架构的操作系统自动安装方法
CN108255500B (zh) * 2017-12-14 2020-12-15 广东睿江云计算股份有限公司 一种基于cobbler的兼容虚拟化架构的操作系统自动安装方法

Similar Documents

Publication Publication Date Title
EP2575002B1 (de) Verfahren und Virtualisierungssoftware für die Bereitstellung von unabhängigen Zeitquellen für virtuelle Laufzeitumgebungen
DE102019110023A1 (de) System mit programmierbarer Multi-Kontext-Beschleuniger-Schaltung
EP2575039B1 (de) Verfahren und Anordnung zur Nutzung einer Ressource einer Hardware-Plattform mit zumindest zwei virtuellen Maschinen
EP2642395B1 (de) Verfahren und Vorrichtung zum Ausführen von Workflow-Skripten
DE112013000369T5 (de) Verwaltung von Threads innerhalb einer Datenverarbeitungsumgebung
DE112012005146T5 (de) Verfahren und System zum Anwenden einer Programmkorrektur auf ein virtuelles Abbild
DE202012013448U1 (de) Prozessormodussperre
DE102012105068A1 (de) Beschleunigungseinrichtung mit Unterstützung für virtuelle Maschinen
EP3001313A1 (de) Verfahren zur Simulation eines Anwendungsprogramms eines elektronischen Steuergeräts auf einem Computer
WO2019219796A1 (de) Verfahren zur ereignisbasierten simulation eines systems
DE102016203808A1 (de) Verringern der Bevorrechtigung virtueller Maschinen in einer virtualisierten Umgebung
DE102020122714A1 (de) Techniken zum konfigurieren eines prozessors, um wie mehrere, separate prozessoren zu funktionieren
DE102006052757B4 (de) Verfahren zum Betrieb eines Automatisierungsgerätes mit einer Verarbeitungseinheit mit mehreren Verarbeitungskernen
WO2012152326A1 (de) System und verfahren zum bereitstellen und betreiben von einer oder mehreren echzeitfähigen virtuellen maschinen auf einem mehrkern hoch-rechner
DE112016005868T5 (de) Starten von Anwendungsprozessoren einer virtuellen Maschine
DE112017008307T5 (de) Systeme und verfahren zur effizienten unterbrechung von virtuellen maschinen
DE102020123181A1 (de) Techniken zum konfigurieren eines prozessors, um wie mehrere, separate prozessoren zu funktionieren
EP2685377B1 (de) Verfahren und Anordnung zur Synchronisierung von zwei auf einer Hardware-Plattform ablaufenden Prozessen
DE102013211266A1 (de) Aufrechterhalten der Bandbreiten-Servicequalität einer Hardware-Ressource über einen Hardware-Zähler
DE102016105381A1 (de) Gemeinsames Nutzen von Arbeitsspeicher durch Gäste
EP2521035B1 (de) Verfahren und Anordnung zur Konfigurierung einer Ressource für eine virtuelle Laufzeitumgebung
WO2011154020A1 (de) Rechenvorrichtung mit koordination des zugriffs auf einen internen speicher und betriebsverfahren
EP3021220A1 (de) Verfahren und Computer zum Zugriff eines Echtzeit-Betriebssystems auf einen AHCI-Controller
EP2575040A1 (de) Verfahren für die Verarbeitung von Unterbrechungsanforderungen eines Datenverarbeitungsgerätes und Virtualisierungssteuerung für ein Datenverarbeitungsgerät
DE102019209086B3 (de) Kraftfahrzeug-Computersystem mit Hypervisor sowie Kraftfahrzeug

Legal Events

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

Ref document number: 11723335

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11723335

Country of ref document: EP

Kind code of ref document: A1