Une note rapide, il existe en fait 3 modes, et non deux en ce qui concerne les pilotes utilisés :
- HVM :noyau et pilotes non modifiés utilisant des périphériques émulés par logiciel
- PV-HVM :noyau non modifié avec disque paravirtualisé (spécifique Xen) et pilotes réseau
- PV :noyau et pilotes modifiés
Pour un invité Xen/DomU vous pouvez faire un uname très basique et lsmod avec un grep pour lister les modules utilisés :
uname -a
lsmod | grep xen
Si uname -a répertorie un noyau avec la chaîne "xen" dedans, alors vous avez un noyau modifié et c'est probablement un invité PV, et vous verrez la sortie du lsmod commande pour le confirmer. Si vous avez une sortie du grep sur lsmod mais aucun signe d'un noyau modifié alors vous êtes PV-HVM. Sans aucun signe de l'un ou de l'autre, c'est un HVM droit.
Remarque :En général, vous pouvez faire plus avec les machines virtuelles sur lesquelles les outils PV sont installés, ce qui peut être un pointeur assez évident, mais vous pouvez simuler la présence des outils PV pour autoriser la suspension/reprise, etc., vous ne pouvez donc pas vous y fier en général. .
Il existe une meilleure alternative à l'analyse de uname -a sortie de l'intérieur du domaine invité. Vous devriez plutôt vérifier le profil de la VM dans l'hyperviseur lui-même.
XL
Avec le courant Pile d'outils XenLight pour les installations Xen autonomes, cela peut être réalisé en exécutant xl list --long commande :
# xl list
Name ID Mem VCPUs State Time(s)
My-Virtual-Machine 42 1024 1 -b---- 9001.0
# xl list -l 42
or
# xl list --long My-Virtual-Machine
[
{
"domid": 6,
"config": {
"c_info": {
"name": "My-Virtual-Machine",
"uuid": "12345678-abcd-1234-abcd-12345678abcd",
"type": "pv",
...
},
...
}
}
]
Notez le type article dans le c_info section — si elle est égale à "pv" , cela signifie paravirtuel.
XM
Avec un ancien installation Xen autonome en utilisant le xm traditionnel pile d'outils de gestion, les choses étaient similaires :
# xm list --long My-Virtual-Machine
(domain
(domid 42)
(name My-Virtual-Machine)
(image
(linux
(kernel ...)
...
)
)
...
)
Notez le (linux) élément dans le (image) section — elle correspond au builder directive de configuration, où « linux » signifie « paravirtuel » (plutôt que le noyau réel), tandis que « hvm » signifie « virtualisation complète ».
XE
Avec XenServer ou XCP appliance vous pouvez utiliser xe vm-list params=all commande ou quelque chose de similaire.
virsh
Il peut y avoir (ou il y a eu) un moyen d'obtenir ces informations de libvirt toolstack, mais inconnu pour moi.
Notez qu'à partir de Xen 4.5, le mode paravirtuel sur x86-64 a deux versions :
- paravirtualisation classique (PV) qui s'appuie sur les systèmes invités à réécrire de l'utilisation de l'anneau 0 vers l'anneau 1 ; depuis qu'AMD a abandonné l'anneau 1 et l'anneau 2 en x86-64, Xen a dû se rabattre sur la gestion logicielle, qui est encore plus lente que HVM ;
- paravirtualisation assistée par matériel (PVH), — à ne pas confondre avec entièrement virtualisé avec des pilotes paravirtuels (PV-on-HVM), — qui s'appuie sur l'assistance matérielle pour gérer les instructions privilégiées et les tables de pages mémoire, mais utilise des techniques PV traditionnelles pour tout le reste, de sorte qu'aucun matériel n'est émulé et que des performances quasi natives sont obtenues comme c'était le cas en bon état. vieux x86-32 fois.
Pour vérifier si l'hôte fonctionne avec PVH activé, on peut utiliser xl info (bien que cette méthode ne soit pas meilleure que d'inspecter grub.cfg ):
# xl info | grep xen_commandline
xen_commandline : pvh=1 loglvl=all guest_loglvl=all console=com1,vga
^^^^^
Pour vérifier si un invité particulier fonctionne en mode PVH (pvh=1 dans le fichier de configuration), encore une fois, consultez xl list -l :
"c_info":{
"name": "My-Virtual-Machine",
"type": "pv",
"pvh": "True",
...
},
Cependant, du point de vue de l'administration, PVH ne devrait pas être différent de PV.