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,
Mike
---
A concrete example for those reading the thread:
1. Pool of max size 50, 20 VMs in 'connected' state and 30 in 'available' state
2. Minimum ready VMs set to 30.
3. Maximum concurrent operations set to 100
In this case, when recompose is triggered twenty of the 'available' VMs will be immediately recomposed leaving the remaining 30 VMs intact, 10 of which are available for new users and 20 of which are currently in use. As those complete, the remaining 10 available VMs will be recomposed. The 20 connected VMs will be recomposed after the existing sessions are finished.
