VMware Horizon Community
nzorn
Expert
Expert

View 6: Minimum number of ready machines during Composer operations not working

View 6.0.2.  Recently upgraded, but no other issues so far. 

I noticed when I issued a recompose (with wait for users to log off) during the middle of the day it started recomposing all of my desktops (except for those with users logged in).  It did not leave any desktops in the "Available" or "Provisioned" state.  The minimum number of ready (provisioned) machines during View Composer maintenance operations is set to 5 under my pool settings.

Has anyone else ran into this or can verify this happens to them as well?

Reply
0 Kudos
19 Replies
kgsivan
VMware Employee
VMware Employee

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?

Reply
0 Kudos
nzorn
Expert
Expert

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

Reply
0 Kudos
nzorn
Expert
Expert

kgsivan,

Were you able to find anything out on this? 

Thanks

Reply
0 Kudos
nzorn
Expert
Expert

I did another recompose during the day today and same problem.

35 logged in users

67 total desktops

Under the pool itself it says:

Sessions: 33

Number of machines: 67

Connected: 33

Customizing: 34

Reply
0 Kudos
nzorn
Expert
Expert

Opened ticket # 15616034503 with VMware.

Reply
0 Kudos
kgsivan
VMware Employee
VMware Employee

Sorry nzorn ; I missed the thread.

Could not reach to a conclusion / did not find clue from the answers against my questions. Smiley Sad

Let us see what support says

Reply
0 Kudos
nzorn
Expert
Expert

Still not a word from VMware.

Reply
0 Kudos
nzorn
Expert
Expert

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."

Reply
0 Kudos
nzorn
Expert
Expert

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?"

Reply
0 Kudos
nzorn
Expert
Expert

If anyone from VMware is reading this can you look into this case?  It doesn't seem to be going anywhere....

15616034503

Reply
0 Kudos
mpryor
Commander
Commander

This thread caught my eye, I'll check with the support team.
Mike

Reply
0 Kudos
mpryor
Commander
Commander

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%2FGU...) 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 60, 25 VMs in 'connected' state and 35 in 'available' state
  2. Minimum ready VMs set to 40.
  3. Maximum concurrent operations set to 100
  4. 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

Reply
0 Kudos
nzorn
Expert
Expert

Mike,

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.

Reply
0 Kudos
kgsivan
VMware Employee
VMware Employee

Hi nzorm,

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."

Reply
0 Kudos
mpryor
Commander
Commander

> I still don't understand (according to the link again) why a user connected to a desktop be considered a 'READY' state?

As I said in my last reply, the 'ready' state is an internal state which is defined to mean one thing to the provisioning engine only. It doesn't correspond to what most people using the UI would think it does - the UI has a different state it displays that also accounts for existing sessions ('available') which is not the same as the internal 'ready' state. This has now been flagged internally that using the name adds confusion because the average user will misunderstand what it is.

> 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.

Yes, that's correct.

Reply
0 Kudos
nzorn
Expert
Expert

Wow, I'll have to give that a shot during my next recompose then.  This is something that needs to be fixed, I shouldn't have to modify that value every time I issue a recompose.

Reply
0 Kudos
mpryor
Commander
Commander

I know it sounds crazy, but it really is working as designed. If for example you've got the value set to 50 then you should be able to have 50 sessions running in the pool during the recompose, the fact that 30 of them are already connected before you start is unrelated. What you're looking for is a feature that always preserve the pool headroom value during a recompose, so that a recompose will not happen if it's expected to violate the headroom count - this is slightly different, would be very useful but sadly doesn't exist today. Smiley Happy

Reply
0 Kudos
nzorn
Expert
Expert

Min number of machines: 60

Max number of machines: 100

Number of spare (powered on) machines: 20

I changed the Minimum number of ready (provisioned) machines during View Composer maintenance operations to 30.  7 Users were logged in when I issued a recompose.  It started recomposing some of the available desktops before the provisioned desktops, and then it started powering on some of the provisioned desktops to become available.  So at a certain point I only had 7 desktops available during the recompose.  I'm not sure why it would recompose some of the available desktops before the provisioned ones.  While it did not leave 20 spare powered on machines during the recompose atleast it left some machines available.

I'm thinking that in order to have machines available at all times during a recompose I'll just set the Minimum number of ready (provisioned) machines during View Composer maintenance operations to a number about 10 less than the Max number of machines.  I'm hoping this will work, but that will be my next test.

Mike, thanks for info you have posted as you have at least assisted me in getting to the point where some desktops are left available during a recompose.  Unfortunately the paid support with my open VMware case did not provide me any guidance as you did.

Reply
0 Kudos
MrBeatnik
Hot Shot
Hot Shot

I know this is old, but just to chime in on this too:

I understand, from this thread, it is working as expected... but do we know if a feature request has been asked for on this [and if it is being added]?

At least we can work around by upping the number to something silly right before doing a recompose.

Reply
0 Kudos