Virtualization: what changed in the last decade
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 47 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/37959 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produzent |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
6
11
13
20
23
28
31
32
35
37
40
42
44
47
00:00
VirtualisierungHardwareSystemprogrammierungServerEmulatorSoftwareHardwareVirtuelle RealitätBitSystemtechnikCloud ComputingMathematikEmulatorTermVisualisierungFormale GrammatikVirtueller ServerAggregatzustandSoftwareentwicklerVirtuelle MaschineComputerarchitekturProgrammierumgebungPerspektiveComputerp-BlockTaskGrundraumServerProdukt <Mathematik>Migration <Informatik>QuaderOverhead <Kommunikationstechnik>TheoremFunktionalDreiSoftwareBaumechanikAbstraktionsebeneRelativitätstheorieKonfiguration <Informatik>HalbleiterspeicherWiederherstellung <Informatik>Prinzip der gleichmäßigen BeschränktheitGenerator <Informatik>Wald <Graphentheorie>Digital Equipment CorporationInterpretiererSurjektivitätInverser LimesDifferenz <Mathematik>FlächeninhaltKonstruktor <Informatik>BildschirmfensterSoftwarewartungComputeranimationVorlesung/Konferenz
05:28
SystemprogrammierungVirtualisierungComputerTeilmengeTheoremSchnittmengeMechanismus-Design-TheoriePhysikalisches SystemCyberspaceGamecontrollerCoprozessorComputerATMFokalpunktQuick-SortMAPTheoremSensitivitätsanalyseArithmetisches MittelStereometrieDifferenteOrdnung <Mathematik>Virtuelle MaschineTeilmengeVirtuelle RealitätÄhnlichkeitsgeometrieComputeranimation
07:23
VirtualisierungSystemprogrammierungHardwareExistenzsatzARM <Computerarchitektur>Kernel <Informatik>ZufallszahlenATMBinärdatenTranslation <Mathematik>p-BlockAbschattungSeitentabelleEmulatorIntelDatenstrukturRFIDKontrollstrukturCodeVirtuelle MaschineKernel <Informatik>MAPVisualisierungATMFunktionalPhysikalisches SystemTranslation <Mathematik>Mechanismus-Design-TheorieTopologieFahne <Mathematik>Einfacher RingHardwareRoutingVirtuelle RealitätGlobale OptimierungSchnittmengeGamecontrollerSoundverarbeitungAggregatzustandKontrollstrukturPerspektiveCodierungBitCASE <Informatik>Gesetz <Physik>GruppenoperationSeitentabelleReelle ZahlStrömungsrichtungNetzbetriebssystemDigitalisierungImplementierungWorkstation <Musikinstrument>TermAbschattungEmulatorVMware WorkstationÄhnlichkeitsgeometrieWurzel <Mathematik>p-BlockComputeranimation
16:37
RFIDDatenstrukturKontrollstrukturIntelSystemprogrammierungVirtualisierungWeb-SeiteAbschattungTabelleSoftwareSynchronisierungSeitentabelleMaßerweiterungTLB <Informatik>Hash-AlgorithmusZweiKonfigurationsdatenbankPhysikalismusHalbleiterspeicherVirtuelle RealitätFormale GrammatikVirtuelle MaschineSystem FVirtuelle AdresseMultiplikationsoperatorDreiecksfreier GraphVersionsverwaltungMapping <Computergraphik>AbschattungSeitentabelleMAPTranslation <Mathematik>Physikalischer EffektKonditionszahlAdressraumWeb-SeiteMathematikPerspektiveDatenstrukturNetzbetriebssystemATMQuaderKontextbezogenes SystemKontrollstrukturWurzel <Mathematik>CodeCoprozessorProgrammierungCyberspaceZeiger <Informatik>BefehlsprozessorWeg <Topologie>PunktEinfache GenauigkeitBitSpeicherabzugSynchronisierungTabelleSystemaufrufUmwandlungsenthalpieProzess <Informatik>TUNIS <Programm>Twitter <Softwareplattform>RoutingForcingCodierungSchedulingVisualisierungInformationGraphService providerPhysikalische TheorieARM <Computerarchitektur>Stabilitätstheorie <Logik>Metropolitan area networkComputeranimation
25:51
SystemprogrammierungBefehlsprozessorVirtualisierungEmulatorOperations ResearchFormation <Mathematik>VisualisierungQuellcodeSystem FVirtuelle RealitätQuick-SortVerkehrsinformationBefehlsprozessorNichtlinearer OperatorImplementierungKonditionszahlMultiplikationsoperatorSensitivitätsanalyseVirtuelle MaschineKernel <Informatik>Dreiecksfreier GraphEmulatorFamilie <Mathematik>CodierungBimodulSummierbarkeitElektronische PublikationSchlüsselverwaltungAggregatzustandWald <Graphentheorie>FunktionalAusnahmebehandlungTopologiePhysikalisches SystemSpieltheorieMultiplikationTreiber <Programm>BenutzerschnittstellenverwaltungssystemGamecontrollerTermProgrammierumgebungGrenzschichtablösungPunktwolkeLuenberger-BeobachterInterrupt <Informatik>Weg <Topologie>CodeBaum <Mathematik>Wurzel <Mathematik>ZweiDatenfeldEinfache GenauigkeitBitKontrollstrukturNetzbetriebssystemXMLComputeranimation
32:35
Prozessfähigkeit <Qualitätsmanagement>VirtualisierungFront-End <Software>GruppoidSystemprogrammierungHardwareHardwareVirtuelle RealitätPlastikkarteGraphikprozessorTheoretische PhysikWort <Informatik>Treiber <Programm>ComputerSoftwareFunktionalGeradeVisualisierungVirtuelle MaschineNetzbetriebssystemAbgeschlossene MengeAggregatzustandRechenschieberKugelZahlenbereichServerProgrammierumgebungFamilie <Mathematik>CASE <Informatik>Zentrische StreckungReelle ZahlMultiplikationsoperatorPunktwolkeEmulatorKontextbezogenes SystemKlasse <Mathematik>Wurzel <Mathematik>Interface <Schaltung>Nichtlinearer OperatorBasis <Mathematik>Puffer <Netzplantechnik>Elektronische PublikationInverser LimesVideokonferenzEinfacher RingImplementierungTelekommunikationClique <Graphentheorie>Einfache GenauigkeitMultiplikationSystem FPhysikalismusComputeranimation
38:54
HardwareSystemprogrammierungPunktSystemaufrufVirtuelle RealitätAdressraumGruppenoperationKonfiguration <Informatik>MultiplikationsoperatorSchnitt <Mathematik>AdditionKontextbezogenes SystemInverser LimesCASE <Informatik>VisualisierungPlastikkarteRechenschieberMechanismus-Design-TheorieFormale SpracheMigration <Informatik>BitSoftwareWarteschlangeGraphikprozessorHardwareTermUmwandlungsenthalpieRechter WinkelKlasse <Mathematik>Prozessfähigkeit <Qualitätsmanagement>Vorlesung/KonferenzBesprechung/Interview
42:03
SystemprogrammierungXML
Transkript: Englisch(automatisch erzeugt)
00:07
Hello, thank you for being here. My name is Hugo, I will be talking a little bit about hardware virtualization and what changed in the last decade. I'm a systems engineer at a small cloud provider called DigitalOcean.
00:26
Sorry, had to put this somewhere. So why do we virtualize hardware? Apart from the right answers that the CTOs and COs like server consolidation, faster
00:42
provisioning and faster recovery, from the geeky side some operational tasks became much easier. We can live migrate virtual servers between servers, we can have virtually zero downtime
01:02
maintenance, Windows, and visual machines are really nice environments. At least rebooting a VM is much faster than putting a normal computer. So I'll be talking a little bit about why hardware virtualization is useful, because
01:25
it's not exactly required, well nowadays it actually is. So, the easier way to virtualize is just emulate everything, literally everything. We have instructions, we do instruction by instruction interpretation, all the hardware
01:49
state is emulating software, like RAM is just a block of allocated memory, registers are just variables, and so on and so on.
02:03
This is extremely simple, it could be easy enough to be a university assignment if you are not implementing a CSC instruction set at least. But it's really slow, really really slow. Nevertheless it's very useful for development.
02:23
The most famous emulator is probably Box that started in 94 and the last commit was one day ago, so I believe people are still using it.
02:41
So instruction by instruction emulation is actually not feasible in the production environment, because we expect the down speed to be not that significant.
03:00
So there are faster ways to virtualize even without hardware support. But first let's make a little detour. Who here heard about the term Virtual Machine Monitor?
03:24
Interesting. Any idea in which decade that term was coined? Yep. So in the 70s, actually in 74, Popek and Goldberg wrote a paper with the title Formal
03:46
Requirements for Virtualizable Third-Generation Architectures. The paper abstract mentioned things like PDP-10 and IBM 360.
04:02
Popek and Goldberg in this paper established the base requirements to consider a Virtual Machine Monitor. So fidelity is just that the behavior from the guest's perspective should be similar
04:24
to the host's perspective. And the guest is not supposed to understand or perceive in any way that it's a guest that is a virtualized thing. Performance is a little bit subjective here, but in the paper it was very obvious that
04:44
it meant that emulation or plain emulation was not an option. So the visualization overhead was supposed to be close to neglectable. And safety I guess is obvious.
05:03
The guest VMs must coexist between each other and should not interfere with the Virtual Machine Monitor and with the resources that they don't have access to or that they are not supposed to have access to.
05:23
So these are the requirements. Popek and Goldberg also in the same paper came up with a couple of theorems. We are going to put our focus in the first theorem and it is for any conventional third-generation computer, a Virtual Machine Monitor may be constructed if the set of
05:42
sensitive instructions for that computer is a subset of the set of privileged instructions. So my question about this was, what is a third-generation computer? Since this paper was written in the 70s, well, different expectations, but this is also
06:02
made very explicit in the paper. It should have some sort of relocation mechanism, which makes sense because similar VMs are supposed to share the same space. The instruction set is expected to have different privilege levels, so a supervisor
06:25
and the user mode. And a trap mechanism or set of trap mechanisms are also required. Now, what is the meaning of sensitive instructions and privileged instructions?
06:46
So privileged instructions are those that trap if the processor is in user mode and do not trap in system mode or in supervisor mode. And sensitive instructions when trapped must pass a control to the Virtual Machine Monitor.
07:11
And now the suggestion or the proposed way of virtualizing Virtual Machines is nowadays
07:21
called classic virtualization. And the concept is very, very simple. We are supposed to directly execute the safe instructions and by safe we mean that they don't interfere with the Virtual Machine Monitor or any other VMs.
07:44
And we are expected to trap and emulate the privileged instructions. Now, how does this apply to hardware?
08:00
Curiosity. Is any of you going to Prague next week? Okay, this might be safe then. Will you be attending Embedded Linux Conf? Okay, so about hardware. ARM exists, but we'll be ignoring it for today and this is going to be very specific to Intel.
08:30
I'm not going to mention AMD, they have very similar visualization capabilities even if they are incompatible at the instruction set level.
08:45
So, how this classical virtualization could work on x86? So, x86 already has four privilege levels, which is very useful.
09:01
Those privilege levels go from ring 0 to ring 3. Ring 0 is the actual privilege levels and rings 1 to 3 are not privileged. This means that if we try to execute privileged instructions on rings 1 to 3,
09:22
it will trap and the Virtual Machine Monitor will regain control. And when that happens, it is supposed to emulate the instruction that actually caused the trap and give control back to the virtualized OS. So, from the privilege levels perspective or rings, the Virtual Machine Monitor
09:47
and possibly the operating system kernel runs on ring 0, so in real privilege mode. The user runs on ring 3 and a virtualized OS could run on ring 1.
10:05
Probably the virtualized OS that we don't know which OS could be would use ring 3 as well to run its userland code.
10:20
I should mention that in terms of data access, ring 0 has access to everything. Ring 1 has access to or can see and access the data in the rings to entry and so on.
10:40
So, let's pick a random x86 instruction. Okay, it is not really random. Pop flags. Pop flags is a very interesting instruction because when we run it in privileged mode, it changes the ALU and the system flags
11:05
and when we run it in non-privileged mode, only the ALU is changed. So, its behavior depends on the current privilege level, which makes it challenging
11:21
because there is no way for the Virtual Machine Monitor to intercept its execution and the ideal scenario would be the execution would be intercepted by the VMM to check the guest's current privilege level and it would either emulate it in privileged mode
11:44
or non-privileged mode from the guest perspective. But since this instruction doesn't trap, that is not possible. x86 has in total 17 non-privileged sensitive instructions,
12:03
which means they don't actually trap and we would expect it to, at least for a classical virtualization to work. Additionally, the guest operating system can easily know if it is being virtualized or not
12:28
because the privilege level is stored in the two lower bits in the CS register. So, this is bad news because this means that x86 can't be classically virtualized
12:45
without hardware support. However, we have been using fast emulators way before having hardware virtualization available and this has been done by doing binary translation.
13:09
The idea is extremely simple. The implementation is actually not that simple. But the idea is that there is a mechanism inside the VMM
13:22
that dynamically translates the sensitive instructions so they cause a trap and the Virtual Machine Monitor instead of running those instructions directly emulates their behavior
13:47
and mimics the side effects of that execution to the guest. As an optimization and a required optimization, the translated blocks have to be cached, which sounds simple but is actually not simple when we consider corner cases
14:05
like self-modifying code. We need a few things like shadow page tables. I'm going to talk a little bit about this in a few minutes.
14:22
All the IO is emulated as well. So, it's not trivial but it was a fast solution for some years. I guess the first actual working Virtual Machine Monitor using binary translation
14:42
that was really fast was a VMware workstation that was released in 1999 or 2000. Eventually, a few years later, 2005 or 2006, Intel started adding support for hardware virtualization.
15:07
And what they did was adding a new mode of execution that is called, by then, root mode.
15:21
And the Virtual Machine Monitor would run in root mode and the guests would run in non-root mode. The guests would be totally unaware about their execution mode.
15:40
Actually, Intel VTX adds a new set of instructions and the guests wouldn't be able to run any of those new instructions without trapping back into the VMM. Except one actually, but not important for now.
16:05
The guests are totally unaware about what's going on. They just run their code and they don't need to do anything else. Now, how VTX actually works. Each guest has its own control structure that has all the state and a little bit more.
16:30
The transitions between root and non-root mode are atomic. The Virtual Machine Monitor has a very simple job.
16:43
It creates a VM control structure. It's not a trivial structure, but it fills things like the initial guest state, how the registers look like. It has to provide some memory space context.
17:05
Then it sets a program counter and it just launches the VM. And when it launches the VM, the VM or the processor translates to non-root mode.
17:22
And it stays in non-root mode running the guest's code until a VM exit happens. The VMCS also specifies in which conditions a VM exit should happen.
17:47
And this makes things very interesting. We can easily fine-tune the guest to exit only in very specific conditions.
18:01
And I'm going to talk a little bit about what are the typical exit reasons. We can have multiple VMCSs, but in a single point in time there is only one active VMCS.
18:22
So a single core, and I'm talking about cores and not processors, because each core can have its own active VMCS. And in a single point in time, the core is either in root mode or in non-root mode.
18:41
If it's in non-root mode, it's running a guest. And once the VM exits back to root mode, the VMM might decide to schedule another different virtual machine to that same core. And it just points the VMCS pointer to another VMCS structure
19:07
and starts that virtual machine or resumes that virtual machine. In this graph, I'm using VM entry as a generalization of VM resume or VM start.
19:25
Actually, it's VM launch. We have an easy way to run guest code safely.
19:42
This can be considered a classic virtualization. We can easily emulate CPU. Now we need to talk about the MMU.
20:05
In the initial releases of VTX, or the initial one, the first one in 2006,
20:20
the MMU could not be virtualized. And that was bad, because there has to be something translating or managing the page tables. So the page tables are simply the mapping from virtual memory to physical memory.
20:45
But since we have a virtual machine inside something that is real, we need two layers of translation. So from the virtual machine, a virtual memory to the virtual machine physical memory.
21:06
But that physical memory seen by the virtual machine is actually virtual memory from the VMM's perspective. Then there is also the translation from the host level or the VMM level
21:22
from that virtual memory to actual physical memory. The solution for that was shadow page tables. This has lots of performance implications.
21:42
Shadow page tables consist of keeping the mapping in an optimal way. The guest operating system would be managing the page tables and everything would work out of the box.
22:02
But since there is no MMU virtualization, the VMM has to take the mappings provided from the guest operating system and map those mappings to actual physical memory
22:20
and use that as appointing the VMM's page table registry to that shadow page tables. This is going to make more sense in a second.
22:41
So this mapping has to be kept in sync. So every time that the page tables change on the guest, the VMM has to update the shadow page tables. This means that every time the page tables register changes on the guest,
23:05
it causes a VM exit and it gets worse than this. When a new memory page is added to page tables, the VMM has to keep track of changes to that page table.
23:26
This means that every time that we or the guest map something that changes in the specific page table, it also causes a VM exit.
23:41
This is lots of VM exits. I guess I should mention that every time that there is a context switch in the guest operating system, it causes the page tables register changes. Here I wrote CR3, I don't know why.
24:03
This is lots of VM exits. In the earlier versions of VDX, a VM exit VM resume would take around 4000 cycles, CPU cycles. In theory, we could measure a VM exit VM resume in microseconds, which is pretty uncool.
24:30
Eventually, MMU virtualization arrived. Intel called it extended page tables.
24:42
The formal name, fancy name is second level address translation. Some people also call them nested page tables. They were introduced in 2008, a couple of years after VDX first introduction.
25:00
It makes all the work for us. When TLB miss happens, it walks the guest page table entries and the host page table entries for us. That's all we wanted, right?
25:24
Obviously, that doesn't require as many VM exits as before. The guest manages its own page tables and that doesn't cause a VM exit.
25:40
The performance gains when compared to shadow page tables were very obvious. We are in 2008. The situation report. We have a really nice CPU virtualization. The MMU is guest friendly, so everything is awesome.
26:05
I still find this music extremely catchy. Sort of. There are multiple situations that can cause a VM exit.
26:22
The typical reasons are exceptions, CPU exceptions, external interrupts, the execution of root sensitive instructions, VDX instructions, IO instructions, lots of things. The VMM can avoid some of the exits because it can literally cherry-pick
26:52
plenty of conditions that trigger a VM exit, but some of them can't be ignored.
27:04
Usually, when a VM exit happens, the virtual machine monitor looks into the virtual machine control structure. It has a field exit reason. That exit reason is like an exit status code.
27:26
The VMM knows what triggers the exception, but usually that is not enough. That instruction has to be emulated and the guest state has to be updated somehow or something has to happen.
27:46
This means that to actually handle VM exits properly, we need to have x86 emulator in our VMM,
28:00
which are not very trivial. Curiosity. Any of you compiled x86 emulator in the last month? Interesting. Any of you compiled a kernel in the last month?
28:20
OK. Any of you compiled an x86 without knowing it in the last month? I guess you did. The KVM code that is in the kernel... I can talk a little bit about KVM.
28:41
The KVM code that we have in the kernel actually has a minimal emulator that handles VM exits successfully. The KVM module does most of the work for us
29:04
in terms of keeping track of the virtual machine state. There are different implementations. The Intel VTX has been improved over the years. Then there is this incompatible AMD implementation
29:24
and the KVM module handles all that for us. It is really simple to use. We just need to... There is a device file, a devkvm, and we can play with it using IO CTLs.
29:44
That is what QEMU uses. Now let's talk a little bit about IO. All the devices exposed to the guest are emulated.
30:00
Since one of the requirements is that the guest should be able to be a complete and modified system, we need to provide some device that the guest knows how to deal with. Usually this means providing or emulating very old devices like
30:29
Intel E1000 or RTL8139 or NE2000, because pretty much every operating system has built-in drivers for those devices.
30:44
The way IO works is actually very simple. When the guest does any IO operation, and it can be PIO or MMIO,
31:01
the VMM gains control emulates whatever is expected to happen from that emulated device and gives control back to the guest. This means that sometimes a single IO operation might require multiple VM exits,
31:29
mostly because we are emulating devices that were not thought to be used in a visualization environment.
31:42
So, high throughput is impossible in this scenario. This didn't used to be a big deal until a couple of years ago with the whole cloud boom. Mostly because even if you are a cloud provider,
32:01
you don't want to have a virtual machine spending 30% of its time in a cycle VM exit, VM resume, just because the user inside that guest is downloading a file at 5 megs per second.
32:21
Yes, it is that bad. A decade ago, I guess it was actually a couple of years ago, a smart guy called Russell suggested something called VirtIO
32:41
per virtualized IO. I remember I mentioned that we didn't want to change our guests, but this happened for a good reason. So, instead of emulating a full device, VirtIO just suggested that a very simple PCL device was enough,
33:09
and that would be okay for all or most of the device classes that we could have some interest in having access from the guest.
33:23
The way it works is very simple. There is a special device, the guest knows how to deal with it, and it exposes just one or n ring buffers, and those ring buffers are shared with the VMM,
33:42
and are used as a communication channel between the guest and the host. The VMM or the backend side of that device provides the actual IO operation. VirtIO became supported by multiple hypervisors,
34:00
and I guess any major operating system nowadays has VirtIO drivers, at least for network cards and probably something else, but I like network cards. This improved things significantly.
34:22
Performance-wise, it is still not as good as native hardware, but it was much better than having an emulated device. I guess one could easily reach a speedup of 20x network-wise, which was a lot.
34:44
Eventually, a higher hardware virtualization became a requirement. I don't have slides about this, so I'm going to do some talking. The basic functionality just allows the VMM to safely assign or dedicate a device to a virtual machine.
35:14
That by itself is not very useful, because it is useful if you want to play Quake in your VM,
35:22
in your desktop, using your graphics card. But in a cloud environment, usually the number of VMs scales much better than the number of devices that you have to actually assign.
35:45
Since the first implementation or release of a native hardware virtualization, things were already optimized, and we could get to a state where there were virtually no VM exits triggered by I.O.
36:11
There are a few tricks to make that happen and a few exceptions, but it was already technically possible. We could get to, for example, close to line speed network-wise,
36:25
and a new family of virtualized devices started appearing since then. This is not really that interesting with the whole cloud thingy today.
36:46
The PCI-C came with a really nice thing called Single Root I.O. Visualization.
37:02
It allows us to do things like safely assign a NIC to multiple VMs. I know that this is going to sound very weird to say it like this, but some specific NICs or any NIC that one can buy for a server nowadays supports SRIOV,
37:28
and it allows us to split that NIC into multiple virtual functions. This means that the NIC has the base physical function that we expect a network card to have,
37:44
but we can have secondary visual functions that can also function like network devices, but have some limitations, and those limitations exist to guarantee safety.
38:03
We can get NICs that support until 256 virtual functions, and we can assign a single NIC to a virtual machine, and those virtual machines have access to real hardware, and that's pretty cool.
38:25
I guess my time is pretty much over. So, virtualization is pretty cool, and that's all. Questions? No questions?
38:48
In the case of these virtualization-aware network interfaces, would each VM be assigned a different, let's say, MAC address? That's a very good question.
39:01
Okay, there are some options there, and there is also... I'm going to say yes, but the right answer is a little bit more complex than that. So, you can't just give direct access for a VM that you might or might not trust, give direct access to the wire to that VM.
39:21
So, most of the NIC brands, at least SolarFlare and Intel, support a mechanism to filter out and filter in the packets that pass through. So, that's called queue splitting,
39:41
and you are allowed to assign specific TX and RX queues to that PF. So, yeah, you can do whatever you want at L2, but there is safety there. Okay, thanks.
40:03
Oh, here. Are there other classes of devices in addition to network cards which can be used that way? Not that I'm aware of, actually. The entity that comes up with this is a PCI special interest group,
40:24
and every time that I start reading their specs, I kind of fall asleep. I mentioned network cards because that's something quite important for my company and it's something that I deal with daily.
40:42
I guess doing the same with GPUs would be pretty cool as well, but with NIC this doable now. Where are most of the remaining performance limitations in virtualization
41:05
or where is most of the work happening in terms of optimizing for performance? Right now, with hardware IO virtualization,
41:21
you can get very close to native performance, and at that point it's mostly about the drawbacks. For example, by doing IO virtualization you lose some things like live migration,
41:40
and for some use cases that's quite important, but in terms of speed you can get very close to native. Thank you.