VMware Horizon Community
gao2
Contributor
Contributor

Not All Desktops Recompose

I'm having a problem when I recompose an entire pool. It doesn't matter whether I selected View Composer > Recompose from the "Settings" tab of the pool or go into its inventory, select all, and Right-Click > Recompose.

It happens consistently, every time. I usually have to go back 2-3 times to each pool to make sure I get all desktops on the right snapshot.

Does anyone know what's going on or where I could find more information?

VMware View 5.1.0 build-704644

Reply
0 Kudos
9 Replies
oturn
Enthusiast
Enthusiast

Exact same issue here. Anyone?

Reply
0 Kudos
vedeht
Hot Shot
Hot Shot

When you do this are you forcing the users to log out?  What is the task status when looking at the pool inventory Desktops (View Composer Details) of the desktop?  Does it say "recompose"?

If so how long have you waited for this to complete?  It will only recompose as many desktops at once as the setting specified in the vCenter settings specified in View.

Try our VMWare View Demo on www.virtualdojo.com
Reply
0 Kudos
gmtx
Hot Shot
Hot Shot

Ditto, and just last night I had a recompose of a pool with 50 floating linked clones scheduled for after hours, and checked about two hours after it was supposed to have run. Only one VM actually recomposed, and none of the others had any tasks pending. The recompose was set to stop on first error, but there were no error events shown and the VM that did recompose was fine.

That's the worst I've ever seen it. Usually I'll get a handful that won't recompose and I have to do them manually. I figured it was just a bug that would be fixed in an upcoming release, and for the few that failed I just did them manually and didn't worry too much about it, but after last night it looks like scheduled recompose jobs where I'm not there to watch are off the list.

Geoff

Reply
0 Kudos
vedeht
Hot Shot
Hot Shot

Looks like it is mentioned in the Known Issues section on View 5.1.0 release notes.

Under rare circumstances, it was possible that View Composer could enter a repeated polling loop during a recompose operation, which could result in an unusually long completion time.

Refrence Link: https://www.vmware.com/support/view51/doc/view-51-release-notes.html#knownissues

Try our VMWare View Demo on www.virtualdojo.com
Reply
0 Kudos
oturn
Enthusiast
Enthusiast

We don't force the users to log out. The task displayed in the inventory is recompose. In our case, the pool we're dealing with is smaller than the maximums set in the vCenter Server settings. We typically set a recompose for 4am. By 8am it's either done, or waiting on a few users to log off. By this time, several of the desktops have been skipped already.

When a desktop is skipped, the recompose status will just change to a normal status of available, provisioned, etc., and the recompose task will increment down a number. This happens after no tasks have run on the skipped desktop. Just recently, I was actually watching the console the moment this happened. It was mildly amusing... Again, a few desktops recomposed normally.

I don't believe the long completion time is the bug. The recompose isn't taking too long, it's just completely bypassing workstations.

Reply
0 Kudos
gmtx
Hot Shot
Hot Shot

That's exactly the same behavior I'm seeing as well. Nothing waiting*, no errors, but the the recompose has skipped VMs.

*What I do normally see is that any VMs that were connected are showing the recompose pending. It's only skipping (some) idle VMs.

Geoff

Reply
0 Kudos
riki78
Contributor
Contributor

Hello

Same problem here.... We have this issue since view 4.0.

Does anyone have a solution for this problem? or opened a case?

Best regards

Simon

Reply
0 Kudos
adarobin
Enthusiast
Enthusiast

Do you have your desktops set to refresh at log off?  If so you're probably hitting this: http://kb.vmware.com/kb/2006707

I called about it when I was running on 4.6, and I was under the impression it was going to be fixed in the next release but I'm on 5.0.1 right now and I still have the issue.

Reply
0 Kudos
gmtx
Hot Shot
Hot Shot

That behavior matches what I'm seeing with 5.1, so it's obviously still not fixed.

Thanks for the link to the KB article.

Geoff

Reply
0 Kudos