Windows 10 : Microsoft introduit la virtualisation imbriquée

Le par  |  10 commentaire(s)
Windows-10-logo

De la virtualisation dans la virtualisation. Dans la build 10565 de Windows 10 Insider Preview, Microsoft pose les jalons de la prise en charge de la Nested Virtualization.

Pour les testeurs, Microsoft a publié en début de semaine une build 10565 de Windows 10 Insider Preview. Il s'avère qu'elle intègre une version très préliminaire de la Nested Virtualization. Cette technologie fait référence à de la virtualisation imbriquée et consiste à faire de la virtualisation dans de la virtualisation.

" La fonctionnalité virtualise certaines caractéristiques matérielles qui sont nécessaires pour exécuter un hyperviseur dans une machine virtuelle ", résume une employée de Microsoft qui livre diverses explications et détails techniques dans un billet de blog.

Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux. Pour le moment, Microsoft prépare le terrain à la première préversion publique de Hyper-V Containers. La nouvelle fonctionnalité n'est pas complète et qui plus est sujette à " beaucoup " de bugs. Elle est uniquement opérationnelle avec Hyper-V.

Windows-10-Nested-Virtualization
La virtualisation imbriquée n'intéressera évidemment pas l'utilisateur lambda. Elle peut être utile pour exécuter plusieurs hyperviseurs sur un même serveur hôte, et des scénarios pour tester des produits logiciels avec diverses configurations.

Complément d'information

Vos commentaires

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #1863448
J'ai un peu de mal à saisir l'utilité concrète :

Virtualisation ESXi : du virtuel directement sur du hardware
Hyper V & co : du virtuel sur un os

Et ici ? Le but c'est de pouvoir faire communiquer plusieurs machines
virtuelles installées sur plusieurs hyperviseur ?

Du coup ma question devient : Pourquoi utiliser plusieurs
hyperviseurs simultanément sur le même système ?

Hum
Le #1863453
Ça peut être valable dans le cas où tu veux tester un Esxi ou Proxmox depuis ta machine. Du style "je veux tester la dernière version de Proxmox qui viens de sortir mais je n'ai pas de serveur dispo"
Le #1863483
Ça fait un certain temps qu'on peut le faire sous d'autres systèmes d'exploitation. L'intérêt étant par exemple d'avoir une VM qui fait tourner plusieurs autres VMs à fin de tests (l'exemple que cite droide), ou de faire tourner plusieurs containers/paravirts/HVM dans une VM, soit des VMs dans la VM faisant tourner un pacson de containers. Rien de bien neuf ceci dit, mais c'est pas plus mal que Microsoft se mette enfin à la page à ce niveau là.

L'utilité en DC? maximiser l'utilisation des ressources encore plus qu'avec de la virtualisation classique. (par ex, une machine 40 cœurs logiques, 256Go de RAM. Elle peut faire tourner un bon paquet de VMs, mais qui elles mêmes ne seront pas forcément utilisées "à fond". Donc on rajoute un hyperviseur sur chaque VM, et on maximise l'utilisation des CPUs et de la RAM. Par contre, faut pas se planter en dimensionnant la chose).

Le défaut? les entrées/sorties. À un moment, il faut que les I/Os disques et réseau suivent.

Pour citer l'article et le corriger un chouilla:

"Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux *depuis longtemps*" - FTFY
Le #1863485
lidstah a écrit :

Ça fait un certain temps qu'on peut le faire sous d'autres systèmes d'exploitation. L'intérêt étant par exemple d'avoir une VM qui fait tourner plusieurs autres VMs à fin de tests (l'exemple que cite droide), ou de faire tourner plusieurs containers/paravirts/HVM dans une VM, soit des VMs dans la VM faisant tourner un pacson de containers. Rien de bien neuf ceci dit, mais c'est pas plus mal que Microsoft se mette enfin à la page à ce niveau là.

L'utilité en DC? maximiser l'utilisation des ressources encore plus qu'avec de la virtualisation classique. (par ex, une machine 40 cœurs logiques, 256Go de RAM. Elle peut faire tourner un bon paquet de VMs, mais qui elles mêmes ne seront pas forcément utilisées "à fond". Donc on rajoute un hyperviseur sur chaque VM, et on maximise l'utilisation des CPUs et de la RAM. Par contre, faut pas se planter en dimensionnant la chose).

Le défaut? les entrées/sorties. À un moment, il faut que les I/Os disques et réseau suivent.

Pour citer l'article et le corriger un chouilla:

"Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux *depuis longtemps*" - FTFY


Hum, je vais retenir l'idée de maximiser l'utilisation des ressources.

Mais dans ce cas, tu peux me dire pourquoi es-ce que tu ne change de pas d'hyperviseur ?

Si j'ai bien suivi ton explication (j'ai un gros doute), tu monte une VM dans une VM parce que ta première VM n'exploite pas pleinement les ressources que tu lui as attribuée,
du coup, pour moi la solution n'est pas de remonter une VM dedans pour éviter
le hachis mais de changer pour un hyperviseur capable de mieux gérer les
ressources attribuées nn ?
Le #1863527
5COMM a écrit :

lidstah a écrit :

Ça fait un certain temps qu'on peut le faire sous d'autres systèmes d'exploitation. L'intérêt étant par exemple d'avoir une VM qui fait tourner plusieurs autres VMs à fin de tests (l'exemple que cite droide), ou de faire tourner plusieurs containers/paravirts/HVM dans une VM, soit des VMs dans la VM faisant tourner un pacson de containers. Rien de bien neuf ceci dit, mais c'est pas plus mal que Microsoft se mette enfin à la page à ce niveau là.

L'utilité en DC? maximiser l'utilisation des ressources encore plus qu'avec de la virtualisation classique. (par ex, une machine 40 cœurs logiques, 256Go de RAM. Elle peut faire tourner un bon paquet de VMs, mais qui elles mêmes ne seront pas forcément utilisées "à fond". Donc on rajoute un hyperviseur sur chaque VM, et on maximise l'utilisation des CPUs et de la RAM. Par contre, faut pas se planter en dimensionnant la chose).

Le défaut? les entrées/sorties. À un moment, il faut que les I/Os disques et réseau suivent.

Pour citer l'article et le corriger un chouilla:

"Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux *depuis longtemps*" - FTFY


Hum, je vais retenir l'idée de maximiser l'utilisation des ressources.

Mais dans ce cas, tu peux me dire pourquoi es-ce que tu ne change de pas d'hyperviseur ?

Si j'ai bien suivi ton explication (j'ai un gros doute), tu monte une VM dans une VM parce que ta première VM n'exploite pas pleinement les ressources que tu lui as attribuée,
du coup, pour moi la solution n'est pas de remonter une VM dedans pour éviter
le hachis mais de changer pour un hyperviseur capable de mieux gérer les
ressources attribuées nn ?


salut,

l’idée de jouer au poupes russe avec les hyperviseur sert juste pour tester un hyperviseur sans reformater a chaque fois un serveur en hardware. exemple un serveur avec "windows 10 + hyperv 10565" permet de tester une version beta de vmware ESXi avec dedans une vm avec windows 8.1, le but et de voire les reaction du win8.1 dans "vmware esxi beta"

quand tu ecris : Hyper V & co : du virtuel sur un os

c est faux un hyperviseur se place toujour entre le hardware et l'os, dans le cas de hyperv ton bureau et tous ton os deviens une sorte de VM pour simplifier, au meme niveau que tes vm dans la consoler hyperv les ressource sont partager équitablement entre ton "bureau" et tes vm .
Le #1863535
tetenfer a écrit :

5COMM a écrit :

lidstah a écrit :

Ça fait un certain temps qu'on peut le faire sous d'autres systèmes d'exploitation. L'intérêt étant par exemple d'avoir une VM qui fait tourner plusieurs autres VMs à fin de tests (l'exemple que cite droide), ou de faire tourner plusieurs containers/paravirts/HVM dans une VM, soit des VMs dans la VM faisant tourner un pacson de containers. Rien de bien neuf ceci dit, mais c'est pas plus mal que Microsoft se mette enfin à la page à ce niveau là.

L'utilité en DC? maximiser l'utilisation des ressources encore plus qu'avec de la virtualisation classique. (par ex, une machine 40 cœurs logiques, 256Go de RAM. Elle peut faire tourner un bon paquet de VMs, mais qui elles mêmes ne seront pas forcément utilisées "à fond". Donc on rajoute un hyperviseur sur chaque VM, et on maximise l'utilisation des CPUs et de la RAM. Par contre, faut pas se planter en dimensionnant la chose).

Le défaut? les entrées/sorties. À un moment, il faut que les I/Os disques et réseau suivent.

Pour citer l'article et le corriger un chouilla:

"Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux *depuis longtemps*" - FTFY


Hum, je vais retenir l'idée de maximiser l'utilisation des ressources.

