VMWare driver – Support for Video Memory

Registered by Sagar Ratnakara Nikam

This blueprint introduces support for video memory in Nova VMWare driver

Problem Description
==========================================
The nova VMWare driver in Juno does not allow an instance to have a specific video memory, which means the default video memory (4 MB) is set by VMWare vCenter. Also the nova VMWare driver does not allow setting number of displays and enabling 3D support for the instances
The ability to set the video memory, number of displays and 3D support is important for instances especially in VDI use case, where instances might need high graphic capabilities.
VMWare vCenter allows setting of Video Memory of the VM. The video memory allocation is evenly divided - Half the video memory is reserved on the hardware GPU, while the other half is reserved via host RAM. A maximum of 512 MB video can be assigned to a VM, which means a max of 256 MB is on hardware GPU for a VM. If a VM has video memory assigned and all the hardware GPU is already reserved for other VMs, then software 3D rendering will be used, which means all of the instance’s video memory will be on host RAM. By default the vCenter sets the graphics rendering to “Automatic”, which means if hardware GPU is not available, video memory is set on host RAM and software 3D rendering will be used

Proposed Change
==========================================
The proposed change can be classified as follows
• During spawn of instance, check if video memory and number of displays is set in
        flavor extra spec and 3D support is set in image property. If yes, add video
        memory, number of displays and 3D support to the instance

• Allow resize of video memory and number of displays if the new flavor used has
        the flavor extra spec for video memory and number of displays set

• The video memory can be set in a flavor using the flavor extra_specs key
        hw_video:video_ram and using VISDK object VirtualMachineVideoCard

• The number of displays can be set in flavor using the flavor extra_specs key
        hw_video:video_display

• Enabling of 3D support will be done using the image property
        “enable3dsupport=True”. Image property is used since 3D is dependent on images
        (like Windows 8 etc) and is not flavor dependent

Blueprint information

Status:
Started
Approver:
John Garbutt
Priority:
Low
Drafter:
Sagar Ratnakara Nikam
Direction:
Needs approval
Assignee:
Sagar Ratnakara Nikam
Definition:
Pending Approval
Series goal:
None
Implementation:
Needs Code Review
Milestone target:
milestone icon next
Started by
Sagar Ratnakara Nikam

Related branches

Sprints

Whiteboard

Sagar, as mentioned on IRC, I recommend to split this blueprint into two blueprints. The first would be the changes made to support the settings in the virt layer and the flavor/image. The second would be any changes to the scheduler that would utilize the changes from the first blueprint.

-jay

A similar feature for supporting video memory for instances in libvirt is already available and was implemented as part of the following BP
https://blueprints.launchpad.net/nova/+spec/libvirt-video-driver-selection
specifically this patch
https://review.openstack.org/#/c/63472/

The BP "vmware-driver-support-for-video-memory" is for achieving feature parity for VMWare driver
-Sagar

Jay, Added a new BP for scheduler changes
https://blueprints.launchpad.net/nova/+spec/vmware-video-memory-filter-scheduler
- Sagar

Seems to be nicely copying the pattern of the libvirt feature, so lets approve this as a driver consistency kind of thing. --johnthetubaguy 17th October 2014

Gerrit topic: https://review.openstack.org/#q,topic:bp/vmware-driver-support-for-video-memory,n,z

Addressed by: https://review.openstack.org/130988
    VMWare - Support for video memory to instances

Addressed by: https://review.openstack.org/128931
    VMware: refactor cpu allocations

Addressed by: https://review.openstack.org/134750
    VMware - Support for video memory resize

Moving to kilo-2, as its not been moved into the NeedsCodeReview state, it is assumed that not all patches are yet up for review. --johnthetubaguy 16th December 2014

Sorry, we have now hit the non-priority feature freeze for kilo. Please resubmit your spec for the L release. --johnthetubaguy 5th Feb 2015

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.