Hyper-V Adds support for RemoteFX

Registered by Alessandro Pilotti

OpenStack VDI support on Hyper-V can greatly benefit from enabling RemoteFX
in the Nova driver.

RemoteFX allows a guest VM to access the hypervisor's GPU features for 3D
graphical acceleration.

Guest configuration is performed by specifying the number of virtual desktops
to be used by the VM and the maximum resolution, with a given set of predefined


The hypervisor available resources include the total video memory provided by
the combined video adapters configured for RemoteFX.

The RemoteFX resources are provided by the hypervisor and need to be handled
in a way similar to other compute resources. In particular:

* The Nova Hyper-V driver needs to report the amount of available RemoteFX
  video memory as part of the host capabilities
* The Nova Hyper-V driver needs to evaluate video memory requirements specified
  in the flavor extra specs when spawning images
* The Nova scheduler needs a filter to allocate instances based on video memory
  flavor requirements. The filter needs also to be taken into account for live
  migration / cold migration / resize operations.

Example flavor with RemoteFx support:

    nova flavor-key remotefx1 set "hyperv:remotefx=1280x1024,2"

The amount of video memory consumed by an instance based on a given resolution
and monitor count can be calculated as:

video_memory = 64*horizontal_res*vertical_res*monitor_count
e.g.: 64*1280*1024*2 = 167772160 bytes

During the configuration of Hyper-V instances, RemoteFX resources can be
assigned by using the Msvm_Synthetic3DDisplayControllerSettingData WMI class.

On each compute host, the "Remote Desktop Services Virtualization Host" (RDVH)
role must be enabled on the host and one or more physical GPUs with RemoteFX
support need to be available.

RDVH can be enabled with:

    Add-WindowsFeature –Name RDS-Virtualization

Blueprint information

John Garbutt
Alessandro Pilotti
Alessandro Pilotti
Series goal:
Accepted for newton
Milestone target:
milestone icon newton-2
Started by
John Garbutt
Completed by
Alessandro Pilotti

Related branches



Any instances which enable this feature consume host/network resources, and so IMHO there needs to be a way for administrators to control this usage. I think that instance flavours are probably a reasonable place to put some kind of controls. eg an image is only allowed to use this feature if the associated flavour has it marked as allowed. That way the admin in charge of defining flavours & giving users access to flavours can control who can utilize the limited resources.

Thanks for the update, I'm following up to your objections in the -dev ML.

Unapproved - please re-submit via nova-spec --johnthetubagy (20th March 2014)

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Given the new rules for kilo, we can approve this spec, mostly because the approach has been previously agreed at the summit. --johnthetubaguy (8th October 2014)

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

OK, so we can approve this for liberty now. --johnthetubaguy 17th April 2015

Gerrit topic: https://review.openstack.org/#q,topic:bp/hyper-v-remotefx,n,z

Addressed by: https://review.openstack.org/42529
    Adds RemoteFX support to the Hyper-V driver

Addressed by: https://review.openstack.org/188734
    Adds hostutilsv2 to HyperV

Sorry, we have now hit the non-priority feature freeze for Liberty. You will need to resubmit this blueprint for Mitaka or apply for an exception. For more details on why this is happening, and the rest of the process details, please see: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
--johnthetubaugy 4th August 2015

Pending Patches

Addressed by: https://review.openstack.org/42529
    Adds RemoteFX support to the Hyper-V driver


Work Items

This blueprint contains Public information 
Everyone can see this information.