Mais dans ce cas, tu peux me dire pourquoi es-ce que tu ne change de pas d'hyperviseur ?

Si j'ai bien suivi ton explication (j'ai un gros doute), tu monte une VM dans une VM parce que ta première VM n'exploite pas pleinement les ressources que tu lui as attribuée,
du coup, pour moi la solution n'est pas de remonter une VM dedans pour éviter
le hachis mais de changer pour un hyperviseur capable de mieux gérer les
ressources attribuées nn ?


salut,

l’idée de jouer au poupes russe avec les hyperviseur sert juste pour tester un hyperviseur sans reformater a chaque fois un serveur en hardware. exemple un serveur avec "windows 10 + hyperv 10565" permet de tester une version beta de vmware ESXi avec dedans une vm avec windows 8.1, le but et de voire les reaction du win8.1 dans "vmware esxi beta"

quand tu ecris : Hyper V & co : du virtuel sur un os

c est faux un hyperviseur se place toujour entre le hardware et l'os, dans le cas de hyperv ton bureau et tous ton os deviens une sorte de VM pour simplifier, au meme niveau que tes vm dans la consoler hyperv les ressource sont partager équitablement entre ton "bureau" et tes vm .


" Hyper V & co : du virtuel sur un os " : abus de langage de ma part

Pour résumer (si je t'ai bien suivi), l'idée de Nested (qui est un hyperviseur ?) c'est de permettre de virtualiser un autre hyperviseur (ESXi) qui va lui même virtualiser une VM [W8] dans le but de tester l'hyperviseur (ESXi) ?

(évitant donc de faire le test sur une seconde machine dont il faudrait faire l'acquisition et sans mettre en danger l'installation initiale de l'hyperviseur)

Du coup, tu pourrais placer Nested entre le matériel et ESXi comme tu pourrais le placer
"dans" une VM ? [ Putin, les gros fans d'inception ici ]

Le #1863590
5COMM a écrit :

tetenfer a écrit :

5COMM a écrit :

lidstah a écrit :

Ça fait un certain temps qu'on peut le faire sous d'autres systèmes d'exploitation. L'intérêt étant par exemple d'avoir une VM qui fait tourner plusieurs autres VMs à fin de tests (l'exemple que cite droide), ou de faire tourner plusieurs containers/paravirts/HVM dans une VM, soit des VMs dans la VM faisant tourner un pacson de containers. Rien de bien neuf ceci dit, mais c'est pas plus mal que Microsoft se mette enfin à la page à ce niveau là.

L'utilité en DC? maximiser l'utilisation des ressources encore plus qu'avec de la virtualisation classique. (par ex, une machine 40 cœurs logiques, 256Go de RAM. Elle peut faire tourner un bon paquet de VMs, mais qui elles mêmes ne seront pas forcément utilisées "à fond". Donc on rajoute un hyperviseur sur chaque VM, et on maximise l'utilisation des CPUs et de la RAM. Par contre, faut pas se planter en dimensionnant la chose).

Le défaut? les entrées/sorties. À un moment, il faut que les I/Os disques et réseau suivent.

Pour citer l'article et le corriger un chouilla:

"Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux *depuis longtemps*" - FTFY


Hum, je vais retenir l'idée de maximiser l'utilisation des ressources.

Mais dans ce cas, tu peux me dire pourquoi es-ce que tu ne change de pas d'hyperviseur ?

Si j'ai bien suivi ton explication (j'ai un gros doute), tu monte une VM dans une VM parce que ta première VM n'exploite pas pleinement les ressources que tu lui as attribuée,
du coup, pour moi la solution n'est pas de remonter une VM dedans pour éviter
le hachis mais de changer pour un hyperviseur capable de mieux gérer les
ressources attribuées nn ?


salut,

l’idée de jouer au poupes russe avec les hyperviseur sert juste pour tester un hyperviseur sans reformater a chaque fois un serveur en hardware. exemple un serveur avec "windows 10 + hyperv 10565" permet de tester une version beta de vmware ESXi avec dedans une vm avec windows 8.1, le but et de voire les reaction du win8.1 dans "vmware esxi beta"

quand tu ecris : Hyper V & co : du virtuel sur un os

c est faux un hyperviseur se place toujour entre le hardware et l'os, dans le cas de hyperv ton bureau et tous ton os deviens une sorte de VM pour simplifier, au meme niveau que tes vm dans la consoler hyperv les ressource sont partager équitablement entre ton "bureau" et tes vm .


