Provisioning services no servers available for disks in maintenance mode

[Nick Krone]

Receiving "provisioning services no servers available for disk" when trying to boot into two maintenance versions of 2 vDisks we have. This is from a target device in VMware.

 

Issue just started to happen. We have PVS 7, XenDesktop 7 set up. All VDIs work just fine and you can boot up to the production vDisks without issue.

 

PVS servers and the hypervisor (vCenter) has been rebooted. These are Windows 7 vDisks that are a new version in maintenance mode.

 

I created a new version in maintenance mode for one of the XenApp 6.5 vDisks we have - and see the same issue.

 

Maintenance mode vDisks are showing as having no vDisk active. Booting to the production vDisks from the same target device shows the vDisk as active.

 

Any ideas/thoughts on why this is happening?

[William Walker1709152505]

I found a workaround for this issue.  Go to the disk in the PVS console and right click and choose "Replication Status" once that opens just close it and restart your vm that is booting the new vhd and it will not give you the error anymore.

[Peter Van Esser1709152818]

Is there any update on this? We have the same problem but with Hyper-V hypervisor?

It worked fine till a few day's ago, now it seems to look for the disk on the wrong PVS server.

[Carl Fallis]

Since this is PVS 7 (I hope 7.1) try setting HKLM\Software\Citrix\ProvisioningServices\SkipRimsForPrivate to 1 (Dword) in the registry

 

With PVS 7.0 and higher the streamprocess checks with inventory only in the case when streaming private mode (or maintenance basically the same).  But the inventory is not real time and does not always have the correct information at the time you need it.  This is why the streamprocess does not use it for standard mode any more.  This key tells the streamprocess to bypass all interaction with inventory and default back to algorithms used in 6.0. 

[Carl Fallis]

Another way to make sure the inventory service is up to date is to run the following command:

 

mcli run ForceInventory

 

This will force the inventory process to update all the servers in the farm. 

[Jonathan Block]

Carl,

 

Dumb question - where do we run that ForceInventory command at?

 

Thanks,

 

JB

[Jonathan Block]

Carl - disregard my last post.  Found it.  Thanks!

[Hilaire Campo]

Thanks the replication did the trick  

[Joseph Esposito]

vDisk replication did not work in my case, however creating "HKLM\Software\Citrix\ProvisioningServices\SkipRimsForPrivate to 1 (Dword)" did the trick.

[Brian Welchel1709154669]

Since this is PVS 7 (I hope 7.1) try setting HKLM\Software\Citrix\ProvisioningServices\SkipRimsForPrivate to 1 (Dword) in the registry

 

With PVS 7.0 and higher the streamprocess checks with inventory only in the case when streaming private mode (or maintenance basically the same).  But the inventory is not real time and does not always have the correct information at the time you need it.  This is why the streamprocess does not use it for standard mode any more.  This key tells the streamprocess to bypass all interaction with inventory and default back to algorithms used in 6.0. 

Slight correction, this needs to go under HKLM\Software\Citrix\ProvisioningServices\StreamProcess\  <reg DWORD>SkipRimsForPrivate=1

 

http://support.citrix.com/article/CTX200233.

 

Be sure to bounce the Stream service.

[Jonathan Block]

Quick question - in the registry on my PVS servers, I have a "SkipRIMS" entry under:

 

HKLM\Software\Citrix\ProvisioningServices\StreamProcess\

 

Do I need to delete that entry after I add the "SkipRIMSForPrivate" entry?

[Carl Fallis]

If you are using PVS 7.X you must add the "SkipRIMSForPrivate"  key. 

[Jonathan Block]

Thanks for the quick reply Carl. 

 

To clarify, I got the key added.  What I was trying to figure out was whether or not the "SkipRIMS" key needed to be deleted as well. 

[Brian Welchel1709154669]

Thanks for the quick reply Carl. 

 

To clarify, I got the key added.  What I was trying to figure out was whether or not the "SkipRIMS" key needed to be deleted as well. 

No, just add the new key.  You should leave the existing SkipRIMS key.

[Paul Mathews]

On 6/13/2014 at 3:16 PM, William Walker1709152505 said:

I found a workaround for this issue.  Go to the disk in the PVS console and right click and choose "Replication Status" once that opens just close it and restart your vm that is booting the new vhd and it will not give you the error anymore.

 

this worked for me, thanks!

[Andrew Menzies]

On 6/13/2014 at 10:16 AM, William Walker1709152505 said:

I found a workaround for this issue.  Go to the disk in the PVS console and right click and choose "Replication Status" once that opens just close it and restart your vm that is booting the new vhd and it will not give you the error anymore.

 

Recently had this happen when I made a copy of a vDisk and imported the copy as a new separate vDisk. This "replication status" workaround worked for me. Thanks!