> On Feb. 28, 2014, 10:06 a.m., Koushik Das wrote: > > core/src/com/cloud/agent/api/StopCommand.java, line 27 > > <https://reviews.apache.org/r/17889/diff/3/?file=505671#file505671line27> > > > > Shouldn't there be a similar change in StartCommand as well?
For VM deployment, the GPU details are getting passed through VirtualMachineTO, so no need to add anything in StartCommand. > On Feb. 28, 2014, 10:06 a.m., Koushik Das wrote: > > engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java, line > > 1019 > > <https://reviews.apache.org/r/17889/diff/3/?file=505673#file505673line1019> > > > > What happens if there is an exception while updating GPU capacity? Will > > the startVM fail and the vm cleaned up? StartVM will not fail in case of exception while updating GPU capacity. Capacity update is a separate task and MS should not fail the startVM in case of update failure. Also, to update GPU capacity, there is a separate thread runs per minute to update the capacity count. > On Feb. 28, 2014, 10:06 a.m., Koushik Das wrote: > > core/src/com/cloud/agent/api/StartupRoutingCommand.java, line 253 > > <https://reviews.apache.org/r/17889/diff/3/?file=505670#file505670line253> > > > > This is not required, use getGpuGroupDetails() instead When MS adds the host first time, this setGpuGroupDetails method fills the hostInfo with GPU group details; this setter method use the getGpuGroupDetails internally to get the GPU details. So, in back we have the getGpuGroupDetails method but I think we need some setter method to set this GPU details in startupRoutingCommand. > On Feb. 28, 2014, 10:06 a.m., Koushik Das wrote: > > engine/components-api/src/com/cloud/resource/ResourceManager.java, line 158 > > <https://reviews.apache.org/r/17889/diff/3/?file=505672#file505672line158> > > > > getGPUDevice() and listAvailableGPUDevice() - The name says GPUDevice > > but one return a single GPUDeviceTO and another returns a list of > > HostGpuGroupsVO. Can we have better names if these are indeed different > > things? > > > > Also instead of GPUDeviceTO, should it be a VO? The method like getGPUDevice(), isGPUDeviceAvailable() are using listAvailableGPUDevice method to get the GPU related info. Here, getGPUDevice is returing GPUDeviceTO which is getting passed to VirtualMachineTO. If you think the method names are not as per there task, i'll think of some better name and change it later. - Sanjay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17889/#review35770 ----------------------------------------------------------- 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/CreateServiceOfferingCmd.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/CitrixResourceBase.java > 48ae3ea > server/src/com/cloud/agent/manager/allocator/impl/FirstFitAllocator.java > 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 > >