" Hyper V & co : du virtuel sur un os " : abus de langage de ma part

Pour résumer (si je t'ai bien suivi), l'idée de Nested (qui est un hyperviseur ?) c'est de permettre de virtualiser un autre hyperviseur (ESXi) qui va lui même virtualiser une VM [W8] dans le but de tester l'hyperviseur (ESXi) ?

(évitant donc de faire le test sur une seconde machine dont il faudrait faire l'acquisition et sans mettre en danger l'installation initiale de l'hyperviseur)

Du coup, tu pourrais placer Nested entre le matériel et ESXi comme tu pourrais le placer
"dans" une VM ? [ Putin, les gros fans d'inception ici ]


Oui, mais la vraie utilisation la plus puissante est celle ci :

Supposons que tu veux tester la haute disponibilité des serveurs Proxmox. En physique, il faut au minimum 2 voir 3 machines. En virtualisé une seule machine suffit.

On teste la bascule, la répartition tout cela en virtuel. Je l'ai fait aussi pour réaliser des supports de cours, ...


Le #1863594
5COMM a écrit :

tetenfer a écrit :

5COMM a écrit :

lidstah a écrit :

Ça fait un certain temps qu'on peut le faire sous d'autres systèmes d'exploitation. L'intérêt étant par exemple d'avoir une VM qui fait tourner plusieurs autres VMs à fin de tests (l'exemple que cite droide), ou de faire tourner plusieurs containers/paravirts/HVM dans une VM, soit des VMs dans la VM faisant tourner un pacson de containers. Rien de bien neuf ceci dit, mais c'est pas plus mal que Microsoft se mette enfin à la page à ce niveau là.

L'utilité en DC? maximiser l'utilisation des ressources encore plus qu'avec de la virtualisation classique. (par ex, une machine 40 cœurs logiques, 256Go de RAM. Elle peut faire tourner un bon paquet de VMs, mais qui elles mêmes ne seront pas forcément utilisées "à fond". Donc on rajoute un hyperviseur sur chaque VM, et on maximise l'utilisation des CPUs et de la RAM. Par contre, faut pas se planter en dimensionnant la chose).

Le défaut? les entrées/sorties. À un moment, il faut que les I/Os disques et réseau suivent.

Pour citer l'article et le corriger un chouilla:

"Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux *depuis longtemps*" - FTFY


Hum, je vais retenir l'idée de maximiser l'utilisation des ressources.

Mais dans ce cas, tu peux me dire pourquoi es-ce que tu ne change de pas d'hyperviseur ?

Si j'ai bien suivi ton explication (j'ai un gros doute), tu monte une VM dans une VM parce que ta première VM n'exploite pas pleinement les ressources que tu lui as attribuée,
du coup, pour moi la solution n'est pas de remonter une VM dedans pour éviter
le hachis mais de changer pour un hyperviseur capable de mieux gérer les
ressources attribuées nn ?


salut,

l’idée de jouer au poupes russe avec les hyperviseur sert juste pour tester un hyperviseur sans reformater a chaque fois un serveur en hardware. exemple un serveur avec "windows 10 + hyperv 10565" permet de tester une version beta de vmware ESXi avec dedans une vm avec windows 8.1, le but et de voire les reaction du win8.1 dans "vmware esxi beta"

quand tu ecris : Hyper V & co : du virtuel sur un os

c est faux un hyperviseur se place toujour entre le hardware et l'os, dans le cas de hyperv ton bureau et tous ton os deviens une sorte de VM pour simplifier, au meme niveau que tes vm dans la consoler hyperv les ressource sont partager équitablement entre ton "bureau" et tes vm .


" Hyper V & co : du virtuel sur un os " : abus de langage de ma part

