VMware Horizon Community
Makian
Enthusiast
Enthusiast

Pool creation & deletion. Some minor bugs in View v5.1 ?

Hi Everyone,

We have recently updated our View v5.0 system to View v5.1 by closely following the instructions in the published upgrade guide.

Our VDI system seems to be working OK in general since this upgrade. However, we have encountered the following new issues. Just wondering if anyone else has experienced the same and/or may have any advice please ?.

  • The view composer log file contains multiple instances of the following error when the cloning the master replica to create a pool (but clone & pool creation still works).

2012-06-26 17:42:10,000 | 31            | INFO  | CommonLib.Util.Util - Will retry after 0 seconds. The retry number is 1.

2012-06-26 17:42:10,000 | VC thread     | INFO  | CommonLib.VcSubsystem.PropertyCollectorUpdateTracker - Got SimVcSubsystemException      RequestCanceledFault fault was thrown by the VC server: https://na-vdi-vcenter.stud.ad.eiu.edu.au:443/sdk..

  • When creating a pool with “Host Caching” enabled the system waits for 30mins at a “configure virtual disk digest” task within vCenter. During this period multiple instances of the following error appears in the View Composer logs (but pool creation eventually still works)

2012-06-26 17:54:22,971 | 30            | INFO  | CommonLib.Util.Util - Will retry after 0 seconds. The retry number is 1.

2012-06-26 17:54:22,971 | VC thread     | INFO  | CommonLib.VcSubsystem.PropertyCollectorUpdateTracker - Got SimVcSubsystemException RequestCanceledFault fault was thrown by the VC server: https://na-vdi-vcenter.stud.ad.eiu.edu.au:443/sdk..

  • When deleting a pool with “Host Caching” enabled the vcenter reportsthe VM replica has been deleted from the datastore. However, if you browse the datastore it’s actually still there and needs to be deleted manually.

  • According the the VMWare View Admin Guide if you enable “host caching” on an existing pool the VMs within that pool should activate this feature after they next reboot. This is not happening in our environment; we can only get “host caching” activated for VMs if the pool is created with this option ON when it’s created.

Perhaps these are just some new bugs included in View v5.1 ?. Not a big deal so we are just working around them for now but it would be excellent to be able to fix these up.

Thanks

Reply
0 Kudos
7 Replies
Brandon_Sarrade
Contributor
Contributor

I am also experiencing similar issues. Composing pools seems to hang at the "Configure virtual disk digest" step for around 3 - 5 minutes with Host Caching enabled.

iforbes
Hot Shot
Hot Shot

I'm getting the exact same thing when I enable the digest during pool creation - just sits at 'In Progress' forever. Did you resolve?

Thanks

Reply
0 Kudos
Makian
Enthusiast
Enthusiast

Hello,

No, unfortunately this delay problem was never resolved so we have just been living with this 30min delay when creating a new pool. We did place a service call with VMWare but they were unable to replicate the problem on their own test systems and in the end they were unable to assist.

We are hoping this issue will be "magically" fixed by the next View 5.2 update when it's installed.

Reply
0 Kudos
rgayton
Contributor
Contributor

Add me to the list.  Nothing like waiting for crud like this at 2:00 am.  Looks like I'll add this to my open tickets with vmware.

Reply
0 Kudos
Dave_McD
Contributor
Contributor

It has been my experience over many upgrades that what you should do is not upgrade. Build a fresh environment, it is cleaner.

I have 5.1 freshly built and creating a new pool with host caching is really quick, mainly because I have the replicas and OS on SSD.

Reply
0 Kudos
jslabaugh
Enthusiast
Enthusiast

We are also having the host caching issues you described.

Reply
0 Kudos
AnthBro
Enthusiast
Enthusiast

Correct this happens when host cache is enabled.

Details about host cachine is here http://communities.vmware.com/docs/DOC-19439

If you are constantly changing settings and working on the pool you may want to set a block out period, that way if it works the way I believe it does the digest should recompute during  the blackout periods.  Let me know how you go.

Blackout times

This defines recurring schedule for which the cache regeneration should  not be performed. This option allows the administrator to plan the  'digest recompute' to run only during non-business hours, off-peak  schedule etc. Refer figure 4. Here the cache regeneration is not  performed during 9 AM to 6 PM on all week days

20143_20143.pngFIG1.png

Any views or opinions presented in this post are solely those of the author and do not necessarily represent those of the company he works for.
Reply
0 Kudos