Machines virtuelles, question à la noix

Support Debian
,
Tags: #<Tag:0x00007fb5da05bb20> #<Tag:0x00007fb5da05b8c8>
#1

Bonjour à tous, j’ai une question à la noix qui me turlupine sur la virtualisation, je pourrais me renseigner tout seul, mais je me dis que vous avez probablement la réponse, alors je vous sollicite.

Avant propos : j’ai déjà utilisé des VM de manière classique : souvent avec un hôte Windows, et des VM Linux (CentOS), la VM était contenue dans un fichier sur le HDD. Je ne me souviens plus le nom de l’outil qui faisait tourner la VM, ni l’extension du fichier contenant la VM, mais ce n’est pas très important, le point principal, c’est que la VM est contenue un fichier déposé sur le disque dur de l’hôte.

Le contexte : depuis que je me suis mis à Debian sur mon PC, j’ai un dual boot organisé comme ça :

  • Disque dur 1 :
    1. Une partition de démarrage avec les boot loaders
    2. Une partition système Windows
    3. Une partition système Debian avec tout dedans, /home inclus, c’est probablement pas une bonne pratique, mais pour l’instant ce n’est pas le débat
    4. Une partition pour le swap Debian
  • Disque dur 2 :
    1. Des vidéos que je peux lire depuis Windows ou Debian

Et maintenant, la question que je me pose… Est-il possible d’exécuter, sur un de mes OS, une VM qui utiliserait comme stockage la partition de l’autre OS ??? En clair, lancer mon Debian (partition 1.3) dans une VM qui s’exécute sur mon Windows (partition 1.2), ou l’inverse.

#2

Par principe, pourquoi pas puisque la partition autre (non montée) n’est qu’une partition, comme on peut lancer avec qemu un Linux stocké dans une clé USB.
Après, il faut voir si l’autre partition, je pense en particulier à Windows, accepte de démarrer comme ça, sans toute la chaîne qui part du BIOS et s’il couine, comment contourner.

#3

Tu veux avoir un host A qui demarre une VM B qui execute le host C.
Non.
Une VM ne peut pas démarrer un Host.

Soit ton système windows démarre une machine virutelle Debian.
Soit ton système Debian démarre une machine virtuelle windows.

Il est impossible de fait tourner un OS du host dans une VM exécuté par un autre OS du même Host.

La virtualisation consiste à faire tourner un émulateur matériel (Hyperviseur) sur un système installé sur la machine physique.
Cet émulateur matériel fait à son tour tourner un OS qui est installé dans une instance de cet émulateur.

un serveur physique → OS Hôte → hyperviseur → machine virtuelle → OS

#4

Non ca ne marche pas. L’OS sur le Host ne fonctionnera pas sur la machine virtuelle car ce n’est pas le même « matériel ».
Un « disque » virtuel n’a physiquement rien à voir avec un disque « physique ».
En plus ca dépendra de ton Hyperviseur

#5

Dommage, ça aurait été rigolo.

2 J'aime
#6

Je ne comprends pas, il est tout à fait possible de faire tourner une VM sur une machine, VM utilisant un des disques de la machine. Je fais ça constamment. La seule contrainte est que le disque ne soit pas utilisé par l’hote.
Exemple d’une commande que je fais constamment:

qemu-system-aarch64 \
  -machine virt \
  -cpu cortex-a72 \
  -m 4096 \
  -smp 4 \
  -bios /usr/share/edk2/aarch64/QEMU_EFI.fd \
  -drive if=none,file=/dev/sda,format=raw,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -device virtio-net-device,netdev=net0 \
  -netdev user,id=net0 \
  -device virtio-gpu-pci \
  -device qemu-xhci \
  -device usb-kbd \
  -device usb-mouse \
  -display gtk,gl=on

Elle lance une VM utilisant le disque physique /dev/sda
Pour virtualbox, tu peux créer un vmdk associé à un disque physique par

VBoxManage internalcommands createrawvmdk -filename Disquesda.vmdk -rawdisk /dev/sda

En revanche, tu ne peux pas utiliser une partition utilisée par l’hote. En revanche comme on peut partager la racine de l’hote, je me demande ce que donnerait une VM ayant monté cette racine puis fait un chroot sur cette racine (voire un pivot). Assurrément une mauvaise idée mais pas impossible je pense.

1 J'aime
#7

Ah, voilà qui est intéressant ! Je crois comprendre que certaines options de ta ligne de commande spécifient le hardware de la VM ? Peux-tu détailler ton option -bios STP ?

#8

En lecture seule

Les risques sont minimes. On peut utiliser la racine de l’hôte comme environnement de récupération, faire un chroot , réparer une installation, reconstruire un initramfs, etc.
C’est une pratique courante avec un système de secours.

En lecture-écriture

C’est dangereux. Même si le noyau de la VM et celui de l’hôte sont identiques, les deux systèmes auraient chacun leurs caches de pages, leurs journaux de système de fichiers et leurs verrous, sans aucune coordination.
Les modifications concurrentes peuvent entraîner des incohérences et de la corruption de données.

Des options spécifiques à l’architecture qui fait tourner, aarch64 c’est du PI ou quelque chose comme ça.
Sous Qemu ARM, il n’y a pas debios historique; on utilise presque toujours EDK2 , qui est une implémentation libre de l’UEFI.
Tu ne devrais pas avoir ces options avec du amd64 :wink:

#9

Le point est « La seule contrainte est que le disque ne soit pas utilisé par l’hote ».
Ce qui était mon propos.

#10

C’est parce que je suis en train de construire une clef ARM64 avec un boute EFI. Du coup je spécifie un BIOS permettant un tel boute —> QEMU_EFI.fd

Quant à partager la racine tu peux le faire via aufs, j’ai fait un script pour ça qui doit être dans les archives: faire

asciinema play exemple.txt

pour voir un exemple avec deux systèmes partageant la même racine, le premier est l’hote, le deuxième est un chroot avec une racine en ro avec un tmpfs en rw par dessus.
exemple.txt (8,5 Ko)