Pour résumer (si je t'ai bien suivi), l'idée de Nested (qui est un hyperviseur ?) c'est de permettre de virtualiser un autre hyperviseur (ESXi) qui va lui même virtualiser une VM [W8] dans le but de tester l'hyperviseur (ESXi) ?

(évitant donc de faire le test sur une seconde machine dont il faudrait faire l'acquisition et sans mettre en danger l'installation initiale de l'hyperviseur)

Du coup, tu pourrais placer Nested entre le matériel et ESXi comme tu pourrais le placer
"dans" une VM ? [ Putin, les gros fans d'inception ici ]


exactement ta aussi la virtualisation de stockage qui est sympa et très pratique, et de réseaux chiante et lourde a gérè.
Le #1863601
Merci pour vos réponses les gars.

J'avais tout de suite compris ce concept :
"exemple un serveur avec "windows 10 + hyperv 10565" permet de tester une version beta de vmware ESXi avec dedans une vm avec windows 8.1, le but et de voire les reaction du win8.1 dans "vmware esxi beta""

Mais pas celui d'une optimisation encore plus fine des ressources physiques. J'avoue rester un peu dubitatif la dessus, et je reste sur les mêmes questionnements que 5COMM

Pour la construction d'une archi complexe, c'est sûr qu'on y gagne quand même, pas besoin de monter X hyperviseurs.
Le #1863607
NET6a a écrit :

5COMM a écrit :

tetenfer a écrit :

5COMM a écrit :

lidstah a écrit :

Ça fait un certain temps qu'on peut le faire sous d'autres systèmes d'exploitation. L'intérêt étant par exemple d'avoir une VM qui fait tourner plusieurs autres VMs à fin de tests (l'exemple que cite droide), ou de faire tourner plusieurs containers/paravirts/HVM dans une VM, soit des VMs dans la VM faisant tourner un pacson de containers. Rien de bien neuf ceci dit, mais c'est pas plus mal que Microsoft se mette enfin à la page à ce niveau là.

L'utilité en DC? maximiser l'utilisation des ressources encore plus qu'avec de la virtualisation classique. (par ex, une machine 40 cœurs logiques, 256Go de RAM. Elle peut faire tourner un bon paquet de VMs, mais qui elles mêmes ne seront pas forcément utilisées "à fond". Donc on rajoute un hyperviseur sur chaque VM, et on maximise l'utilisation des CPUs et de la RAM. Par contre, faut pas se planter en dimensionnant la chose).

Le défaut? les entrées/sorties. À un moment, il faut que les I/Os disques et réseau suivent.

Pour citer l'article et le corriger un chouilla:

"Cette technologie n'est pas propre à Windows et se retrouve aussi intégrée au noyau Linux *depuis longtemps*" - FTFY


Hum, je vais retenir l'idée de maximiser l'utilisation des ressources.

Mais dans ce cas, tu peux me dire pourquoi es-ce que tu ne change de pas d'hyperviseur ?

Si j'ai bien suivi ton explication (j'ai un gros doute), tu monte une VM dans une VM parce que ta première VM n'exploite pas pleinement les ressources que tu lui as attribuée,
du coup, pour moi la solution n'est pas de remonter une VM dedans pour éviter
le hachis mais de changer pour un hyperviseur capable de mieux gérer les
ressources attribuées nn ?


salut,

l’idée de jouer au poupes russe avec les hyperviseur sert juste pour tester un hyperviseur sans reformater a chaque fois un serveur en hardware. exemple un serveur avec "windows 10 + hyperv 10565" permet de tester une version beta de vmware ESXi avec dedans une vm avec windows 8.1, le but et de voire les reaction du win8.1 dans "vmware esxi beta"

quand tu ecris : Hyper V & co : du virtuel sur un os

c est faux un hyperviseur se place toujour entre le hardware et l'os, dans le cas de hyperv ton bureau et tous ton os deviens une sorte de VM pour simplifier, au meme niveau que tes vm dans la consoler hyperv les ressource sont partager équitablement entre ton "bureau" et tes vm .


" Hyper V & co : du virtuel sur un os " : abus de langage de ma part

Pour résumer (si je t'ai bien suivi), l'idée de Nested (qui est un hyperviseur ?) c'est de permettre de virtualiser un autre hyperviseur (ESXi) qui va lui même virtualiser une VM [W8] dans le but de tester l'hyperviseur (ESXi) ?

(évitant donc de faire le test sur une seconde machine dont il faudrait faire l'acquisition et sans mettre en danger l'installation initiale de l'hyperviseur)

Du coup, tu pourrais placer Nested entre le matériel et ESXi comme tu pourrais le placer
"dans" une VM ? [ Putin, les gros fans d'inception ici ]


Oui, mais la vraie utilisation la plus puissante est celle ci :

Supposons que tu veux tester la haute disponibilité des serveurs Proxmox. En physique, il faut au minimum 2 voir 3 machines. En virtualisé une seule machine suffit.

On teste la bascule, la répartition tout cela en virtuel. Je l'ai fait aussi pour réaliser des supports de cours, ...


Proxmox : Je ne sais même pas ce que c'est
Quand tu dis bascule/répartition : tu peux être plus précis ?

Tetenfer : virtualisation de stockage hum, tu peux m'en dire plus ?
Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]