Could you please tell me the pool size Min / Mix / Spare. and number of Connected VMs at the time of recompose?
Minimum during recompose is set to 5 at pool level.. What was the max number of concurrent composer maint. operations at the vCenter settings?
I don't have the exact number of users and VM's at that time, but there's been a max of 36 users on that pool so far with 67 desktops spun up.
Max number of machines: 100
Number of spare (powered on machines): 20
Minimum number of ready (provisioned) machines during View Composer maintenance operations: 5
Min Number of machines: 60
Should be the defaults:
Max concurrent vCenter provisioning operations: 20
Max concurrent power operations: 50
Max concurrent View Composer maintenance operations: 12
Max concurrent View Composer provisioning operations: 8
Were you able to find anything out on this?
I did another recompose during the day today and same problem.
35 logged in users
67 total desktops
Under the pool itself it says:
Number of machines: 67
Opened ticket # 15616034503 with VMware.
Still not a word from VMware.
Received this today:
"The escalation engineer I have been working with on this SR has managed to reproduce what you are seeing in his lab environment. At this point we now have what we need to create a PR to report the issue up to the developers so they can take a look at it and let us know when they will be able to get the issue resolved. It will take a while before we hear back from them on what the solution will be. If they can provide us some work around we will pass that along, but we will have to wait to find out what the developers say."
So after months of waiting this is what I get back from VMware:
"So that you have an update, it looks like the developers are thinking they will be updating the documentation to reflect how it works rather than change the workings of the software as the documentation update will be much quicker. I don't see any discussion currently about changing the software for future releases at this point, but the discussion is still ongoing.
At this point have we met the expectations that we opened the SR under or did you need me to continue to hold this SR open looking for some additional information?"
If anyone from VMware is reading this can you look into this case? It doesn't seem to be going anywhere....
This thread caught my eye, I'll check with the support team.
After an initial read of the issue internally, there's been a bit of confusion about the underlying problem which resulted in the SR you created not being picked up immediately. Fundamentally, it boils down to a disconnect between what the product does and what the average user would interpret the feature as. To elaborate: the documentation (https://pubs.vmware.com/horizon-view-60/index.jsp?topic=%2Fcom.vmware.horizon-view.desktops.doc%2FGUID-D9EBE966-A755-4618-B20D-B8CD74F128BF.html) refers to "Minimum number of ready (provisioned) machines during View Composer maintenance operations". Internally, this has a very specific definition that means it was successfully provisioned and is not in a maintenance operation such as an initial clone or recompose - it does not mean 'ready to be logged into' since that is the more specific 'available' state, that also takes into account whether the VM is already in use, currently booting up, etc.
This is reflected in the documentation but could be made clearer in the product itself, to quote:
The term "ready" applies to the state of the linked-clone virtual machine, not the machine status that is displayed in View Administrator. A virtual machine is ready when it is provisioned and ready to be powered on. The machine status reflects the View-managed condition of the machine. For example, a machine can have a status of Connected, Disconnected, Agent Unreachable, Deleting, and so on.
From the SR you mentioned, the recompose left the minimum number of VMs alone in a "ready" state at any one time but they were all either connected/disconnected and hence not available for other users. I do agree that it doesn't really fit in with what the average administrator would want to happen though for a floating pool, which is really about preserving spare VMs that are ready to log into at any given point in time, but it is technically working as designed and documented. I've raised it internally to look at providing something that more closely matches what you want but it would be considered a feature request rather than bug fix.
Hope that clears things up for you,
A concrete example for those reading the thread:
- Pool of max size 60, 25 VMs in 'connected' state and 35 in 'available' state
- Minimum ready VMs set to 40.
- Maximum concurrent operations set to 100
- Trigger a recompose, leave existing sessions intact
In this case, when recompose is triggered 20 of the 'available' VMs will be immediately recomposed leaving the remaining 40 VMs intact, 15 of which are available for new users and 25 of which are currently in use but can be reconnected to by their current user. As those in the initial 20 complete, the remaining 15 available VMs will be recomposed. The 25 connected VMs will be recomposed after the existing sessions are finished.
Edit: fixed formatting, tweaked example
Thanks for the reply, I'm glad I looked at this thread this morning as I have not been getting email notifications from this site lately.
Per your link it says: "If your users must be able to access remote desktops at all times, you must maintain a certain number of machines that stay provisioned and ready to accept connection requests from your users even when View Composer maintenance operations take place."
That's all I'm trying to accomplish. My users need access to desktops at all times, even during recomposes, and it obviously isn't working. This prevents me from doing recomposes in the middle of the day.
I still don't understand (according to the link again) why a user connected to a desktop be considered a 'READY' state?
So are you saying that if I change the "Minimum number of ready (provisioned) machines during View Composer maintenance operations" to a number that is slightly higher than the number of users currently logged in that it will leave desktops available during the recompose? Granted I would have to change this number every time I issue a recompose.
The READY doesn't actually implies the desktop status. Theoretically, it just mean that it is ready to accept connection requests. Having said that, the READY state is in context within the system, to ensure if it is in pair with connection broker.
To some extent, I agree that the in-line help or documentation may lead to confusion about to expected behavior of its functionality.
However, if you go through the view administrator guide,
Page 78, "Keeping Linked-Clone Machines Provisioned and Ready During View Composer Operations"
Fourth bullet says:
" The term "ready" applies to the state of the linked-clone virtual machine, not the machine status that is displayed in View Administrator. A virtual machine is ready when it is provisioned and ready to be powered on. The machine status reflects the View-managed condition of the machine. For example, a machine can have a status of Connected, Disconnected, Agent Unreachable, Deleting, and so on."