PVS Windows boots slow 'getting devices ready'

[Ben Tusa]

Environment:

 

VMware 6.7

PVS 1909

AL 1911

Windows 10 1903

 

I publish an image to PVS, when I boot it up Win10 sits on 'getting devices ready' for about 5 mins. If I boot the image once in private mode then switch back to standard mode everything seems fine after that, boots up in under 1 min. Is that something you have to do with PVS each time you export/update your image? Or am I missing some step in my PVS platform layer?

[Kyle Loos]

Did anyone in this chain find a solid answer on this? We are seeing similar behavior with our Server 2016 images created using app layering. They always sat at the 'Getting devices ready" screen for a few minutes but it has gotten longer and now some will simply reboot and get stuck in a loop. I have been setting the image to private mode to let the process finish and write to the image but this adds extra time. 

 

I have tried a few different versions of app layering with the same results. Currently using the latest: 21.07. 

[Markus Lundberg1709157352]

13 hours ago, Ben Tusa said:

Environment:

 

VMware 6.7

PVS 1909

AL 1911

Windows 10 1903

 

I publish an image to PVS, when I boot it up Win10 sits on 'getting devices ready' for about 5 mins. If I boot the image once in private mode then switch back to standard mode everything seems fine after that, boots up in under 1 min. Is that something you have to do with PVS each time you export/update your image? Or am I missing some step in my PVS platform layer?

Hi,

 

have you seen this one?

https://support.citrix.com/article/CTX233881

 

[Ben Tusa]

3 hours ago, Markus Lundberg1709157352 said:

Hi,

 

have you seen this one?

https://support.citrix.com/article/CTX233881

 

 

Not sure this applies to me since I can resolve the issue by simply booting the image once in private mode then reseal and change back to standard mode.

[Markus Lundberg1709157352]

17 hours ago, Ben Tusa said:

 

Not sure this applies to me since I can resolve the issue by simply booting the image once in private mode then reseal and change back to standard mode.

It´s usually expected behaivour when you booting the image for the first time after an upgrade, is it faster when you reboot the VDA? 

[Ben Tusa]

7 hours ago, Markus Lundberg1709157352 said:

It´s usually expected behaivour when you booting the image for the first time after an upgrade, is it faster when you reboot the VDA? 

 

That's what I'm trying to understand.  I'm coming from doing everything in PVS to now adding AL to create my PVS images....  When I first publish the AL image to PVS in standard mode, I could reboot it 100 times but each time it takes 5+ mins and sits on the 'getting devices ready' screen because the image is read only so when you reboot  it everything has to occur again.  So like all things PVS if I switch it to private mode (write), let the changes Windows is making take effect in the image, then switch back to standard/read only mode the issue is gone.

 

So my question is, am I missing something in my AL Platform Layer or is this expected behavior to have to switch any published image to private mode and boot it that way once.

[Stephen Borrill]

On 1/16/2020 at 3:55 PM, Ben Tusa said:

 

That's what I'm trying to understand.  I'm coming from doing everything in PVS to now adding AL to create my PVS images....  When I first publish the AL image to PVS in standard mode, I could reboot it 100 times but each time it takes 5+ mins and sits on the 'getting devices ready' screen because the image is read only so when you reboot  it everything has to occur again.  So like all things PVS if I switch it to private mode (write), let the changes Windows is making take effect in the image, then switch back to standard/read only mode the issue is gone.

 

So my question is, am I missing something in my AL Platform Layer or is this expected behavior to have to switch any published image to private mode and boot it that way once.

 

It's a known issue (I hesitate to say expected) due to the large amount of scrubbing that ELM does when publishing an image. Basically it is having to rediscover all devices as, even though they are known about in the registry, they are marked as inactive. It's even more pronounced on a physical PC; you see the display driver kick in, then the USB drivers for the keyboard/mouse, then audio, etc. However, as you say, even on a VM it's bad (especially if using a GPU) and places a high load on the hypervisor. We've spent a lot of time looking at it and are slowly homing in on what needs altering in the registry to stop it happening, which we hope to either automate using a PVS post-publishing script or, better yet, convince Citrix to fix it. We have a support case open with them about it too.

[Ben Tusa]

4 hours ago, Stephen Borrill said:

 

It's a known issue (I hesitate to say expected) due to the large amount of scrubbing that ELM does when publishing an image. Basically it is having to rediscover all devices as, even though they are known about in the registry, they are marked as inactive. It's even more pronounced on a physical PC; you see the display driver kick in, then the USB drivers for the keyboard/mouse, then audio, etc. However, as you say, even on a VM it's bad (especially if using a GPU) and places a high load on the hypervisor. We've spent a lot of time looking at it and are slowly homing in on what needs altering in the registry to stop it happening, which we hope to either automate using a PVS post-publishing script or, better yet, convince Citrix to fix it. We have a support case open with them about it too.

 

Thanks for the info, makes sense.  I have found since that after creating new platform layer I haven't seen the issue happen again.  At least the 'getting devices ready' screen stays on for a much shorter time now.

[Tyson Glaser]

On 1/31/2020 at 4:00 AM, Stephen Borrill said:

 

It's a known issue (I hesitate to say expected) due to the large amount of scrubbing that ELM does when publishing an image. Basically it is having to rediscover all devices as, even though they are known about in the registry, they are marked as inactive. It's even more pronounced on a physical PC; you see the display driver kick in, then the USB drivers for the keyboard/mouse, then audio, etc. However, as you say, even on a VM it's bad (especially if using a GPU) and places a high load on the hypervisor. We've spent a lot of time looking at it and are slowly homing in on what needs altering in the registry to stop it happening, which we hope to either automate using a PVS post-publishing script or, better yet, convince Citrix to fix it. We have a support case open with them about it too.

Any updates on this? I have a case in with Citrix for this exact thing. Initial layer we export from App Layering will take anywhere between 20-40 minutes depending on the different layers we use... open it up once and it takes less than 5 minutes. They initially said it's a storage/network issue...which makes zero sense considering network/storage doesn't change and we can get a <5 minute boot by simply opening the image. Last reply was, "Oh this must be a microsoft issue, you will need to send them a dump".... uggghhh.