> > Thanks for your reply, Sanjay. I understand that it's only K1 and K2 cards > > at the moment, but when they add more, do we really want to have > > to edit the code to match? What is the notification process by which we > > know there are new types? Does the user have to upgrade CloudStack > > to get access to the new types? In contrast, if we could use the current > > list from the server, we don't have to worry about it: it will > > just keep itself up to date.
If we look at [1] section "Interoperability and compatibility requirements" each of the cards supports certain profiles which has underpinning to Video RAM it supports, no of vGPUs that can be supported on one physical GPU. These mapping are maintained in CS. This mapping is required for the planner to pick a host which has the required resources to deploy a VM. Currently XenServer does not expose the Video RAM that each profile supports. Once we have that and all other loose ends around resources available vs used are taken care of then we can try to dynamically learn the lists from the hosts. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/GPU+and+vGPU+support+for+CloudStack+Guest+VMs > You can take a somewhat similar view on the vmware disk controller issue > (cloudstack-4787 iirc) , where it is hard coded what to use, and changing it > to > ui based has taken a couple of versions and is still not fixed. Which is why > I would vote against any hard coded value that could and should either be > dynamic or user specified. Sateesh and I had some good discussions around this. I am sure this will surface as a proposal very soon. Thanks, RamG > -----Original Message----- > From: Erik Weber [mailto:terbol...@gmail.com] > Sent: 12 March 2014 21:16 > To: dev > Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU > support for XenServer. > > Anything that's hard coded is potentially a problem to change for a user. > > You can take a somewhat similar view on the vmware disk controller issue > (cloudstack-4787 iirc) , where it is hard coded what to use, and changing it > to > ui based has taken a couple of versions and is still not fixed. Which is why i > would vote against any hard coded value that could and should either be > dynamic or user specified. > > Regards, > Erik Weber > 12. mars 2014 16:24 skrev "Stephen Turner" <stephen.tur...@citrix.com> > følgende: > > > Does anyone else have a view on this? I'm not familiar with the code > > base yet, so am I worrying about nothing? > > > > -- > > Stephen Turner > > > > > > -----Original Message----- > > From: Stephen Turner [mailto:stephen.tur...@citrix.com] > > Sent: 11 March 2014 16:13 > > To: dev@cloudstack.apache.org > > Cc: Sanjay Tripathi > > Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU > > support for XenServer. > > > > Thanks for your reply, Sanjay. I understand that it's only K1 and K2 > > cards at the moment, but when they add more, do we really want to have > > to edit the code to match? What is the notification process by which > > we know there are new types? Does the user have to upgrade CloudStack > > to get access to the new types? In contrast, if we could use the > > current list from the server, we don't have to worry about it: it will > > just keep itself up to date. > > > > -- > > Stephen Turner > > > > > > -----Original Message----- > > From: Sanjay Tripathi > > Sent: 11 March 2014 16:05 > > To: Stephen Turner; dev@cloudstack.apache.org > > Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU > > support for XenServer. > > > > Hi Stephen, > > > > As of now, there are 2 GPU cards available in market i.e. NVIDIA GRID > > K1 and K2 cards. These card supports 5 different configurations of > > vGPUs which we call as vGPU types (for details: > > http://www.nvidia.com/object/virtual-gpus.html). In future, if this > > list grows, then we'll add a separate table similar to guest_os table, > > which will have the list of supported vGPU types. > > > > Also, the table "vgpu_types" has the entries of different vGPU types > > supported in hosts managed by CloudStack. > > > > --Sanjay > > > > -----Original Message----- > > From: Stephen Turner > > Sent: Tuesday, March 11, 2014 5:54 PM > > To: dev@cloudstack.apache.org > > Cc: Sanjay Tripathi > > Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU > > support for XenServer. > > > > I see that the change has been pushed already, but I'm a bit concerned > > about there being a hard-coded list of vGPU types in the class GPU. I > > anticipate that Nvidia or other vendors will add more vGPU types > > later, and this will require us to keep up with the list. Is there a > > way we can use the list of vGPU types returned from the servers instead? > > > > -- > > Stephen Turner > > > > > > > > -----Original Message----- > > From: ASF Subversion and Git Services > > [mailto:nore...@reviews.apache.org] > > On Behalf Of ASF Subversion and Git Services > > Sent: 11 March 2014 10:10 > > To: Koushik Das; Devdeep Singh; Alex Huang > > Cc: Sanjay Tripathi; ASF Subversion and Git Services; cloudstack > > Subject: Re: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU > > support for XenServer. > > > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > https://reviews.apache.org/r/17889/#review36769 > > ----------------------------------------------------------- > > > > > > Commit c7d31fe288b13ff4f0f046f83f9eb4a9c2bf06c5 in cloudstack's branch > > refs/heads/master from Sanjay Tripathi [ > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7d31fe ] > > > > CLOUDSTACK-4760 : Enabling GPU support for XenServer. > > CLOUDSTACK-4762 : Enabling VGPU support for XenServer. > > > > This feature is to enable the GPU-passthrough and vGPU functionality, > > with the help of this feature, admins/users will be able to leverage > > the GPU graphics unit power by deploying a virtul machine with GPU or > > vGPU support or by changing the service offering of an existing VM at > > any later point of time. There GPU/vGPU enabled VMs are able to run > graphical applications. > > For now, this feature is only supported with XenServer hypervisor but > > can be extended to add the support of other hypervisors. > > > > > > - ASF Subversion and Git Services > > > > > > On Feb. 27, 2014, 12:35 p.m., Sanjay Tripathi wrote: > > > > > > ----------------------------------------------------------- > > > This is an automatically generated e-mail. To reply, visit: > > > https://reviews.apache.org/r/17889/ > > > ----------------------------------------------------------- > > > > > > (Updated Feb. 27, 2014, 12:35 p.m.) > > > > > > > > > Review request for cloudstack, Alex Huang, Devdeep Singh, and > > > Koushik > > Das. > > > > > > > > > Bugs: CLOUDSTACK-4760 and CLOUDSTACK-4762 > > > https://issues.apache.org/jira/browse/CLOUDSTACK-4760 > > > https://issues.apache.org/jira/browse/CLOUDSTACK-4762 > > > > > > > > > Repository: cloudstack-git > > > > > > > > > Description > > > ------- > > > > > > CLOUDSTACK-4760 : Enabling GPU support for XenServer. > > > CLOUDSTACK-4762 : Enabling VGPU support for XenServer. > > > > > > This feature is to enable the GPU-passthrough and vGPU > > > functionality, with the help of this feature, admins/users will be > > > able to leverage the GPU graphics unit power by deploying a virtul > > > machine with GPU or vGPU support or by changing the service offering > > > of an existing VM at any later point of time. There GPU/vGPU enabled > > > VMs are able to run graphical applications. > > > For now, this feature is only supported with XenServer hypervisor > > > but can be extended to add the support of other hypervisors. > > > > > > > > > Diffs > > > ----- > > > > > > api/src/com/cloud/agent/api/to/GPUDeviceTO.java PRE-CREATION > > > api/src/com/cloud/agent/api/to/VirtualMachineTO.java bed3e1d > > > api/src/com/cloud/gpu/GPU.java PRE-CREATION > > > api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca > > > > > > api/src/org/apache/cloudstack/api/command/admin/offering/CreateService > > OfferingCmd.java > > 1d8cbff > > > api/src/org/apache/cloudstack/api/response/GpuResponse.java > > PRE-CREATION > > > api/src/org/apache/cloudstack/api/response/HostResponse.java > e2d8eb5 > > > api/src/org/apache/cloudstack/api/response/UserVmResponse.java > 84d532b > > > api/src/org/apache/cloudstack/api/response/VgpuResponse.java > > PRE-CREATION > > > core/src/com/cloud/agent/api/GetGPUStatsAnswer.java PRE- > CREATION > > > core/src/com/cloud/agent/api/GetGPUStatsCommand.java PRE- > CREATION > > > core/src/com/cloud/agent/api/StartupRoutingCommand.java 626c87f > > > core/src/com/cloud/agent/api/StopCommand.java 6a29aa6 > > > engine/components- > api/src/com/cloud/resource/ResourceManager.java > > 95fb385 > > > > > > > engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java > > d19fc38 > > > > > engine/schema/resources/META-INF/cloudstack/core/spring-engine- > schema- > > core-daos-context.xml > > 08efb83 > > > engine/schema/src/com/cloud/gpu/HostGpuGroupsVO.java PRE- > CREATION > > > engine/schema/src/com/cloud/gpu/VGPUTypesVO.java PRE-CREATION > > > engine/schema/src/com/cloud/gpu/dao/HostGpuGroupsDao.java PRE- > CREATION > > > engine/schema/src/com/cloud/gpu/dao/HostGpuGroupsDaoImpl.java > > PRE-CREATION > > > engine/schema/src/com/cloud/gpu/dao/VGPUTypesDao.java PRE- > CREATION > > > engine/schema/src/com/cloud/gpu/dao/VGPUTypesDaoImpl.java PRE- > CREATION > > > engine/schema/src/com/cloud/host/HostVO.java 56c066b > > > engine/schema/src/com/cloud/host/dao/HostDaoImpl.java 08a4366 > > > engine/schema/src/com/cloud/service/ServiceOfferingDetailsVO.java > > e1a1e93 > > > > > plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixRe > > sourceBase.java > > 48ae3ea > > > > > server/src/com/cloud/agent/manager/allocator/impl/FirstFitAllocator.ja > > va > > b77f8ac > > > server/src/com/cloud/api/ApiDBUtils.java a23244b > > > server/src/com/cloud/api/query/dao/HostJoinDaoImpl.java 1b95d9b > > > server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java 08478e2 > > > server/src/com/cloud/configuration/ConfigurationManagerImpl.java > > 1c1da1f > > > server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java > 3c87b24 > > > server/src/com/cloud/hypervisor/HypervisorGuruBase.java 7fb79fa > > > server/src/com/cloud/network/NetworkUsageManagerImpl.java > e9b0393 > > > server/src/com/cloud/resource/ResourceManagerImpl.java adad85c > > > server/src/com/cloud/server/ManagementServerImpl.java 2a08ddc > > > server/src/com/cloud/server/StatsCollector.java 548587c > > > server/src/com/cloud/storage/VolumeApiServiceImpl.java c95d316 > > > server/src/com/cloud/vm/UserVmManagerImpl.java 97e3ae7 > > > server/test/com/cloud/resource/MockResourceManagerImpl.java > 5599e8c > > > server/test/com/cloud/vm/DeploymentPlanningManagerImplTest.java > 751a3bd > > > server/test/resources/createNetworkOffering.xml c6228da > > > setup/db/db/schema-430to440.sql 0ded7a9 > > > test/integration/smoke/test_deploy_vgpu_enabled_vm.py PRE- > CREATION > > > tools/marvin/marvin/integration/lib/base.py 0a7ad94 > > > ui/scripts/configuration.js 869b876 > > > ui/scripts/instances.js 53c9e98 > > > > > > Diff: https://reviews.apache.org/r/17889/diff/ > > > > > > > > > Testing > > > ------- > > > > > > Tests: > > > > > > Hosts: > > > 1) Add a XS hosts with GPU cards. > > > 2) Create a pool of XS hosts with GPU cards. > > > 3) Create a pool of XS hosts which are GPU enabled as well which are > > > not > > enabled. > > > 4) Checke the values in both the tables and verify the no. of GPU > > > cards, > > remaining capacity etc. > > > 5) Remove a host from a pool and the remaining capacity should get > > updated properly. > > > > > > VM: > > > 1) Create a compute offering with GPU/vGPU capability. > > > 2) Deploy HVM OS with this service offering. > > > 3) In case of successful start of VM, remaining capacity should get > > updated correspondingly. > > > 4) Stop the VM and verify the capacity. > > > 5) Destroy the VM and verify the capacity. > > > 6) If the hosts does not have capacity to deploy a gpu enabled VM, > > > then > > CS throws the InsufficientServerCapacity exception with proper error > > message in the logs. > > > > > > > > > Thanks, > > > > > > Sanjay Tripathi > > > > > > > > > >
