10.6. Microsoft Hyper-V and RDS Desktop Providers

10.6.1. Sessions Are Started by Oracle VDI on RDS Hosts That Do Not Participate in the Microsoft Remote Desktop Provider. Why Is That Happening?
10.6.2. Hyper-V Desktop Cloning Fails With "Cannot Reload MSiSCSI Target List" Errors
10.6.3. Can I Enter the Farm Information for the Microsoft Remote Desktop Provider and let Oracle VDI Detect the Individual RDS Hosts Participating in the Farm?
10.6.4. Oracle VDI Is Not Able to Communicate With the Windows Server
10.6.5. Connection Problems between Oracle VDI and Hyper-V

10.6.1. Sessions Are Started by Oracle VDI on RDS Hosts That Do Not Participate in the Microsoft Remote Desktop Provider. Why Is That Happening?

This will happen if you add to the provider some of the RDS hosts that participate in a farm, but not all of them. In case of RDS hosts participating in a farm, Oracle VDI detects the farm name which is returned to the Remote Client when a user tries to get a new session. Therefore, the session may be started on any RDS host participating in the farm, even on those that Oracle VDI does not know about.

This is why it is strongly recommended to add all RDS hosts of the farm to the Microsoft Remote Desktop provider. See Section 4.2.5, “Microsoft RDS Farm (NLB Cluster) Management” for details.

10.6.2. Hyper-V Desktop Cloning Fails With "Cannot Reload MSiSCSI Target List" Errors

The desktop cloning process relies on the iscsicli command-line interface on the Hyper-V server in order to assign a disk to the new clone. The iscsicli command may sometimes hang on the Hyper-V server, which in turn will cause the cloning process to fail with the error "Cannot reload MSiSCSI target list".

Oracle VDI supports a number of settings which allow an administrator to configure how Oracle VDI runs the iscsicli command on the Hyper-V server. The properties can be modified using the vda command-line interface. The settings that can be modified are as follows:

msiscsi.timeout - The amount of time that Oracle VDI should wait for MSiSCSI operations to complete on a Windows server.

msiscsi.retries - The number of times Oracle VDI retry loading the iSCSI target list on a Windows server before returning an error.

msiscsi.retry.interval - The amount of time that Oracle VDI should wait between iSCSI load retries.

To see the current values for the settings use the command:

# /opt/SUNWvda/sbin/vda settings-getprops \
--property=msiscsi.timeout,msiscsi.retries,msiscsi.retry.interval

To set new values for the settings use a command like the following:

# /opt/SUNWvda/sbin/vda settings-setprops \
--property=msiscsi.timeout=30,msiscsi.retries=10,msiscsi.retry.interval=15

In particular, increasing the value of the msiscsi.retry.interval property has been observed to reduce the number of cloning failures due to iscsicli failure.

10.6.3. Can I Enter the Farm Information for the Microsoft Remote Desktop Provider and let Oracle VDI Detect the Individual RDS Hosts Participating in the Farm?

No, it is not possible to do so. If you want Oracle VDI to collect information about the sessions and allow some control over them, you need to provide the administrator credentials of each individual RDS host participating in the farm so that Oracle VDI is able to query these hosts about the sessions.

Alternatively, you may choose to only specify the Remote Desktop Server Farm, in which case no session and load information is available in Oracle VDI.

See Section 4.2.5, “Microsoft RDS Farm (NLB Cluster) Management” for details.

10.6.4. Oracle VDI Is Not Able to Communicate With the Windows Server

Test that WinRM can communicate using HTTP between two Windows servers.

To configure WinRM to listen for HTTP requests run "winrm qc" on your windows platform.

On another windows machine execute the command below where IP is the IP address or host name of the Windows server you want to test and USER is the local administrator on the Windows server you want to test.

C:\Documents and Settings\Administrator>winrm id -r:IP -u:USER
IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 5.2.3790 SP: 2.0 Stack: 1.1

If you get an error executing this command then WinRM has not been setup correctly on the Windows server.

10.6.5. Connection Problems between Oracle VDI and Hyper-V

By default, Windows Server 2008 R2 installs with the Windows Remote Management (WinRM) limited to 15 concurrent operations per user. To check the number of concurrent operations per user, run the following command on the Windows host:

> winrm get winrm/config 
... 
Service 
MaxConcurrentOperationsPerUser = 15 
... 

For some Oracle VDI deployments, this limit is too low and can cause communication problems between Oracle VDI and Hyper-V. When there are communication problems, the cacao logs typically contain the following error message:

SOAP Fault: The WS-Management service cannot process the request. The maximum  
number of concurrent operations for this user has been exceeded. Close existing  
operations for this user, or raise the quota for this user. 
     Actor: 
      Code: s:Receiver 
  Subcodes: w:InternalError 
    Detail: The WS-Management service cannot process the request. This user is  
allowed a maximum number of 15 concurrent operations, which has been exceeded.  
Close existing operations for this user, or raise the quota for this user. 

If you see this error message, the solution is to increase the MaxConcurrentOperationsPerUser property to a value that is appropriate for your Oracle VDI deployment. To change the property, run the following command on the Hyper-V host:

> winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="num"}

For example:

> winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="200"}