Chez Techglimpse, nous recevons fréquemment des e-mails de nos lecteurs nous demandant d'écrire un tutoriel sur la "détection de la virtualisation" à partir d'un VPS ou d'une machine virtuelle. Cependant, nous n'avons pas été en mesure de répondre à ces e-mails immédiatement, car nous n'avions pas de configuration de test comprenant des hyperviseurs populaires (au moins quelques-uns) tels que Xen, VmWare, KVM, VirtualBox, HyperV, etc. peu d'hyperviseurs en cours d'exécution - juste pour le bien de nos lecteurs. Enfin, ce didacticiel vous expliquera quelques commandes et recherches (je veux dire, lire les journaux) qui peuvent vous aider à identifier le type d'hyperviseur qui exécute la machine virtuelle actuelle.
Les commandes ci-dessous ont été exécutées sur des machines virtuelles créées au-dessus des hyperviseurs Xen, KVM, VirtualBox et également sur une Icehouse OpenStack-KVM.
Méthode 1 :Lecture du journal système
Certains hyperviseurs divulguent des informations sur leur type (y compris le nom de l'hyperviseur et le type de virtualisation - comme la paravirtualisation, la virtualisation complète ou HVM) dans les fichiers journaux du système. Ces informations peuvent être obtenues depuis /var/log/message ou en extrayant la sortie de 'dmesg ‘ commande.
Remarque : Comme indiqué, cette méthode ne fonctionnera que sur certains hyperviseurs. Par exemple, VirtualBox et Xen ne divulguent aucune information dans les fichiers journaux.
Sur Xen-VM
[root@xen-vm ~]# dmesg |grep virtual
Vous ne trouvez aucune information dans les fichiers journaux sur l'hyperviseur Xen.
Sur KVM-VM
[centos@KVM-vm ~]$ dmesg |grep virtual [ 0.000000] Booting paravirtualized kernel on KVM [ 1.930785] systemd[1]: Detected virtualization 'kvm'.
Sur VirtualBox-VM
[root@VB-vm ~]# dmesg |grep virtual
Vous ne trouvez aucune information dans les fichiers journaux de VirtualBox.
Sur la machine virtuelle KVM OpenStack
[root@OS-vm ~]$ dmesg |grep virtual Booting paravirtualized kernel on KVM input: Macintosh mouse button emulation as /devices/virtual/input/input1
Sur la machine hôte KVM
[root@kvm-host ~]$ dmesg |grep virtual Booting paravirtualized kernel on bare hardware
Méthode 2 :Utilisation de la commande 'dmidecode'
DMI (interface de gestion de bureau) – dmidecode , la commande Linux native peut être utilisée pour vider les informations sur le matériel et le BIOS dans un format lisible par l'homme.
Lorsque 'dmidecode ‘ est exécuté :
Sur la machine virtuelle Xen
[root@xen-vm ~]# dmidecode | egrep -i 'manufacturer|product' Manufacturer: Xen Product Name: HVM domU Manufacturer: Xen Manufacturer: Intel
Sur la machine virtuelle KVM
[centos@kvm-vm ~]$ sudo dmidecode | egrep -i 'manufacturer|product' Manufacturer: Bochs Product Name: Bochs Manufacturer: Bochs Manufacturer: Bochs
Remarque : Vous pouvez voir 'Bochs ' en tant que valeur pour le fabricant, le nom du produit, etc... Bochs est un émulateur et un débogueur compatible X86-64 qui aide à l'émulation du processeur, de l'affichage, du BIOS, de la mémoire et d'autres matériels du PC. Cela signifie que la machine émule du matériel, ce qui laisse entendre qu'il s'agit d'une machine virtuelle et principalement d'un KVM.
Sur la machine virtuelle VirtualBox
[root@VB-vm ~]# dmidecode | egrep -i 'manufacturer|product' Manufacturer: innotek GmbH Product Name: VirtualBox Manufacturer: Oracle Corporation Product Name: VirtualBox Manufacturer: Oracle Corporation
Sur la machine virtuelle OpenStack-KVM
[centos@OS-vm ~]$ sudo dmidecode | egrep -i 'manufacturer|product' Manufacturer: Red Hat Product Name: KVM
Lorsque vous exécutez 'dmidecode ‘ sur une machine hôte, vous obtenez les informations sur le matériel et le BIOS.
[root@kvm-host ~]# dmidecode | egrep -i 'manufacturer|product' Manufacturer: Supermicro Product Name: X8SIL Manufacturer: Supermicro Product Name: X8SIL Manufacturer: Supermicro Manufacturer: Intel Manufacturer: Kingston Manufacturer: Kingston Manufacturer: Kingston Manufacturer: Kingston Manufacturer: To Be Filled By O.E.M.
Méthode 3 :Lister /dev/disk
Les machines virtuelles doivent avoir une émulation matérielle de la machine hôte. Par exemple, l'émulation de disque à partir de l'hôte. Donc, si vous répertoriez simplement les fichiers sous "/dev/disk/by-id ', vous pouvez facilement déterminer quel émulateur est utilisé par l'hyperviseur.
Sur la machine virtuelle Xen
[root@xen-vm~]# ls -l /dev/disk/by-id total 0 lrwxrwxrwx 1 root root 9 Sep 29 15:14 ata-QEMU_DVD-ROM_QM00004 -> ../../hdd lrwxrwxrwx 1 root root 9 Sep 29 15:14 ata-QEMU_HARDDISK_QM00001 -> ../../hda lrwxrwxrwx 1 root root 10 Sep 29 15:14 ata-QEMU_HARDDISK_QM00001-part1 -> ../../hda1 lrwxrwxrwx 1 root root 10 Sep 29 15:14 ata-QEMU_HARDDISK_QM00001-part2 -> ../../hda2
QEMU émule tout le matériel attaché à l'hôte sur une machine virtuelle.
Sur la machine virtuelle KVM
[centos@kvm-vm ~]$ ls -l /dev/disk/by-id lrwxrwxrwx. 1 root root 9 Sep 30 10:40 ata-QEMU_HARDDISK_QM00001 -> ../../sda lrwxrwxrwx. 1 root root 10 Sep 30 10:35 ata-QEMU_HARDDISK_QM00001-part1 -> ../../sda1
Sur la machine virtuelle VirtualBox
[root@VB-vm ~]# ls -l /dev/disk/by-id total 0 lrwxrwxrwx 1 root root 9 Oct 5 21:10 ata-VBOX_CD-ROM_VB2-01700376 -> ../../hdc lrwxrwxrwx 1 root root 9 Oct 5 21:10 ata-VBOX_HARDDISK_VBc7f3f571-49b6d797 -> ../../hda lrwxrwxrwx 1 root root 10 Oct 5 21:10 ata-VBOX_HARDDISK_VBc7f3f571-49b6d797-part1 -> ../../hda1 lrwxrwxrwx 1 root root 10 Oct 5 21:10 ata-VBOX_HARDDISK_VBc7f3f571-49b6d797-part2 -> ../../hda2 lrwxrwxrwx 1 root root 10 Oct 5 21:10 ata-VBOX_HARDDISK_VBc7f3f571-49b6d797-part3 -> ../../hda3
Remarque : VBOX au lieu de QEMU sur une machine virtuelle VirtualBox
Sur la machine virtuelle KVM OpenStack
[centos@OS-vm ~]$ ls -l /dev/disk/by-id ls: cannot access /dev/disk/by-id: No such file or directory
Je n'ai trouvé aucune information sur OpenStack VM. Probablement, OpenStack le cache ? Pas sûr !
Sur la machine hôte KVM
[root@kvm-host ~]# ls -l /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 10 Sep 28 08:45 dm-name-centos-home -> ../../dm-2 lrwxrwxrwx 1 root root 10 Sep 28 08:45 dm-name-centos-root -> ../../dm-1 lrwxrwxrwx 1 root root 10 Sep 28 08:45 dm-name-centos-swap -> ../../dm-0 lrwxrwxrwx 1 root root 10 Sep 28 08:45 dm-uuid-LVM-fQq4kAJfUvtqpELNejjkiUTcGNhMJAIGbhQF7TR1rpaLi9Z8e1OF19f0K4DKhtxg -> ../../dm-1 lrwxrwxrwx 1 root root 10 Sep 28 08:45 dm-uuid-LVM-fQq4kAJfUvtqpELNejjkiUTcGNhMJAIGcstbiCdWXv3SCKfHb8lSPbApR525PK2W -> ../../dm-0 lrwxrwxrwx 1 root root 10 Sep 28 08:45 dm-uuid-LVM-fQq4kAJfUvtqpELNejjkiUTcGNhMJAIGrt7RtF7L1qlwo2fjIIQh9FasnQoV3q9y -> ../../dm-2 lrwxrwxrwx 1 root root 10 Sep 28 08:45 lvm-pv-uuid-rZHlC1-OyIn-lpf8-NU1e-uhLB-s3At-GyR6zx -> ../../sda2 lrwxrwxrwx 1 root root 9 Sep 28 08:45 scsi-SAdaptec_ft_A8E727A8 -> ../../sda lrwxrwxrwx 1 root root 10 Sep 28 08:45 scsi-SAdaptec_ft_A8E727A8-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Sep 28 08:45 scsi-SAdaptec_ft_A8E727A8-part2 -> ../../sda2
Méthode 4 :Utilisation du package virt-what
Toutes les saveurs Linux ne sont pas livrées avec 'virt-what 'paquet installé. Vous pouvez l'installer en utilisant 'yum ‘.
[root@vm ~]# rpm -ivh virt-what-1.11-2.el5.x86_64.rpm warning: virt-what-1.11-2.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID e8562897 Preparing... ########################################### [100%] 1:virt-what ########################################### [100%]
Sur la machine virtuelle Xen
[root@xen-vm ~]# virt-what xen xen-hvm
Sur la machine virtuelle KVM
[centos@kvm-vm ~]$ sudo virt-what kvm
Sur la machine virtuelle VirtualBox
[root@VB-vm ~]# virt-what virtualbox
Sur la machine virtuelle KVM OpenStack
[root@OS-vm ~]# virt-what kvm
Sur l'hôte KVM
[root@kvm-host ~]# virt-what
Remarque : Vous n'obtenez aucune sortie sur une machine hôte.
Méthode 5 :Utilisation de virtdetect ou systemd-detect-virt
Virtdetect rpm est basé sur ‘Sys::Detect::Virtualization ' script perl – Reportez-vous à ce didacticiel pour plus d'informations .
Méthode 6 :Utilisation de la commande ‘lshw’
Installez 'lshw ‘ paquet comme ci-dessous :
[root@vm ]# yum install lshw Installed: lshw.x86_64 0:B.02.17-3.el6 Complete!
Sur la machine virtuelle Xen
[root@xen-vm ~]# lshw -class system description: Computer product: HVM domU vendor: Xen version: 4.1.5 width: 32 bits capabilities: smbios-2.4 dmi-2.4 smp-1.4 smp
Sur la machine virtuelle KVM
[centos@kvm-vm~]$ sudo lshw -class system description: Computer product: Bochs vendor: Bochs width: 64 bits capabilities: smbios-2.4 dmi-2.4 vsyscall32
Sur la machine virtuelle VirtualBox
[root@VB-vm ~]# lshw -class system description: Computer product: VirtualBox vendor: innotek GmbH version: 1.2 serial: 0 width: 32 bits capabilities: smbios-2.5 dmi-2.5 description: System peripheral product: VirtualBox Guest Service
Sur la machine virtuelle KVM OpenStack
[root@OS-vm ]# lshw -class system description: Computer product: KVM vendor: Red Hat version: RHEL 6.6.0 PC width: 64 bits capabilities: smbios-2.4 dmi-2.4 vsyscall64 vsyscall32
Sur l'hôte KVM
[root@kvm-host ~]# lshw -class system description: Sealed-case PC product: X8SIL (To Be Filled By O.E.M.) vendor: Supermicro version: 0123456789 width: 64 bits capabilities: smbios-2.6 dmi-2.6 vsyscall32
Méthode 7 :Utilisation de « ethtool »
Sur quelques hyperviseurs, vous pouvez facilement savoir si le périphérique réseau est émulé à l'aide de la commande "ethtool".
[centos@kvm-vm ]$ ethtool -i eth0 driver: virtio_net version: 1.0.0 firmware-version: bus-info: 0000:00:02.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
Eh bien, ce sont quelques commandes qui vous permettent de détecter la virtualisation sur divers hyperviseurs. Connaissez-vous une autre méthode ? Laissez-nous dans la section des commentaires ci-dessous.