locked
Curious about App-V 4.6 RO Cache Network Traffic RRS feed

  • Question

  • Our environment is Server 4.5 SP2, and Client 4.6 SP3. We utilize RO cache on DFS network storage, and our clients are VDI VM's.

    We recently ran into an issue when we recycled a large pool of VM's where the CPU/Network Utilization was maxed on our cache file server. Upon further investigation there appears to be about 550MB of traffic between each VM and the Cache file itself when the VM boots (no users logged in). Can someone explain to me what this traffic could be?

    Monday, February 24, 2014 5:39 PM

Answers

  • In RO cache mode (ReadOnlyFSD], *nothing* should get streamed down to the client at all.

    where does the amount of data show up - any specific files/folders, or monitored network traffic between the client and the DFS share?

    is there anything in the App-V log file?

    Did you initiate a server publishing refresh with a user that has access to all applications before you sealed the VDI Master image?


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Wednesday, February 26, 2014 6:36 AM
    Moderator

All replies

  • Some further info/issues as well...

    On an image with 4.6 SP1, this download of data is happening, but the ability to login to Windows is quick...

    On an image with 4.6 SP3 (and 5.0 sp2, not configured), this same download of data is happening - but the ability to login to windows is being delayed greatly.

    I can't find much from the release notes about any of this. Anybody know whats going on?

    Monday, February 24, 2014 7:24 PM
  • Hello,

    Is the RO-cache configuration still set after the upgrade?


    Nicke Källén | The Knack| Twitter: @Znackattack

    Monday, February 24, 2014 9:17 PM
  • Yes it is still acting in RO mode. Like I said the download of data happens in both SP1 and SP3, but the windows login process is being held up in SP3 until the download is complete - and when we are recycling 1000+ VM's at one time this can cause delays.
    Tuesday, February 25, 2014 3:29 PM
  • What happens if you use SP2?

    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, February 25, 2014 7:56 PM
  • Have not tried that yet.

    SP3 is required for coexistence with App-V 5.

    Tuesday, February 25, 2014 10:59 PM
  • Hello,

    Actually, SP2 is required. SP3 came for 8.1 support


    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, February 25, 2014 11:23 PM
  • In RO cache mode (ReadOnlyFSD], *nothing* should get streamed down to the client at all.

    where does the amount of data show up - any specific files/folders, or monitored network traffic between the client and the DFS share?

    is there anything in the App-V log file?

    Did you initiate a server publishing refresh with a user that has access to all applications before you sealed the VDI Master image?


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Wednesday, February 26, 2014 6:36 AM
    Moderator
  • We are still seeing this. No issues in the App-V client log. No errors anywhere - just odd behavior.

    I don't believe this has anything to do with SP level at this point.

    We have captured traffic between a newly booted VDI VM and the cache file server and it ranges anywhere from a couple hundred MB to the full cache size (nearly 200GB in our environment). In some cases the VDI VM will not enter a ready state (available to users) until the entire amount of data was read by the client (so says the capture). The end result of the machine once booted has no indications of that data then residing on the machine.

    Imagine this behavior times thousands of VDI VM's, and our file server hammered at 100% CPU for hours on end while these machines try to access the cache and become ready. Has been a nightmare anytime large amounts of VM's are recycled.

    And again this happens at machine startup before a user has logged in.

    Any bright ideas?

    Tuesday, May 19, 2015 5:26 PM