mark_j
Virtuoso
Virtuoso

Non-persistant pool generating VM names +1 until infinite (far beyond pool naming boundary)

We're running VDM to 2.1. In a non-persistent pool, with additional machine being created one at a time, the number scheme will stay within the pool's range of numbering. However, when VMs are created two at a time at any point, the counter number scheme appears to malfunction from thereon in and begins increasing the pooled VM names sequentially to infinite. This would occur when creating many VMs during an initial pool creation or multiple users login within 5-6 minutes of each other. Unfortunately, there is no mechanism to control how many VMs are created concurrently and I can't prevent this from occurring during production. In a non-persistent pool 2 in size, I've had VMs named <prefix>1-15+(and beyond)

I'd appreciate any suggestions you have for me regarding this, as we'd like to keep the pooled VMs within the same pool of names.

If you find this or any other answer useful please mark the answer as correct or helpful.
0 Kudos
7 Replies
mpryor
Commander
Commander

You can easily configure the number of simultaneous provisioning operations - this is an advanced setting for the VC as added in the VDM admin UI, just edit it to make the changes. Having said that, the behaviour you've seen is expected - VDM will increment the number for new VMs based on which ones already exist in the pool.

0 Kudos
mark_j
Virtuoso
Virtuoso

The advanced option allows setting upper and lower limits on the pool sizing, as well as configuring the available VM number, but there is no setting for number of simultanious provisioning(meaning the number of VMs being cloned/customized concurrently). With the number of incrementing VMs, by design it is supposed to reuse the VM numbers after the VMs have been destroyed. That's why it will work properly and reuse the VM numbers until I create/clone/customize more than one VM at a time - after that point it looses track of itself and increases the number even though there are open numbers at the bottom/middle of the pool. From speaking with the vmware tech's, they believe it should be reusing the unused VMs # in the bottom/middle of the pool. I have a ticket open with VM regarding this and they're getting clarification of this from a higher-level engineer over there.

If you find this or any other answer useful please mark the answer as correct or helpful.
0 Kudos
mpryor
Commander
Commander

The advanced option allows setting upper and lower limits on the pool sizing, as well as configuring the available VM number, but there is no setting for number of simultanious provisioning(meaning the number of VMs being cloned/customized concurrently).

This is a per-VC setting, not per desktop, make the change in the Configuration tab.

With the number of incrementing VMs, by design it is supposed to reuse the VM numbers after the VMs have been destroyed. That's why it will work properly and reuse the VM numbers until I create/clone/customize more than one VM at a time - after that point it looses track of itself and increases the number even though there are open numbers at the bottom/middle of the pool. From speaking with the vmware tech's, they believe it should be reusing the unused VMs # in the bottom/middle of the pool. I have a ticket open with VM regarding this and they're getting clarification of this from a higher-level engineer over there.

No, during normal operation it will increment based on the highest number of the existing VMs, it does not fill in the missing VM numbers. Various people have asked for this functionality though.

0 Kudos
mphodge
Enthusiast
Enthusiast

We have a customer who wants to insert zeros before the numbering, i.e. 001, 002... 010, 011... etc.

Is this possible with the latest VDM? or is it something that could be implemented?

It was a tough job convincing them to put the number at the end of the computer name, as their internal naming convention was something like pc001-xp, pc002-xp, etc. So another useful feature would be to use wildcards in the desktop ID field and not just limit it to a prefix.

0 Kudos
mark_j
Virtuoso
Virtuoso

That current standard naming convention wouldn't permit the naming scheme you described. The starting 00s would be omitted, as it names VMs from 1-999435(some high number). I believe a newer VDI release is due out this Fall, you may want to keep your eyes peeled for more advanced pooling features (Linux support for the connection broker may be added, as per our account's VMWare engineer)

If you find this or any other answer useful please mark the answer as correct or helpful.
0 Kudos
mphodge
Enthusiast
Enthusiast

Thanks for the reply. You wouldn't believe the fuss this naming convention has caused! Smiley Happy

Apparently some people get very 'protective' about their naming schemes, especially in the corporate world, and consequently VDI is struggling to maintain it's reputation as a viable solution!!

Eyes are now peeled...

0 Kudos
markvr80
Enthusiast
Enthusiast

Sorry to reopen an old thread, but I have the same problem with a persistant pool. Our VMs are named prefix-vmXXX and the XXX increments. If I have vm001 to vm050 and delete vm005 then the next vm is called vm051, ie the name vm005 isn't reused. I need it to reuse the "gaps" that are in the pool, otherwise over time I will end up with vm9999 as staff come and go!!

This is an issue because the XXX in the name is also the final part of the IP address, so there is a maximum value for XXX of 249 (we reserve 250+ for networking kit)

Is it possible to force VDM to reuse these old "gaps"?

0 Kudos