QEMU a plusieurs façons de connecter un périphérique de bloc à une machine virtuelle. Initialement, cela a été mis en œuvre de la manière suivante:
-hda /dev/sda1
Ainsi, les disques virtuels se connectaient à l'époque de la virtualisation. Il peut être utilisé aujourd'hui si nous voulons simplement tester certains liveCD. Malheureusement, il a ses inconvénients. :
- Lors de la connexion de disques virtuels, il est possible d'utiliser uniquement l'interface considérée comme
/dev/hda (hda, hdb, hdc, ..) sur la machine virtuelle; Pour les CD, l'option -cdrom est -cdrom - Lorsqu'un fichier (ou périphérique) est connecté à une machine virtuelle, QEMU utilise uniquement les paramètres par défaut.
conduire
Pour définir d'autres paramètres (type de bus, utilisation du cache, etc.), l'option -drive été ajoutée à -drive . Bien qu'il ait été initialement utilisé pour définir les paramètres du backend et du frontend , il n'est actuellement utilisé que pour définir les paramètres du backend , c'est-à-dire les paramètres qui affectent la connexion du périphérique virtuel à l'intérieur de la machine virtuelle.
-drive file=/dev/sda1,if=ide,cache=writeback,aio=threads
appareil
Définir tous les paramètres d'un périphérique bloc avec une option au fil du temps s'est avéré déraisonnable. Par conséquent, les options ont été divisées en deux. Paramètres de backend , c'est-à-dire ceux qui sont utilisés pour configurer l'environnement de virtualisation. Et l' interface , qui affecte la façon dont le périphérique est connecté dans la machine virtuelle. Pour cet ensemble de paramètres, une nouvelle option -device été introduite, qui contient l' id de l'id du lecteur spécifié par le paramètre -drive .
L'exemple de configuration suivant connectera le lecteur avec l' identifiant ide0-hd0 , et le résultat est le même que la connexion d'un lecteur virtuel, comme indiqué dans l'introduction.
-drive file=/dev/sda1,id=ide0-hd0,if=none,cache=writeback,aio=threads \ -device ide-drive,bus=ide.0,drive=ide0-hd0
Périphériques de bloc locaux dans une machine virtuelle
L'utilisation de périphériques de blocs physiques pour les machines virtuelles n'est pas très répandue aujourd'hui compte tenu de l'utilisation généralisée des disques virtuels. Techniquement, nous pouvons exécuter une machine virtuelle avec un système propriétaire à partir d'un ancien disque dur. Cependant, dans ce cas, il est préférable de faire d'abord une image disque (image) à l'aide de dd et de démarrer le système à partir de celui-ci déjà.
Comme un périphérique bloc local, il peut être connecté à une machine virtuelle.
- Baie RAID locale - périphérique de type md
- Master DRBD (network RAID1) - périphérique de type drbd
- Partition de disque créée dans le groupe LVM - périphérique de type dm
- Un fichier normal connecté via une boucle est un périphérique de boucle
Bloquer le périphérique d'un autre ordinateur exporté via le serveur NBD - périphérique de type nbd
(Ici, il convient également de mentionner le type d'appareil Ceph rbd et le type d'appareil ZFS zvol - environ Per)
NBD
Considérez le concept de connexion d'un périphérique bloc à partir d'un ordinateur distant via un réseau. Voir le manuel séparé pour NBD .
QEMU possède une API NBD intégrée, de sorte qu'un périphérique de bloc distant étendu avec un serveur NBD peut être directement connecté à la machine virtuelle via QEMU - voir la figure à gauche.
Cependant, NBD est un protocole assez simple qui n'utilise pas d'authentification sur un serveur distant et ne contrôle pas l'état de la connexion. Le protocole NBD suppose que le client peut se reconnecter si la connexion au serveur est interrompue, mais malheureusement QEMU ne le fait pas.
En partie, la situation peut être résolue en connectant plusieurs périphériques NBD et en créant une matrice RAID virtuelle à l'intérieur. Cette approche présente plusieurs avantages et un défaut fatal. Si l'un des appareils s'éteint, il ne se passera rien de mal. Mais s'ils s'envolent d'un coup = ce sera mauvais. Les opérations d'E / S dans un environnement virtuel seront beaucoup plus rapides, car les requêtes seront exécutées en parallèle sur plusieurs machines physiques (serveurs NBD) à la fois. Mais d'un autre côté, cela nécessitera plus de ressources du processeur virtuel et de la mémoire virtuelle.
Le principal inconvénient de la construction d'une matrice RAID à partir de périphériques NBD dans une machine virtuelle est le périphérique QEMU, si le périphérique NBD se bloque, il ne sera reconnecté qu'après un redémarrage complet de la machine, tandis que le redémarrage interne du système d'exploitation à l'intérieur de la machine virtuelle ne sera pas suffisant. Mais vous pouvez créer une machine virtuelle sans disques qui accèdera indépendamment au serveur NBD et connectera les périphériques NBD nécessaires. De plus, les périphériques défaillants doivent être ajoutés à la baie et resynchronisés, cela peut être fait manuellement ou à l'aide de scripts à l'intérieur de la machine virtuelle.
Il est préférable d'accéder au serveur NBD à l'aide du périphérique de machine virtuelle NBD. Particulièrement bon, en termes de performances d'E / S, est de construire une matrice RAID à partir de périphériques NBD.
Cette solution s'est avérée être la plus productive de toutes testées. Et la machine virtuelle a pu continuer à fonctionner sans interruption, même en cas de déconnexion du serveur NBD (ou de panne) au fil du temps.
Ainsi, il a été possible d'organiser un environnement de virtualisation relativement stable et en même temps productif sur des équipements instables.
Le principal problème avec les matrices RAID sur les périphériques NBD est que vous devez être très prudent lorsque vous connectez un périphérique faisant partie d'une matrice RAID à partir du serveur NBD. Il s'agit d'un processus assez délicat avec une forte probabilité d'erreur fatale, ce qui peut entraîner une perte de données. Une petite faute de frappe suffit. Voir la description de l'accident de voiture mortel du 21 juillet 2012 sur la page Peanuts .
L'inconvénient est qu'un périphérique bloc avec lequel une machine virtuelle fonctionne déjà ne peut pas être connecté à un autre endroit si son système de fichiers ne le permet pas - cela est similaire à iSCSI ( i nternet S mall C omputer S usterm I nterface - version réseau de SCSI) ou AoE ( A TA u ver la technologie Eernet).
Disques virtuels
QEMU peut non seulement connecter des périphériques de bloc à la machine virtuelle, mais également, en utilisant diverses API, un fichier normal peut également être connecté, qui ressemblera à un périphérique de bloc à l'intérieur de la machine.
Qemu peut fonctionner avec des disques virtuels de différents formats. Pour les disques virtuels qui sont présentés sous forme de fichiers ordinaires, il existe un utilitaire qemu-img standard qui peut être utilisé à la fois pour la conversion afin de déterminer le format utilisé et ses paramètres.
Récupération des informations de disque virtuel enregistrées en tant que fichier normal. De la même manière, vous pouvez obtenir des informations sur un disque virtuel stocké sur GlusterFS:
root@stroj~# qemu-img info /path_to_file/soubor.img
Cependant, pour obtenir des informations sur un disque virtuel à l'aide de l'API GlusterFS, vous devez utiliser les mêmes paramètres que ceux utilisés pour connecter le disque virtuel à la machine virtuelle. Ainsi, vous pouvez identifier le disque interne sur la machine où le client GlusterFS est installé et utilisé:
root@stroj~# qemu-img info gluster+tcp://192.168.0.2/volume_name/soubor.img
Le disque virtuel VDI ne peut être identifié que via l'API Sheepdog:
root@stroj~# qemu-img info sheepdog:192.168.0.2:8000:vdi_name
Pour un disque virtuel exporté depuis le serveur NBD, il est nécessaire de s'assurer que le bon serveur et le bon port sont spécifiés, car NBD n'utilise aucun autre mécanisme d'identification ou d'authentification qui éliminerait la confusion avec d'autres disques virtuels (la nouvelle version de nbd-server utilise un seul port et identifie l'appareil par son nom - environ par) :
root@stroj~# qemu-img info nbd:192.168.0.2:8000
192.168.0.2
L'adresse IP de l'hôte à partir duquel le périphérique virtuel se connecte. S'il s'agit du même hôte qemu-img info s'exécute, localhost peut être utilisé à la place de l'adresse IP
8000
Numéro de port sur lequel le démon ou le serveur écoute. Par défaut, Sheepdog utilise le port 7000, mais il peut également être exécuté sur un autre port pour éviter les conflits avec une autre application. Un serveur NBD peut écouter sur différents ports si plusieurs appareils sont exportés.
brut
en général, il s'agit simplement d'un ensemble de données enregistrées dans le même format que sur un périphérique bloc classique. Un fichier 5G occupera toute cette place, qu'il contienne des données utiles ou simplement un espace vide. (qui ne s'applique pas aux fichiers épars - environ par.)
qcow
Il diffère du format brut en ce qu'il peut être incrémentiel, car il se développe progressivement - c'est pratique pour les systèmes de fichiers qui ne prennent pas en charge les fichiers clairsemés, par exemple FAT32. Ce format vous permet également de créer des copies incrémentielles distinctes à partir d'un seul disque de base. L'utilisation d'un tel «modèle» permet d'économiser du temps et de l'espace disque. De plus, il prend en charge le cryptage AES et la compression zlib. L'inconvénient est que, contrairement aux disques bruts, un tel fichier ne peut pas être monté directement sur la machine sur laquelle il se trouve. Heureusement, il existe un utilitaire qemu-nbd qui peut exporter ce fichier en tant que périphérique de blocage réseau, puis le connecter à un périphérique NBD.
qcow2
est une version mise à jour du format qcow. La principale différence est qu'il prend en charge les instantanés. Sinon, ils ne sont pas fondamentalement différents. Il est également possible de rencontrer qcow2, qui est défini en interne comme QCOW version 3, une fois qu'il a été inclus dans le format qcow2 il y a longtemps. En fait, il s'agit d'un qcow2 modifié avec le paramètre lazy_refcounts, qui est utilisé pour les instantanés. Étant donné que la différence n'est que d'un bit, qemu-img de la version 1.7 a l'option "modifier" pour le changer. Les versions antérieures de qemu-img ne le font pas. Si vous vouliez changer la version du format, il fallait convertir le disque virtuel en un nouveau fichier, lors de la conversion, le paramètre compat était installé avec le paramètre compat, pour lequel il fallait plutôt réduire le "1.1" à 0.10 ". La présence de l'option «modifier» est pratique car il n'est pas nécessaire d'écraser les données en raison de ces changements mineurs.
qemu-img create -f qcow2 -o compat=1.1 test.qcow2 8G
http://blog.wikichoon.com/2014/12/virt-manager-10-creates-qcow2-images.html
qed
Il s'agit d'un format COW incrémentiel d'un disque virtuel qui crée la moindre charge sur l'hôte. Il ne prend en charge aucune compression et utilise deux tables parallèles pour adresser les blocs de données (clusters). Malheureusement, pas un seul développeur ne s'est intéressé depuis longtemps à son développement, son utilisation pose donc des problèmes qui seront évoqués.
vdi
format de disque virtuel utilisé par le système de virtualisation Oracle Virtualbox.
vmdk
format de disque virtuel utilisé par les produits VMware. Il s'agit également d'un format qui permet à un fichier de se développer progressivement. Cependant, il présente un grand avantage sur les formats qcow2 et qed, qui peuvent également être utilisés avec des solutions sans disque ou avec des systèmes de fichiers réseau. Il vous permet d'avoir un fichier de disque virtuel divisé en plusieurs petits fichiers d'une taille de 2 Go. Cela reste du temps où les systèmes de fichiers ne pouvaient pas créer de fichiers supérieurs à 2 Go. L'avantage est que si un tel disque virtuel est répliqué sur le réseau, moins de données sont transférées et la synchronisation est beaucoup plus rapide (par exemple, dans le cas de GlusterFS). Dans le cas d'une solution sans disque, elle est également utilisée pour stocker uniquement de petits fichiers avec des différences pour chaque instantané
vhdx
format de disque virtuel utilisé par le système de virtualisation Microsoft Hyper-V
vpc
format de disque virtuel utilisé par le système de virtualisation Microsoft VirtualPC.
| Incre
menti
enraciné
C'est à dire
| Chiffre
novation
| Com
prés
ça
| Preal
emplacement
| Shabl
oniz
nation
| Prop
belettes
| Section
image
| À l'intérieur
instantanés
toi
| Vérification approuvée
nosti
| Remarque
|
|---|
| brut | non | non | non | oui | non | non | non | non | non | Peut être monté via une boucle
|
| fichier | oui | non | non | option
personnellement | non | non | non | non | non | Pour Btrfs, vous devez désactiver la copie sur écriture
|
| qcow | oui | oui | oui | non | oui | oui | non | non | non | |
| qcow2 | oui | oui | oui | option
personnellement | oui | oui | non | oui | oui | |
| qed | oui | non | non | non | oui | non | non | non | non | |
| vmdk | oui | non | non | option
personnellement | oui | hein ? | oui | non | non | |
| vdi | oui | non | non | option
statique (statique) | non | non | non | non | oui | |
| vhdx | oui | non | non | option
fixe (fixe) | non | oui 1 | non | non | non | |
| vpc | oui | non | non | option
fixe (fixe) | non | non | non | non | non | |
- ↑ Il est possible d'utiliser uniquement sur des images préinstallées (fixe)
API utilisées
En plus des formats de fichiers, qemu-img fonctionne également avec des «formats» fournis à l'aide de l'API par le biais de laquelle ces périphériques bloqués sont accessibles à distance.
nfs
fichier de disque virtuel connecté à QEMU via le protocole NFS
iscsi
la communication avec le périphérique de bloc se fait via iSCSI. Un appareil ne peut pas être utilisé simultanément sur plusieurs clients.
nbd
L'accès via NBD peut être très rapide. En effet, le protocole est très simple. C'est un avantage, mais en même temps un inconvénient. Cela peut être pratique lorsque plusieurs clients peuvent se connecter au même serveur NBD s'ils utilisent une connexion locale via le serveur xnbd. Cependant, comme nbd ne dispose pas de mécanismes de sécurité ou d'authentification, une situation peut facilement se produire lorsqu'un client se connecte accidentellement au mauvais appareil, qui à un moment donné peut déjà être utilisé et l'endommager.
ssh
la connexion au serveur distant se fait via sshfs
briller
utilise l'API du système de fichiers GlusterFS pour accéder au fichier de disque virtuel. Si le fichier fait partie d'un volume répliqué ou distribué, il répartira les données stockées entre les autres nœuds. Cela lui permet, en cas de panne, d'être disponible sur d'autres nœuds.
chien de berger
est également un système de fichiers distribué avec réplication. Contrairement à GlusterFS, un disque virtuel via l'API est disponible non pas en tant que fichier, mais en tant que périphérique de bloc. Ceci est bénéfique en termes de performances, mais désavantageux si nous devons aller au-delà de l'environnement Sheepdog.
paralles
Lecteurs virtuels sur le stockage connecté au réseau
L'avantage des périphériques de bloc situés en dehors du système de virtualisation est qu'ils sont alors immunisés contre les pannes de machines virtuelles.
Dans ce cas, une haute disponibilité et un volume suffisant pour le stockage à distance sont également fournis.
Utilisation de NFS
Chien de berger
GlusterFS
Machines virtuelles sans bloc
Sans périphériques de bloc, les systèmes d'exploitation qui peuvent démarrer via NFS ou avec un système de fichiers hôte lancé à l'aide de Plan9 peuvent fonctionner.