quelle est la différence entre / dev / vda et / dev / sda
Je me prépare pour une certification et j'ai un CentOS7 (VirtualBox) installé localement et une autre instance dans un service cloud.
Sur le système local, j'ai un /dev/sda et sur le cloud j'ai /dev/vda.
Maintenant, je me demande ce que signifie exactement cette différence? Existe-t-il une norme (documentation?) Pour la dénomination de ces appareils et quels sont les différents noms?
Modifier:
Je pense que ce document est très utile pour comprendre la dénomination: https://www.kernel.org/doc/Documentation/admin-guide/devices.txt
8 block SCSI disk devices (0-15)
0 = /dev/sda First SCSI disk whole disk
16 = /dev/sdb Second SCSI disk whole disk
32 = /dev/sdc Third SCSI disk whole disk
...
240 = /dev/sdp Sixteenth SCSI disk whole disk
Mais je n'ai pas pu trouver d'informations sur/dev/vda.
Virtualisation complète vs paravirtualisation
/dev/sda est le premier disque détecté de type IDE/SATA/SCSI. Dans ce cas, émulé (entièrement virtualisé) par l'hyperviseur.
/dev/vda est le premier pilote de disque paravirtualisé détecté. Il est plus rapide que les périphériques sdX émulés si les deux sont référés au même disque, car il y a moins de surcharge dans son fonctionnement par rapport à un lecteur émulé.
Références:
De http://www.ibm.com/developerworks/library/l-virtio/ :
Virtualisation complète vs paravirtualisation
Commençons par une brève discussion de deux types distincts de schémas de virtualisation: la virtualisation complète et la paravirtualisation. En virtualisation complète, le système d'exploitation invité s'exécute au-dessus d'un hyperviseur qui repose sur le métal nu. L'invité ne sait pas qu'il est virtualisé et ne nécessite aucune modification pour fonctionner dans cette configuration. Inversement, en paravirtualisation, le système d'exploitation invité est non seulement conscient qu'il s'exécute sur un hyperviseur, mais inclut du code pour rendre les transitions invité-à-hyperviseur plus efficaces.
Dans le schéma de virtualisation complet, l'hyperviseur doit émuler le matériel du périphérique, qui émule au niveau le plus bas de la conversation (par exemple, vers un pilote réseau). Bien que l'émulation soit propre à cette abstraction, c'est aussi la plus inefficace et très compliquée. Dans le schéma de paravirtualisation, l'invité et l'hyperviseur peuvent travailler en coopération pour rendre cette émulation efficace. L'inconvénient de l'approche de paravirtualisation est que le système d'exploitation est conscient qu'il est virtualisé et nécessite des modifications pour fonctionner.
De http://www.carfax.org.uk/docs/qemu-virtio :
Quels sont les dispositifs paravirtuels?
Lors de l'exécution d'une machine virtuelle, l'environnement virtuel doit présenter les périphériques au système d'exploitation invité - les disques et le réseau étant les deux principaux (plus la vidéo, l'USB, les minuteries et autres). En fait, c'est le matériel que le client VM voit.
Maintenant, si l'invité doit être gardé totalement ignorant du fait qu'il est virtualisé, cela signifie que l'hôte doit émuler une sorte de matériel réel. Ceci est assez lent (en particulier pour les périphériques réseau) et est la principale cause de la baisse des performances des machines virtuelles.
Cependant, si vous souhaitez faire savoir au système d'exploitation invité qu'il se trouve dans un environnement virtuel, il est possible d'éviter les frais généraux liés à l'émulation d'une grande partie du matériel réel et d'utiliser un chemin beaucoup plus direct pour gérer les périphériques à l'intérieur de la machine virtuelle. Cette approche est appelée paravirtualisation. Dans ce cas, le système d'exploitation invité a besoin d'un pilote particulier installé qui communique avec le périphérique paravirtuel. Sous Linux, cette interface a été normalisée et est appelée interface "virtio".