-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathvirtualisation_interactive.html
More file actions
498 lines (481 loc) · 37.5 KB
/
Copy pathvirtualisation_interactive.html
File metadata and controls
498 lines (481 loc) · 37.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Virtualisation — Hyperviseurs, KVM, ESXi, Hyper-V, Proxmox</title>
<style>
:root{--bg:#f8fafc;--card:#fff;--border:#e2e8f0;--text:#1e293b;--muted:#64748b;--acc:#4f46e5;--acc2:#4338ca;--blue600:#2563eb;--green:#16a34a;--red:#dc2626;--orange:#ea580c;--purple:#7c3aed;--grad1:#1e1b4b;--grad2:#312e81}
@media(prefers-color-scheme:dark){:root{--bg:#0d0d0d;--card:#1a1a1a;--border:#2a2a2a;--text:#e2e8f0;--muted:#94a3b8}}
*{box-sizing:border-box;margin:0;padding:0}
body{font-family:'Segoe UI',system-ui,sans-serif;background:var(--bg);color:var(--text);line-height:1.6}
header{background:linear-gradient(135deg,var(--grad1),var(--grad2));padding:2rem 1rem;text-align:center;border-bottom:2px solid var(--acc)}
header h1{font-size:2rem;font-weight:800;color:#fff}
header p{color:#a5b4fc;margin-top:.4rem;font-size:.95rem}
nav{position:sticky;top:0;z-index:100;background:var(--card);border-bottom:1px solid var(--border);padding:.5rem 1rem;display:flex;gap:.5rem;flex-wrap:wrap;justify-content:center}
.tab-btn{padding:.4rem 1rem;border:none;border-radius:999px;cursor:pointer;font-size:.85rem;font-weight:600;background:var(--border);color:var(--muted);transition:all .2s}
.tab-btn.active{background:var(--blue600);color:#fff}
.tab-btn:hover:not(.active){background:var(--acc);color:#fff}
section{display:none;max-width:1100px;margin:0 auto;padding:1.5rem 1rem}
section.active{display:block}
h2{font-size:1.4rem;font-weight:700;margin-bottom:1rem;color:var(--acc)}
h3{font-size:1.1rem;font-weight:600;margin:1.2rem 0 .6rem}
.grid{display:grid;gap:1rem}.g2{grid-template-columns:repeat(auto-fit,minmax(280px,1fr))}.g3{grid-template-columns:repeat(auto-fit,minmax(220px,1fr))}
.card{background:var(--card);border:1px solid var(--border);border-radius:.75rem;padding:1.2rem}
.card h4{font-size:1rem;font-weight:700;margin-bottom:.5rem;color:var(--acc)}
.codeblk{background:#1e1e2e;color:#cdd6f4;border-radius:.5rem;padding:1rem;font-family:'Cascadia Code','Fira Code',monospace;font-size:.82rem;overflow-x:auto;margin:.5rem 0;line-height:1.7;white-space:pre-wrap}
.c-kw{color:#89b4fa}.c-str{color:#a6e3a1}.c-comment{color:#6c7086;font-style:italic}.c-val{color:#f9e2af}.c-fn{color:#cba6f7}.c-op{color:#94e2d5}
table{width:100%;border-collapse:collapse;font-size:.85rem;margin:.5rem 0}
th{background:var(--acc);color:#fff;padding:.5rem .75rem;text-align:left}
td{padding:.45rem .75rem;border-bottom:1px solid var(--border)}
tr:hover td{background:var(--border)}
.info-box{background:var(--card);border-left:4px solid var(--acc);border-radius:.5rem;padding:.8rem 1rem;margin:.5rem 0}
.info-box.green{border-color:var(--green)}.info-box.red{border-color:var(--red)}.info-box.blue{border-color:var(--blue600)}.info-box.orange{border-color:var(--orange)}.info-box.purple{border-color:var(--purple)}
.badge{display:inline-block;padding:.2rem .6rem;border-radius:999px;font-size:.75rem;font-weight:600;margin:.1rem}
.badge-blue{background:#dbeafe;color:#1d4ed8}.badge-green{background:#dcfce7;color:#15803d}
.badge-red{background:#fee2e2;color:#b91c1c}.badge-yellow{background:#fef3c7;color:#92400e}
.badge-purple{background:#ede9fe;color:#6d28d9}.badge-indigo{background:#e0e7ff;color:#3730a3}
@media(prefers-color-scheme:dark){.badge-blue{background:#1e3a5f;color:#93c5fd}.badge-green{background:#14532d;color:#86efac}.badge-red{background:#450a0a;color:#fca5a5}.badge-yellow{background:#451a03;color:#fcd34d}.badge-purple{background:#2e1065;color:#c4b5fd}.badge-indigo{background:#1e1b4b;color:#a5b4fc}}
.stack{display:flex;flex-direction:column;gap:.3rem;margin:.5rem 0}
.layer{border-radius:.4rem;padding:.5rem .8rem;font-size:.82rem;font-weight:600;text-align:center;color:#fff}
.layer.hw{background:#475569}.layer.hyp{background:var(--acc)}.layer.host{background:#0891b2}.layer.guest{background:var(--green)}.layer.app{background:var(--purple)}.layer.ring{background:#7c3aed}
.quiz-q{background:var(--card);border:1px solid var(--border);border-radius:.75rem;padding:1.2rem;margin:.8rem 0}
.quiz-q p{font-weight:600;margin-bottom:.7rem}
.quiz-opt{padding:.5rem .8rem;border:1px solid var(--border);border-radius:.4rem;margin:.3rem 0;cursor:pointer;transition:all .2s}
.quiz-opt:hover{border-color:var(--acc);background:rgba(79,70,229,.05)}
.quiz-opt.correct{background:#dcfce7;border-color:var(--green);color:#166534}
.quiz-opt.wrong{background:#fee2e2;border-color:var(--red);color:#991b1b}
@media(prefers-color-scheme:dark){.quiz-opt.correct{background:#14532d;color:#86efac}.quiz-opt.wrong{background:#450a0a;color:#fca5a5}}
#quiz-score{display:none;text-align:center;padding:1.5rem;background:var(--card);border-radius:.75rem;margin-top:1rem;font-size:1.1rem;font-weight:700}
</style>
</head>
<body>
<header>
<h1>Virtualisation</h1>
<p>Hyperviseurs Type 1/2, KVM/QEMU, VMware ESXi, Hyper-V, Proxmox — CPU, mémoire, I/O & sécurité</p>
</header>
<nav>
<button class="tab-btn active" onclick="showTab('overview')">Vue d'ensemble</button>
<button class="tab-btn" onclick="showTab('hypervisors')">Hyperviseurs</button>
<button class="tab-btn" onclick="showTab('cpumem')">CPU & Mémoire</button>
<button class="tab-btn" onclick="showTab('io')">I/O, Stockage & Réseau</button>
<button class="tab-btn" onclick="showTab('platforms')">Plateformes</button>
<button class="tab-btn" onclick="showTab('security')">VM, Conteneurs & Sécurité</button>
<button class="tab-btn" onclick="showTab('quiz')">Quiz</button>
</nav>
<section id="overview" class="active">
<h2>Vue d'ensemble</h2>
<div class="grid g2">
<div class="card">
<h4>Qu'est-ce que la virtualisation ?</h4>
<p style="font-size:.88rem;margin-bottom:.5rem">Abstraction des ressources physiques (CPU, RAM, stockage, réseau) pour faire tourner plusieurs systèmes d'exploitation isolés (les <strong>machines virtuelles</strong>) sur un même matériel. Une couche logicielle, l'<strong>hyperviseur</strong> (ou VMM, Virtual Machine Monitor), arbitre l'accès au matériel.</p>
<div class="info-box">
<strong>Principe de Popek & Goldberg (1974)</strong> : un VMM doit garantir l'<em>équivalence</em> (la VM se comporte comme le matériel réel), le <em>contrôle des ressources</em> et l'<em>efficacité</em> (la majorité des instructions s'exécutent directement sur le CPU).
</div>
</div>
<div class="card">
<h4>Pourquoi virtualiser ?</h4>
<ul style="font-size:.85rem;padding-left:1.2rem;line-height:1.9">
<li><strong>Consolidation</strong> : 1 serveur physique → N VM (taux d'usage CPU passe de ~10% à 60-80%)</li>
<li><strong>Isolation</strong> : panne/compromission d'une VM cloisonnée</li>
<li><strong>Densité & coûts</strong> : moins de matériel, d'énergie, d'espace</li>
<li><strong>Snapshots & clones</strong> : rollback, templates, dev/test</li>
<li><strong>Live migration</strong> : déplacer une VM sans coupure</li>
<li><strong>Indépendance matérielle</strong> : la VM est un fichier portable</li>
<li><strong>Base du cloud</strong> : IaaS = VM facturées à la demande</li>
</ul>
</div>
</div>
<div class="card" style="margin-top:1rem">
<h4>Les grandes familles de virtualisation</h4>
<table>
<tr><th>Type</th><th>Principe</th><th>Exemples</th><th>Performance</th></tr>
<tr><td><strong>Full virtualization</strong></td><td>Le guest n'est pas modifié ; instructions privilégiées émulées ou trappées</td><td>VMware (binary translation historique), VirtualBox</td><td>Bonne</td></tr>
<tr><td><strong>Paravirtualization</strong></td><td>Guest <em>modifié</em> (drivers/hypercalls) pour coopérer avec l'hyperviseur</td><td>Xen PV, drivers virtio, VMware Tools</td><td>Très bonne</td></tr>
<tr><td><strong>HW-assisted</strong></td><td>Le CPU expose un mode dédié (VT-x / AMD-V) ; le standard actuel</td><td>KVM, ESXi, Hyper-V, Xen HVM</td><td>Quasi-native</td></tr>
<tr><td><strong>OS-level (conteneurs)</strong></td><td>Pas de VM : isolation par namespaces/cgroups, kernel <em>partagé</em></td><td>Docker, LXC, Podman</td><td>Native</td></tr>
<tr><td><strong>Émulation</strong></td><td>Simulation complète d'une autre architecture (lente)</td><td>QEMU (mode TCG), simulateurs ARM/RISC-V</td><td>Faible</td></tr>
</table>
<div class="info-box blue" style="margin-top:.5rem;font-size:.82rem">
On parle aussi de virtualisation du <strong>stockage</strong> (SAN/LUN, vSAN), du <strong>réseau</strong> (VLAN, VXLAN, SDN, NFV) et des <strong>applications/postes</strong> (VDI, App-V). Cette fiche se concentre sur la virtualisation <strong>serveur/système</strong>.
</div>
</div>
<div class="card" style="margin-top:1rem">
<h4>Modèle de privilèges CPU x86 — où s'insère l'hyperviseur</h4>
<div class="stack">
<div class="layer ring">Ring -1 — VMX root / hyperviseur (KVM, ESXi, Hyper-V)</div>
<div class="layer hyp">Ring 0 — Kernel du guest (croit être seul maître)</div>
<div class="layer guest">Ring 3 — Applications du guest</div>
</div>
<p style="font-size:.85rem;margin-top:.4rem">x86 définit 4 anneaux (0 = kernel, 3 = userland ; 1 et 2 inutilisés). Le problème historique : certaines instructions privilégiées <em>ne trappaient pas</em> en ring 0 non-root. Les extensions <strong>VT-x (Intel)</strong> et <strong>AMD-V</strong> ajoutent un mode « racine » (souvent appelé <em>ring -1</em>) où réside l'hyperviseur, résolvant proprement le problème.</p>
</div>
</section>
<section id="hypervisors">
<h2>Hyperviseurs — Type 1 vs Type 2</h2>
<div class="grid g2">
<div class="card">
<h4>Type 1 — « bare metal »</h4>
<div class="stack">
<div class="layer guest">VM 1</div>
<div class="layer guest">VM 2</div>
<div class="layer hyp">Hyperviseur (s'exécute directement)</div>
<div class="layer hw">Matériel</div>
</div>
<p style="font-size:.85rem;margin-top:.4rem">L'hyperviseur tourne <strong>directement sur le matériel</strong>, sans OS hôte sous-jacent. Performance et isolation maximales. Standard en datacenter et cloud.</p>
<p style="font-size:.85rem;margin-top:.3rem"><strong>Exemples :</strong> VMware ESXi, Microsoft Hyper-V, KVM (techniquement un module du kernel Linux), Xen, Nutanix AHV, Proxmox VE.</p>
</div>
<div class="card">
<h4>Type 2 — « hosted »</h4>
<div class="stack">
<div class="layer guest">VM 1</div>
<div class="layer hyp">Hyperviseur (application)</div>
<div class="layer host">OS hôte (Windows/macOS/Linux)</div>
<div class="layer hw">Matériel</div>
</div>
<p style="font-size:.85rem;margin-top:.4rem">L'hyperviseur est une <strong>application</strong> au-dessus d'un OS classique. Pratique sur poste de travail (dev, test, labos), overhead un peu supérieur.</p>
<p style="font-size:.85rem;margin-top:.3rem"><strong>Exemples :</strong> VirtualBox, VMware Workstation/Fusion, QEMU seul, Parallels Desktop, UTM (macOS).</p>
</div>
</div>
<div class="info-box orange" style="margin-top:1rem;font-size:.83rem">
<strong>La frontière est floue :</strong> KVM transforme un noyau Linux complet en hyperviseur Type 1, mais bénéficie de tout l'OS Linux autour. De même Hyper-V, une fois activé, fait passer le Windows hôte « au-dessus » de l'hyperviseur dans une partition parente. La classification Type 1/2 est utile mais pas absolue.
</div>
<div class="card" style="margin-top:1rem">
<h4>Comparatif des principaux hyperviseurs</h4>
<table>
<tr><th>Hyperviseur</th><th>Type</th><th>Base</th><th>Licence</th><th>Gestion</th><th>Cas d'usage</th></tr>
<tr><td><strong>VMware ESXi</strong></td><td>1</td><td>VMkernel propriétaire</td><td>Commercial (Broadcom)</td><td>vCenter</td><td>Entreprise, leader historique</td></tr>
<tr><td><strong>KVM</strong></td><td>1</td><td>Module kernel Linux + QEMU</td><td>GPL (libre)</td><td>libvirt, oVirt, OpenStack</td><td>Cloud (AWS, GCP), Linux</td></tr>
<tr><td><strong>Hyper-V</strong></td><td>1</td><td>Windows hypervisor</td><td>Inclus Windows / gratuit</td><td>Hyper-V Manager, SCVMM</td><td>Écosystème Microsoft, Azure</td></tr>
<tr><td><strong>Proxmox VE</strong></td><td>1</td><td>Debian + KVM + LXC</td><td>Libre (support payant)</td><td>Web UI intégrée</td><td>PME, homelab, alternative VMware</td></tr>
<tr><td><strong>Xen</strong></td><td>1</td><td>Microkernel Xen + dom0</td><td>GPL (libre)</td><td>XCP-ng / Xen Orchestra</td><td>Citrix, AWS (historique), Qubes OS</td></tr>
<tr><td><strong>Nutanix AHV</strong></td><td>1</td><td>KVM modifié</td><td>Commercial</td><td>Prism</td><td>HCI (hyperconvergé)</td></tr>
<tr><td><strong>VirtualBox</strong></td><td>2</td><td>App multiplateforme</td><td>GPL + ext pack PUEL</td><td>GUI / VBoxManage</td><td>Poste de travail, dev</td></tr>
<tr><td><strong>VMware Workstation/Fusion</strong></td><td>2</td><td>App Windows/Linux/macOS</td><td>Gratuit (depuis 2024)</td><td>GUI</td><td>Dev, démonstrations</td></tr>
</table>
<div class="info-box red" style="margin-top:.5rem;font-size:.82rem">
<strong>Contexte 2026 :</strong> le rachat de VMware par Broadcom (2023) et la refonte des licences (suppression des éditions perpétuelles, bundles par cœur) ont déclenché une vague de migration vers <strong>Proxmox VE</strong>, <strong>XCP-ng</strong>, Hyper-V et les solutions HCI.
</div>
</div>
</section>
<section id="cpumem">
<h2>Virtualisation du CPU & de la mémoire</h2>
<div class="grid g2">
<div class="card">
<h4>Extensions matérielles CPU</h4>
<table>
<tr><th>Techno</th><th>Constructeur</th><th>Rôle</th></tr>
<tr><td>VT-x (VMX)</td><td>Intel</td><td>Modes root / non-root, VMCS, VMENTER/VMEXIT</td></tr>
<tr><td>AMD-V (SVM)</td><td>AMD</td><td>Équivalent, VMCB, VMRUN</td></tr>
<tr><td>EPT</td><td>Intel</td><td>Extended Page Tables (SLAT)</td></tr>
<tr><td>NPT / RVI</td><td>AMD</td><td>Nested Page Tables (SLAT)</td></tr>
<tr><td>VT-d / AMD-Vi</td><td>Intel / AMD</td><td>IOMMU — passthrough & isolation DMA</td></tr>
<tr><td>APICv / AVIC</td><td>Intel / AMD</td><td>Virtualisation de l'APIC (interruptions)</td></tr>
</table>
<div class="info-box" style="margin-top:.4rem;font-size:.82rem">
Le guest tourne en mode <strong>non-root</strong>. Une instruction sensible (I/O, accès registre de contrôle…) provoque un <strong>VMEXIT</strong> qui rend la main à l'hyperviseur, qui traite puis fait un <strong>VMENTER</strong>. Réduire le nombre de VMEXIT = optimiser les perfs.
</div>
</div>
<div class="card">
<h4>SLAT — traduction d'adresses à 2 niveaux</h4>
<p style="font-size:.85rem;margin-bottom:.5rem">Sans assistance, l'hyperviseur devait maintenir des <em>shadow page tables</em> (coûteux). <strong>EPT (Intel)</strong> / <strong>NPT (AMD)</strong> ajoutent une 2ᵉ traduction matérielle :</p>
<div class="codeblk"><span class="c-comment"># Double traduction d'adresse</span>
Virtuelle guest (GVA)
│ page tables du guest
▼
Physique guest (GPA)
│ EPT / NPT (matériel)
▼
Physique hôte (HPA)</div>
<p style="font-size:.83rem;margin-top:.3rem">Gain majeur : plus besoin de trapper chaque modification de table de pages du guest. Coût : un « TLB miss » peut nécessiter un <em>2D page walk</em> plus long → d'où l'intérêt des <strong>huge pages</strong>.</p>
</div>
</div>
<div class="grid g2" style="margin-top:1rem">
<div class="card">
<h4>Ordonnancement des vCPU</h4>
<ul style="font-size:.85rem;padding-left:1.2rem;line-height:1.9">
<li><strong>vCPU</strong> = thread ordonnancé par l'hyperviseur sur les cœurs physiques (pCPU)</li>
<li><strong>Overcommit CPU</strong> : on peut allouer plus de vCPU que de cœurs physiques (ratio courant 3:1 à 8:1 selon la charge)</li>
<li><strong>CPU ready / steal time</strong> : temps où un vCPU veut tourner mais attend un pCPU — symptôme de surengagement</li>
<li><strong>Co-scheduling</strong> : une VM à 8 vCPU peut devoir attendre 8 pCPU libres simultanément → éviter le sur-dimensionnement</li>
<li><strong>NUMA</strong> : aligner vCPU et RAM sur le même nœud NUMA (vNUMA) pour éviter les accès mémoire distants</li>
<li><strong>Affinité / pinning</strong> : épingler des vCPU sur des pCPU (latence faible, temps réel)</li>
</ul>
</div>
<div class="card">
<h4>Gestion mémoire & overcommit</h4>
<table>
<tr><th>Technique</th><th>Description</th></tr>
<tr><td><strong>Ballooning</strong></td><td>Un driver dans le guest « gonfle » pour rendre de la RAM à l'hôte sous pression</td></tr>
<tr><td><strong>TPS / KSM</strong></td><td>Transparent Page Sharing (VMware) / Kernel Same-page Merging (Linux) — déduplication des pages identiques</td></tr>
<tr><td><strong>Memory compression</strong></td><td>Compresser des pages avant de swapper</td></tr>
<tr><td><strong>Swapping hôte</strong></td><td>Dernier recours, très pénalisant (le guest l'ignore)</td></tr>
<tr><td><strong>Huge pages</strong></td><td>Pages 2 Mo / 1 Go — moins d'entrées TLB, accélère le 2D page walk</td></tr>
<tr><td><strong>Reservation / limit / shares</strong></td><td>Garantir, plafonner, ou pondérer la RAM par VM</td></tr>
</table>
<div class="info-box red" style="margin-top:.4rem;font-size:.82rem">
KSM/TPS améliore la densité mais a ouvert des canaux auxiliaires (attaques par déduplication, type <em>Rowhammer</em>/cross-VM). VMware a désactivé le TPS inter-VM par défaut depuis 2014.
</div>
</div>
</div>
<div class="card" style="margin-top:1rem">
<h4>Vérifier le support matériel (Linux)</h4>
<div class="codeblk"><span class="c-comment"># Le CPU supporte-t-il la virtualisation ?</span>
grep -E -o <span class="c-str">'(vmx|svm)'</span> /proc/cpuinfo | sort -u
<span class="c-comment"># vmx = Intel VT-x, svm = AMD-V</span>
<span class="c-comment"># IOMMU activée ? (pour le passthrough)</span>
dmesg | grep -e DMAR -e IOMMU
<span class="c-comment"># KVM est-il chargé et utilisable ?</span>
lsmod | grep kvm
kvm-ok <span class="c-comment"># paquet cpu-checker (Debian/Ubuntu)</span>
<span class="c-comment"># Virtualisation imbriquée (nested) activée ?</span>
cat /sys/module/kvm_intel/parameters/nested <span class="c-comment"># Y = oui</span></div>
</div>
</section>
<section id="io">
<h2>I/O, Stockage & Réseau virtualisés</h2>
<div class="card">
<h4>3 façons de présenter un périphérique à une VM</h4>
<table>
<tr><th>Approche</th><th>Principe</th><th>Performance</th><th>Exemples</th></tr>
<tr><td><strong>Émulation</strong></td><td>L'hyperviseur simule un vrai matériel connu (le guest utilise son driver standard)</td><td>Faible (beaucoup de VMEXIT)</td><td>e1000, IDE, AC97, carte SVGA</td></tr>
<tr><td><strong>Paravirtualisé</strong></td><td>Driver « conscient » de la virtualisation, file partagée hôte/guest</td><td>Élevée</td><td>virtio-net, virtio-blk, virtio-scsi, VMXNET3, PVSCSI</td></tr>
<tr><td><strong>Passthrough</strong></td><td>Le matériel physique est assigné directement à la VM (via IOMMU)</td><td>Native</td><td>PCI passthrough, GPU passthrough, SR-IOV</td></tr>
</table>
</div>
<div class="grid g2" style="margin-top:1rem">
<div class="card">
<h4>virtio — le standard paravirtualisé</h4>
<p style="font-size:.85rem;margin-bottom:.5rem">Spécification ouverte (OASIS) d'interfaces paravirtualisées entre guest et hôte, via des anneaux (<em>virtqueues</em>) en mémoire partagée. Pilier de KVM/QEMU.</p>
<ul style="font-size:.85rem;padding-left:1.2rem;line-height:1.8">
<li><strong>virtio-net</strong> — carte réseau</li>
<li><strong>virtio-blk</strong> / <strong>virtio-scsi</strong> — disques</li>
<li><strong>virtio-balloon</strong> — gestion mémoire</li>
<li><strong>virtio-gpu</strong> — affichage</li>
<li><strong>vhost-net / vhost-user</strong> — datapath déporté dans le kernel ou en userspace (DPDK) pour le très haut débit</li>
</ul>
<div class="info-box orange" style="margin-top:.4rem;font-size:.82rem">
Windows ne fournit pas les drivers virtio nativement → installer le paquet <strong>virtio-win</strong> (ISO Fedora/Proxmox) lors de l'installation du guest.
</div>
</div>
<div class="card">
<h4>Passthrough & SR-IOV</h4>
<p style="font-size:.85rem;margin-bottom:.4rem"><strong>PCI passthrough (VFIO)</strong> : assigne un périphérique PCIe entier à une VM, isolé par l'IOMMU et son <em>groupe IOMMU</em>. Usage : GPU, carte réseau dédiée, contrôleur.</p>
<p style="font-size:.85rem;margin-bottom:.4rem"><strong>SR-IOV</strong> (Single Root I/O Virtualization) : une carte physique (PF — Physical Function) expose plusieurs <strong>VF</strong> (Virtual Functions) légères, chacune assignable à une VM. Débit quasi-natif sans saturer le CPU hôte.</p>
<p style="font-size:.85rem"><strong>vGPU</strong> (NVIDIA vGPU, Intel GVT-g, AMD MxGPU) : partage d'un GPU entre plusieurs VM, clé pour le VDI et l'IA.</p>
<div class="info-box red" style="margin-top:.4rem;font-size:.82rem">
Le passthrough sacrifie la <strong>live migration</strong> (l'état du matériel physique n'est pas migrable simplement) et exige des groupes IOMMU propres.
</div>
</div>
</div>
<div class="grid g2" style="margin-top:1rem">
<div class="card">
<h4>Formats de disque virtuel</h4>
<table>
<tr><th>Format</th><th>Plateforme</th><th>Caractéristiques</th></tr>
<tr><td><strong>raw</strong></td><td>KVM/QEMU</td><td>Image brute, perf max, pas de fonctionnalités</td></tr>
<tr><td><strong>qcow2</strong></td><td>QEMU</td><td>Thin, snapshots, compression, chiffrement, backing files</td></tr>
<tr><td><strong>VMDK</strong></td><td>VMware</td><td>Thin/thick, descriptor + extents</td></tr>
<tr><td><strong>VHDX</strong></td><td>Hyper-V</td><td>Jusqu'à 64 To, resilient, dynamic</td></tr>
<tr><td><strong>VDI</strong></td><td>VirtualBox</td><td>Format natif VBox</td></tr>
<tr><td><strong>OVA/OVF</strong></td><td>Standard (DMTF)</td><td>Paquet d'export/import portable d'une VM</td></tr>
</table>
<div class="info-box blue" style="margin-top:.4rem;font-size:.82rem">
<strong>Thin provisioning</strong> : le disque ne consomme que l'espace réellement écrit. <strong>Thick eager-zeroed</strong> : pré-alloué et zéroé (meilleures perfs, requis pour certains clusters).
</div>
</div>
<div class="card">
<h4>Réseau virtuel</h4>
<table>
<tr><th>Mode</th><th>Description</th></tr>
<tr><td><strong>Bridge</strong></td><td>La VM est sur le même L2 que l'hôte (IP de la LAN)</td></tr>
<tr><td><strong>NAT</strong></td><td>La VM partage l'IP de l'hôte vers l'extérieur</td></tr>
<tr><td><strong>Host-only / interne</strong></td><td>Réseau privé hôte ↔ VM, pas d'accès externe</td></tr>
<tr><td><strong>vSwitch</strong></td><td>Commutateur virtuel (vSwitch standard/distribué VMware, Open vSwitch, Hyper-V vSwitch)</td></tr>
<tr><td><strong>Overlay</strong></td><td>VXLAN/Geneve pour étendre des réseaux L2 sur L3 (SDN, NSX, OVN)</td></tr>
</table>
<div class="codeblk" style="margin-top:.4rem"><span class="c-comment"># Bridge Linux pour VM (netplan/ip)</span>
ip link add br0 type bridge
ip link set eth0 master br0
ip link set br0 up
<span class="c-comment"># puis attacher la VM (virtio-net) sur br0</span></div>
</div>
</div>
</section>
<section id="platforms">
<h2>Plateformes en pratique</h2>
<div class="grid g2">
<div class="card">
<h4>KVM / QEMU / libvirt</h4>
<p style="font-size:.85rem;margin-bottom:.4rem">La pile open source de référence : <strong>KVM</strong> (module kernel = accélération), <strong>QEMU</strong> (émulation des périphériques + machine), <strong>libvirt</strong> (API/daemon de gestion, outil <code>virsh</code>).</p>
<div class="codeblk"><span class="c-comment"># Créer une VM (virt-install)</span>
virt-install --name vm1 --memory <span class="c-val">4096</span> --vcpus <span class="c-val">2</span> \
--disk size=<span class="c-val">40</span>,format=qcow2 \
--cdrom /iso/debian.iso --os-variant debian12 \
--network bridge=br0,model=virtio
<span class="c-comment"># Gérer le cycle de vie</span>
virsh list --all
virsh start vm1
virsh shutdown vm1 <span class="c-comment"># ACPI propre</span>
virsh destroy vm1 <span class="c-comment"># force off</span>
virsh autostart vm1
<span class="c-comment"># Snapshots</span>
virsh snapshot-create-as vm1 snap1 <span class="c-str">"avant maj"</span>
virsh snapshot-revert vm1 snap1
<span class="c-comment"># Live migration vers un autre hôte</span>
virsh migrate --live vm1 qemu+ssh://host2/system
<span class="c-comment"># Image qcow2 à la main</span>
qemu-img create -f qcow2 disk.qcow2 <span class="c-val">40G</span>
qemu-img info disk.qcow2
qemu-img convert -O qcow2 src.vmdk dst.qcow2</div>
</div>
<div class="card">
<h4>Proxmox VE</h4>
<p style="font-size:.85rem;margin-bottom:.4rem">Distribution Debian intégrant <strong>KVM</strong> (VM) + <strong>LXC</strong> (conteneurs), une web UI, le clustering, la HA et le stockage (ZFS, Ceph). Alternative phare à VMware.</p>
<div class="codeblk"><span class="c-comment"># CLI Proxmox — VM (qm) et conteneurs (pct)</span>
qm create <span class="c-val">100</span> --name web --memory <span class="c-val">4096</span> \
--cores <span class="c-val">2</span> --net0 virtio,bridge=vmbr0
qm importdisk <span class="c-val">100</span> debian.qcow2 local-zfs
qm start <span class="c-val">100</span>
qm snapshot <span class="c-val">100</span> avant-maj
qm migrate <span class="c-val">100</span> node2 --online
<span class="c-comment"># Conteneur LXC</span>
pct create <span class="c-val">200</span> debian-12.tar.zst \
--rootfs local-zfs:<span class="c-val">8</span> --memory <span class="c-val">1024</span>
pct start <span class="c-val">200</span></div>
<div class="info-box green" style="margin-top:.4rem;font-size:.82rem">
Cluster Proxmox : <strong>Corosync</strong> pour le quorum, <strong>Ceph</strong> ou <strong>ZFS replication</strong> pour le stockage partagé, HA group pour le redémarrage automatique.
</div>
</div>
</div>
<div class="grid g2" style="margin-top:1rem">
<div class="card">
<h4>VMware vSphere</h4>
<p style="font-size:.85rem;margin-bottom:.4rem"><strong>ESXi</strong> = l'hyperviseur Type 1 ; <strong>vCenter</strong> = la console centrale qui orchestre plusieurs hôtes en cluster.</p>
<table>
<tr><th>Fonction</th><th>Rôle</th></tr>
<tr><td><strong>vMotion</strong></td><td>Live migration de VM sans coupure</td></tr>
<tr><td><strong>Storage vMotion</strong></td><td>Migration du stockage à chaud</td></tr>
<tr><td><strong>DRS</strong></td><td>Équilibrage automatique de charge dans le cluster</td></tr>
<tr><td><strong>HA</strong></td><td>Redémarre les VM d'un hôte tombé</td></tr>
<tr><td><strong>FT</strong></td><td>Fault Tolerance — VM miroir en temps réel</td></tr>
<tr><td><strong>vSAN</strong></td><td>Stockage distribué hyperconvergé</td></tr>
<tr><td><strong>NSX</strong></td><td>Virtualisation réseau (SDN, micro-segmentation)</td></tr>
</table>
</div>
<div class="card">
<h4>Hyper-V (Windows / Server)</h4>
<p style="font-size:.85rem;margin-bottom:.4rem">Hyperviseur Type 1 intégré à Windows. Concepts : <strong>partition parente</strong>, VM Gen 1 (BIOS) vs <strong>Gen 2</strong> (UEFI + Secure Boot), Integration Services, <strong>VMQ</strong>.</p>
<div class="codeblk"><span class="c-comment"># PowerShell Hyper-V</span>
New-VM -Name web -MemoryStartupBytes <span class="c-val">4GB</span> `
-Generation <span class="c-val">2</span> -NewVHDPath C:\vm\web.vhdx `
-NewVHDSizeBytes <span class="c-val">40GB</span> -SwitchName <span class="c-str">"vSwitch"</span>
Start-VM -Name web
Checkpoint-VM -Name web -SnapshotName <span class="c-str">"avant-maj"</span>
Move-VM web -DestinationHost host2 <span class="c-comment"># Live Migration</span></div>
<div class="info-box blue" style="margin-top:.4rem;font-size:.82rem">
<strong>Shielded VMs</strong> (chiffrées par vTPM + Host Guardian Service) et <strong>Failover Clustering</strong> + CSV/Storage Spaces Direct pour la HA.
</div>
</div>
</div>
</section>
<section id="security">
<h2>VM vs Conteneurs & Sécurité</h2>
<div class="card">
<h4>Machines virtuelles vs conteneurs</h4>
<table>
<tr><th>Aspect</th><th>VM</th><th>Conteneur</th></tr>
<tr><td>Isolation</td><td>Forte — kernel + matériel virtuel dédiés</td><td>Plus faible — kernel hôte partagé (namespaces/cgroups)</td></tr>
<tr><td>OS invité</td><td>Complet (n'importe lequel)</td><td>Aucun — juste le userland, même noyau que l'hôte</td></tr>
<tr><td>Overhead</td><td>Go de RAM, démarrage en secondes/minutes</td><td>Mo, démarrage en millisecondes</td></tr>
<tr><td>Densité</td><td>Dizaines par hôte</td><td>Centaines / milliers</td></tr>
<tr><td>Image</td><td>Disque virtuel (Go)</td><td>Layers superposés (Mo)</td></tr>
<tr><td>Surface d'attaque</td><td>Hyperviseur (petit)</td><td>Kernel partagé (large)</td></tr>
<tr><td>Usage idéal</td><td>OS hétérogènes, isolation forte, legacy</td><td>Microservices, scalabilité, CI/CD</td></tr>
</table>
<div class="info-box blue" style="margin-top:.5rem;font-size:.82rem">
Ce n'est pas « l'un ou l'autre » : en pratique on exécute souvent des <strong>conteneurs dans des VM</strong> (ex. nœuds Kubernetes virtualisés) pour cumuler densité et isolation.
</div>
</div>
<div class="grid g2" style="margin-top:1rem">
<div class="card">
<h4>MicroVM — le meilleur des deux mondes</h4>
<p style="font-size:.85rem;margin-bottom:.4rem">Concilier l'isolation matérielle d'une VM et la rapidité d'un conteneur, pour le multi-tenant et le serverless.</p>
<table>
<tr><th>Techno</th><th>Approche</th></tr>
<tr><td><strong>Firecracker</strong> (AWS)</td><td>MicroVM minimaliste (KVM, < 125 ms boot) — base de Lambda & Fargate</td></tr>
<tr><td><strong>Kata Containers</strong></td><td>Conteneurs OCI enveloppés dans une VM légère</td></tr>
<tr><td><strong>gVisor</strong> (Google)</td><td>Kernel applicatif en userspace interceptant les syscalls (pas une vraie VM)</td></tr>
<tr><td><strong>Cloud Hypervisor</strong></td><td>VMM Rust moderne (Intel/communauté)</td></tr>
</table>
</div>
<div class="card">
<h4>Live migration & snapshots</h4>
<ul style="font-size:.85rem;padding-left:1.2rem;line-height:1.85">
<li><strong>Live migration</strong> : copie itérative des pages mémoire (<em>pre-copy</em>) pendant que la VM tourne, puis bascule finale (downtime < 1 s). Variante <em>post-copy</em> pour les très grosses RAM.</li>
<li>Requiert un <strong>stockage partagé</strong> (ou une réplication) et des CPU compatibles (EVC chez VMware).</li>
<li><strong>Snapshot</strong> : état figé (disque ± RAM) à un instant t. Pratique avant une maj, <strong>mais</strong> les chaînes de delta longues dégradent les perfs et grossissent.</li>
<li>⚠️ Un snapshot <strong>n'est pas un backup</strong> : il dépend du disque source. Utiliser une vraie solution (Veeam, PBS, etc.).</li>
</ul>
</div>
</div>
<div class="card" style="margin-top:1rem">
<h4>Sécurité de la virtualisation</h4>
<div class="grid g2">
<div>
<h3 style="margin-top:0">Menaces</h3>
<ul style="font-size:.85rem;padding-left:1.2rem;line-height:1.8">
<li><strong>VM escape</strong> : sortir du guest vers l'hyperviseur/hôte — le pire scénario. Ex. historiques : <span class="badge badge-red">VENOM</span> (CVE-2015-3456, fdc QEMU), <span class="badge badge-red">Cloudburst</span>, bugs SVGA/virtio.</li>
<li><strong>Canaux auxiliaires cross-VM</strong> : Spectre/Meltdown, L1TF/Foreshadow, MDS, Rowhammer — fuite de données entre VM voisines.</li>
<li><strong>Vol/altération d'images</strong> de VM (fichiers disque = données au repos).</li>
<li><strong>Hyperjacking</strong> : rootkit s'insérant sous l'OS.</li>
<li><strong>VM sprawl</strong> : prolifération de VM non maintenues (surface d'attaque oubliée).</li>
</ul>
</div>
<div>
<h3 style="margin-top:0">Bonnes pratiques</h3>
<ul style="font-size:.85rem;padding-left:1.2rem;line-height:1.8">
<li>Patcher l'hyperviseur (microcode CPU inclus) en priorité</li>
<li>Réseau de <strong>management isolé</strong>, MFA sur vCenter/Proxmox/Hyper-V</li>
<li><strong>Secure Boot + vTPM</strong> dans les VM, disques chiffrés (VM Encryption, Shielded VMs)</li>
<li>Micro-segmentation réseau (NSX, vSwitch ACL)</li>
<li>Désactiver les fonctions inutiles (copier-coller, partage de dossiers, TPS inter-VM)</li>
<li>Limiter / auditer la <strong>nested virtualization</strong></li>
<li>Sauvegardes immuables hors-ligne + tests de restauration</li>
</ul>
</div>
</div>
<div class="info-box orange" style="margin-top:.5rem;font-size:.82rem">
<strong>Nested virtualization</strong> : faire tourner un hyperviseur <em>dans</em> une VM (utile pour les labos, WSL2, Hyper-V dans une VM cloud). Pratique mais accroît la surface d'attaque et l'overhead.
</div>
</div>
</section>
<section id="quiz">
<h2>Quiz — Virtualisation</h2>
<div id="quiz-container"></div>
<div id="quiz-score"></div>
</section>
<script>
function showTab(id){document.querySelectorAll('section').forEach(s=>s.classList.remove('active'));document.querySelectorAll('.tab-btn').forEach(b=>b.classList.remove('active'));document.getElementById(id).classList.add('active');event.target.classList.add('active')}
const quizData=[
{q:"Quelle est la différence fondamentale entre un hyperviseur de Type 1 et de Type 2 ?",opts:["Le Type 1 est payant, le Type 2 gratuit","Le Type 1 tourne directement sur le matériel, le Type 2 au-dessus d'un OS hôte","Le Type 1 ne fait que des conteneurs","Aucune"],a:1},
{q:"Quelles extensions CPU fournissent l'assistance matérielle à la virtualisation ?",opts:["SSE / AVX","VT-x (Intel) et AMD-V","TPM / SGX","Hyper-Threading"],a:1},
{q:"À quoi servent EPT (Intel) et NPT (AMD) ?",opts:["Chiffrer la RAM","Traduction d'adresse à 2 niveaux (SLAT) sans shadow page tables","Accélérer le réseau","Cloner les VM"],a:1},
{q:"Qu'est-ce que virtio ?",opts:["Un hyperviseur","Un format de disque","Un standard de drivers paravirtualisés (KVM/QEMU)","Un protocole réseau"],a:2},
{q:"Quel est le principal compromis du PCI passthrough / SR-IOV ?",opts:["Plus lent qu'une carte émulée","On perd la live migration simple","Consomme plus de RAM","Incompatible avec Linux"],a:1},
{q:"Que fait le ballooning mémoire ?",opts:["Compresse le disque","Un driver dans le guest rend de la RAM à l'hôte sous pression","Double la RAM physique","Chiffre la mémoire"],a:1},
{q:"Quel format de disque QEMU supporte thin provisioning, snapshots et compression ?",opts:["raw","qcow2","VMDK thick","ISO"],a:1},
{q:"De quoi se compose la pile open source KVM de référence ?",opts:["KVM (kernel) + QEMU + libvirt","Docker + containerd","ESXi + vCenter","Xen + dom0"],a:0},
{q:"Quelle commande VMware déplace une VM en marche d'un hôte à un autre sans coupure ?",opts:["DRS","vMotion","HA","Storage DRS"],a:1},
{q:"Principale différence d'isolation entre une VM et un conteneur ?",opts:["Aucune","La VM a son propre kernel ; le conteneur partage le kernel de l'hôte","Le conteneur est plus isolé","La VM partage le kernel"],a:1},
{q:"Qu'est-ce que Firecracker (AWS) ?",opts:["Un format d'image","Une microVM légère basée sur KVM (Lambda/Fargate)","Un orchestrateur de conteneurs","Un hyperviseur Type 2"],a:1},
{q:"Qu'appelle-t-on une « VM escape » ?",opts:["Migrer une VM","Sortir du guest pour atteindre l'hyperviseur/l'hôte","Supprimer un snapshot","Cloner une VM"],a:1},
{q:"Pourquoi un snapshot ne remplace-t-il pas une sauvegarde ?",opts:["Il est trop volumineux","Il dépend du disque source et de la chaîne de deltas","Il est chiffré","Il est plus lent"],a:1},
{q:"Quel composant matériel est requis pour le PCI passthrough et l'isolation DMA ?",opts:["TPM","IOMMU (VT-d / AMD-Vi)","APIC","NUMA"],a:1}
];
let answers=new Array(quizData.length).fill(null);
function buildQuiz(){const c=document.getElementById('quiz-container');c.innerHTML=quizData.map((q,i)=>`<div class="quiz-q"><p>${i+1}. ${q.q}</p>${q.opts.map((o,j)=>`<div class="quiz-opt" onclick="answer(this,${i},${j})">${o}</div>`).join('')}</div>`).join('')}
function answer(el,qi,oi){const parent=el.parentElement;if(parent.querySelector('.correct,.wrong'))return;answers[qi]=oi;const correct=quizData[qi].a;parent.querySelectorAll('.quiz-opt').forEach((o,j)=>{if(j===correct)o.classList.add('correct');else if(j===oi&&oi!==correct)o.classList.add('wrong')});if(answers.every(a=>a!==null)){const score=answers.filter((a,i)=>a===quizData[i].a).length;const sc=document.getElementById('quiz-score');sc.style.display='block';sc.innerHTML=`Score : ${score}/${quizData.length} ${score>=11?'Excellent !':score>=8?'Bien !':'À revoir'}`}}
buildQuiz();
</script>
</body>
</html>