 Bonne matin, tout le monde. Merci d'être avec moi. Alors, je vais m'expliquer comment se plait un cake. Non, je suis désolé, j'étais en train de jeter. Mais en fait, comment se plait un gpu virtualisé en utilisant OpenStack Nova ? Alors, premièrement, je vais vite expliquer qui je suis. Alors, je suis Sylvain, je suis français. Et je travaille pour Red Hat comme un ingénieur de software depuis 6 ans, je pense. Je suis aussi un maintaineur Nova Core depuis 5 ans. Mais avant de discuter comment se plait un gpu, je vais m'expliquer comment utiliser un gpu d'une autre façon, d'utiliser un gpu pass-through. Peut-être que vous savez bien qu'un gpu pass-through, ou un PCI pass-through si vous préférez, c'est simple que quelque chose qui a été supporté par Nova depuis Havana, un long time avant. Et, basiquement, c'est à propos de donner directement un PCI à l'instance, passer directement à l'instance. Donc, vous avez un 1-2-1 map entre un gpu physique et un gpu virtualisé. Ici, dans notre cas, un gpu physique et le gpu de l'instance. Ce qui est also nice c'est que ce n'est pas seulement pour un gpu comme je l'ai dit, mais pour d'autres types d'devices PCI, incluant les cartes de réseau d'exemple, les cartes d'exemple ou les cartes d'exemple d'exemple Intel Q80. Ce qui a été dit, il y a des limitations d'orcavia si vous préférez utiliser un gpu pass-through et un gpu pass-through. Le premier de ceux, c'est que vous n'avez pas de faim pour monitor l'introspection, le hardware que vous passez à l'instance parce que le kernel directement bouge le gpu à l'instance. Donc, vous avez un manque de visibilité. Il y a aussi des concerns de sécurité avec ptr pass-through et gpu pass-through. Basiquement, aucun utilisateur malécié peut réfléchir le PCI-device. Par exemple, pensez sur les FPGAs. Si vous pentez un FPGA à l'instance, aucun utilisateur peut réfléchir. Pour gpu, aucun utilisateur peut essayer d'évoquer ou d'évoquer juste par utiliser l'envider. Et pour d'autres cartes, ce sera le même problème. Et la dernière, vous avez des limitations physiques. Bien sûr, parce que du motherboard, parce que du slot PCI. Mais si vous aussi connaissez le PCI Express, vous savez que c'est des lanes PCI Express. Certaines CPUs seulement acceptent 40 lanes. Donc, par exemple, si vous avez un GPU, si vous avez un GPU, en utilisant 8 lanes, vous pouvez imaginer que vous n'aurez pas beaucoup de GPU, beaucoup de GPUs qui peuvent, aujourd'hui, s'occuper d'un CPU. Donc, vous avez aussi des limitations par slot et par CPU. Ce sont les raisons, basiquement, pourquoi les vendeurs hardware tentent de créer des GPUs virtuels. Et laissez-moi expliquer avant d'expliquer comment utiliser ça en Nova. Tout ça fonctionne. Donc, basiquement, c'est d'avoir plus que un single GPU virtuel, par GPU. C'est bon. Et ce qui est très bon, c'est que vous pouvez profilier un nombre de GPUs virtuels, par exemple, pour les mêmes visuels GPUs. Vous pourriez avoir soit 1 virtuel de GPU ou plus de 16. Ça dépend de le profil que vous avez pour ce GPU. Je vais expliquer ça plus tard. Ce qu'il faut aussi savoir, c'est que c'est dans la Nova que vous pouvez imaginer les cases de utilisation. Si vous pouvez profilier les cases de utilisation, vous pouvez aussi utiliser ça pour le VDI ou pour les proposed. Par exemple, si vous voulez avoir un desktop 3D ou un desktop 2D, certains autres préfèrent avoir un large performance. Comment ça fonctionne en pratique ? Vous avez un API managable qui est fait par la nouvelle module de kernel. Toutes les hardwares que vous avez ont été réalisées. Les hardwares sont prises par le module de kernel. Pour l'envers, c'est pour Nvidia et Intel qu'ils ont un module de kernel qui crée un GPU virtuel, ce que je dirais. Ce qui est bien c'est que ce module de kernel vous aide à introspecter les hardwares. Dès que vous n'êtes pas passés directement par le GPU, vous avez un moyen de regarder les hostOS par exemple sur les performances de la GPU ou sur le nombre de GPU virtuel créées. Il y a quelques caveats que vous avez besoin de savoir. Au moins, il y a un sujet qui est rendu spécifique. Il y a quelques questions pour la licence. C'est le cas pour Nvidia. Et il y a quelques autres questions pour quelques produits spécifiques. Et c'est le cas pour les deux. Par exemple, avec Nvidia, vous avez besoin d'un licencieur avec des hardwares spécifiques, test-lackers, surtout, et pour Intel, vous avez besoin d'un licencieur avec des hardwares spécifiques au moins. Et selon tout ce que vous avez fait par le module de kernel, vous avez des limitations par le module. Par exemple, en cas de Nvidia, vous pouvez voir ces spécifiques limitations. Si vous voulez vraiment voir Nvidia vGPUs, regardez la documentation d'aujourd'hui, et regardez si ces limitations sont encore là ou non. Peut-être qu'elles sont déjà fixées par un réel de la module de kernel. Je ne sais pas, d'ailleurs. J'ai parlé des profils, des profils de GPU, donc pensez à le même profil qui vous donne une façon de créer un autre type de GPU. Par exemple, en cas de V100 PCI Express pour une GPU, ce que vous pouvez faire c'est de choisir entre un profil qui vous donne une façon de créer une seule GPU ou une seule GPU virtual ou d'utiliser un autre profil où vous pouvez créer une sortie de GPU virtual. Bien sûr, les performances seraient différentes mais ça va vraiment dépendre de ce que vous voulez. Ne pensez pas qu'il n'y ait pas de manière d'avoir deux profils différents pour le même GPU. Pour une GPU, vous devez penser sur le type de GPU que vous devez obtenir. C'est très simple dans Linux. Le kernel Linux ne utilise VFIO des devices des fonctions virtuales d'input et d'input. Donc, nous allons voir comment cela a travaillé dans la pratique. Cela a un Intel GPU C'est un P30 GPU. Pour l'utiliser vous devez avoir le kernel d'utiliser GBTG. Donc, de cette façon vous devez l'utiliser. Mais ensuite, vous devez aussi rouler le module Intel KVM GT Voyez-le. Comme vous pouvez le voir, ce module va maintenant créer une nouvelle chipseture nommée MdevBus. Et puis vous devez voir tous les types supportés. Par exemple, ici, pour cette GPU nous avons deux types. Donc, je vais vous montrer pour Nvidia GPUs. C'est un nouveau terminal. Donc, comme vous pouvez le voir pour ces différents hosts nous avons un P30 controller un TESLA T4 GPU. Basiquement, vous devez faire le même que pour Intel. Vous devez profiter un module kernel. Vous devez voir Nvidia Mdev. Et puis vous devez avoir la même bus Mdev chipseture. Par exemple, cette GPU a plus de types supportés, comme vous pouvez le voir. Donc, maintenant que j'explique comment voir les types supportés je vais discuter comment utiliser Nova pour cela. Donc, comment utiliser ça. C'est très simple. Vous devez donner des configurations d'options comme vous pouvez le voir. Et puis créer un flavor. Vous devez voir la GPU documentation ici. Mais laissez-moi savoir provider un depot. Donc, maintenant, j'ai un terminal avec un HMV composé d'un nouveau controller et deux notes computers, comme vous pouvez le voir. Chaque of them a Nvidia card T-Slatifier comme vous pouvez le voir ici pour la première. Et pour la seconde la même GPU card. Donc, depuis qu'il y a beaucoup de types et je ne sais pas quelle, laissez-moi vous montrer comment les voir en utilisant la documentation Nvidia. Donc, par exemple, sur la documentation T-Slatifier la documentation Nvidia. Et nous pouvons voir que il y a plusieurs types. Mais ici, par exemple, nous sommes intéressés par deux différents types utilisés pour l'influence et pour l'entraînement. Donc, par exemple, la T-44C et la T-48C. Donc, laissez-moi créer des types de GPU virtual pour 1 ce type et pour l'autre compute utilisant ce type. Donc, let's go back to the terminal and see how we are going to use it. Ok, so basically I know the GPU types. So, the easiest is to look at which Nvidia number is actually having this type. So, for example, here this is the 319 type. But if I want to do this for the other type let me just show you that's basically the same. So, for the other host that's the Nvidia 320 type which is actually correct. So, as you may see I actually created a new option in the nova compute configuration file. So, for this host, I asked to use that specific type with this specific PCI address which if you remember, that's optional. That section is optional but that's for example if you have multiple GPUs for this host you can specify a GPU type difference in between each GPU. But, basically, here you can see the PCI address here and I basically did the same on the other host. Sorry about that. I'm just a typo. Yep, there it is. There it is. So, as you can see, I asked the nova compute to use this specific type Once you modify nova comf for every compute, then of course you need to restart the compute service but then after restarting the compute service you can actually verify that then you have two new resource providers each of them corresponding to a GPU. In my case for this host, I can see this specific GPU and for this host, this other GPU. And for example when I look at this resource provider then you can see that I can actually create four virtual GPUs for this GPU. What I also did because since I had two different types for two different GPUs I also wanted to make sure that some flavors will ask different types. So for this, the documentation says that you need to create a trait that's what I did for this resource provider. So I manually created a trait named custom nvidia 319 that gives you a way to say ok, this one supports this specific type. And the same goes for the other GPU, I mean I can only create two virtual GPUs with this other type and accordingly I can see it on the trait. Remember that you have to manually create the trait. Then the documentation says ok, then you have to provide a new flavor that's what I did. I actually created two flavors for my environment and what I had to do is to ask for that flavor to create one virtual GPU with this flavor with this specific trait. So if I want to create an instance having one virtual GPU supported by this type that's how you make it and that's pretty the same for the other, right? You can basically see the difference in between those two. The only difference is about which specific kind of GPU you would like to create. Then I'm actually happy to say that you made all the work because then you can ask your users to just use the flavors that you created in order to generate some instances. So in this case I want to create a new instance with that specific flavor so I will use a GPU for the other computer height with a CentOS image which is a bit tuned because I had to install the NVIDIA driver itself. Let me actually issue this. Cool. I now have a new instance. Let me check whether the instance is there. Great. So the instance is active. As you can see the host is the correct one. There is no scaling issue. You can see the spec itself. So you know what? Let's go and check the instance itself. But in order to make it I will just use a floating IP. So I will just attach a floating IP because then it will be easier for me to check it. Ok so the instance is booted. Let's connect to the host. Yes. You can see that's nice. Remember that I have to use that specific type indeed. And then you have the virtual GPU. Which is within the instance. Last but not the least remember that I also created another instance with another GPU with that other type. So if for example I look at the hostOS not within the instance but at the hostOS. Remember when I was talking about monitoring as you may see that I can see the tiffer with one single virtual GPU created. So you can basically introspect it right. And on the other compute you can also see the virtual GPU. So I had one instance running on that host with one virtual GPU attach. And on the other compute I also had one instance with another GPU type. I hope that this demo helped you to exactly understand how this works with OpenStack Nova. But let me briefly explain the next features for that and what we would like to see for next cycles. So what would be next for virtual GPUs in Nova. Of course we have a few bugs. You can look at the documentation. I provided all the non issues. A few of them not a lot but still. Some operators also would like to have a specific Cota class Of course, because that's a new resource. Some others also would like to have some new affinity with CPU resources. Sometimes because of some stuff they would like to make sure that they don't have any performance problems. That's a big feature to do but we are trying to do it. And the last one is about live migrating virtual GPUs. The problem that we have is that for the moment KVM doesn't really support live migrations. So once it will be done then hopefully Nova will support it for the next cycles. That's it for my session. So if you have some questions ask for me. Thanks.