Please provide your feedback in this short Flings' survey.
May 19, 2022

Can this tool add hardware to a VM? The use case being we are planning a migration of our VDI's from Windows 10 to Windows 11, which requires us to add a vTPM to each VM before we can run an in-place upgrade. Would be very useful if this tool could add the vTPM for us when the VM's reboot for normal monthly patching without us having to schedule downtime.


May 19, 2022

Hi Tony, VMDSC does not currently allow for this... we initially targeted CPU and Memory and recently added Cores per Socket.

May 19, 2022

Thanks for the response. Are there any plans to support these types of scenarios?

May 19, 2022

We have been documenting feature requests like this and will consider it for future releases, but we do not have plans to expand beyond the current capabilities at this time.

May 10, 2022

I'm trying this fling, but after deploying and starting VM, I'm unable to connect API port 8010 with postman.
Also if I connect with ssh to VM, and run netstat, I can't find anything that uses 8010 port.

Best Regards

May 10, 2022

Hi Paolo,
Can you check the /home/vmdsc/logs/vmdsc.log file and see if you are getting any errors? My guess is that the VMDSC service is failing to connect to your vCenter either because of DNS or certificate issues.

May 13, 2022

Hi Steve,
thank you for your answer, I checked and found that password was not correctly imported because containing < symbol.
I changed the password on vapp configuration and then relaunched /home/vmdsc/scripts/
Now it is working well

Apr 29, 2022


We have vmware self signed certs as part of our 7.x vcenter but still get " x509: certificate signed by unknown authority" in our vmdsc.log - is this expected behavior? We are unable to make any connections on port 8010 with powershell or postman.

Apr 29, 2022

Hi There! Can you confirm you are using the vCenter FQDN and not the IP address? Also, ensure the FQDN does not include the "https://".

Apr 29, 2022

Confirmed that there is no https:// in front of the FQDN of my VC. Also that it is not using an IP address. My VC has been upgraded many times since 5.x - so there is most likely some legacy cert issues here and I will try and open a case with support to look at. This issue did not happen in my lab were all VM's were fresh.

Apr 29, 2022

Have you tried specifying the CA Certificate URL when deploying the VMDSC appliance? The instructions can be found in Section 3.4, Step 11 of the user guide.

Apr 29, 2022

Yes, but the VC self signed cert doesn't have an "Authority Information Access field" to use.

Apr 29, 2022

Give this a shot... SSH to the VMDSC appliance and run the following commands from the /home/vmdsc/config directory replacing the "VC-FQDN" with your vCenter FQDN:

curl -k https://VC-FQDN/afd/vecs/ca --output ca.cer
openssl x509 -inform der -in ca.cer -out ca-cert.pem
curl -i -vv --cacert ca-cert.pem https://VC-FQDN

I am curious what the output looks like.

Apr 29, 2022

I believe that this is the result of an expectation that all VC's are fresh and that the cert template used was not from 2015...

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: VC-FQDN

Error opening Certificate ca.cer
140266295118592:error:02001002:system library:fopen:No such file or directory:bss_file.c:413:fopen('ca.cer','r')
140266295118592:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:415:
unable to load certificate

* Could not resolve host: VC-FQDN
* Closing connection 0
curl: (6) Could not resolve host: VC-FQDN

Apr 29, 2022

It looks like you forgot to substitute your vCenter FQDN into the commands based on the "Could not resolve host: VC-FQDN" error.

Apr 29, 2022

Got it; not output for the middle command.

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1071 100 1071 0 0 44547 0 --:--:-- --:--:-- --:--:-- 46565

* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: ca-cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here:

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Apr 29, 2022

Hmmm, it definitely looks like you have some old legacy certificate chain issues. If you inspect the vCenter certificate can you identify the self signed CA certs in the chain?

May 03, 2022

I have the same issue, self-signed CA certs
really want to start working with this, is there any workaround for this?

May 03, 2022

We are investigating this issue further and hope to provide a workaround soon.

May 03, 2022

Confirmed that VMDSC fling works after we re-generated our vcenter self signed machine cert.

May 03, 2022

That is great to hear, thank you for the update!

Apr 29, 2022

That is what I am expecting. I have this on the root of my chain;

This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store.

Apr 14, 2022

Hi Steve,
Thank you for this amazing fling.
We've tried to use it in our environnement, in an automation workflow.

Why does it return only the first 10 elements ?

I'm creating configurations for over 1000+ virtual machines at the same time. The workflow is doing well.

But i was expecting the API call "/configs" to return a complete JSON with all the pendings configurations, not only 10.

Thank you,
Have a nice day,

Apr 15, 2022

Hi Bryan,

The "GET /configs" API uses pagination. Apologies we missed mentioning this in the documentation.

To get all your configs, you can use the following query parameters:

* "start": indicates the starting point in your stored configs that you'd like to start fetching from, beginning at 0
* "count": the number of configs beginning from "start" that you would like to fetch, maximum count is 10

"GET /configs?start=&count="

e.g. Currently, hitting "GET /configs" returns the first 10 configs

And, hitting the API route with "start=1" and "count=10" will give you the next 10 configs stored in VMDSC (from 1 to 11)

* "GET /configs?start=0&count=10" fetches the first 10 configs
* "GET /configs?start=10&count=10" fetches the the next 10 configs
* ... and so on

If you could iterate over "start" in a loop in your scripts, you should be able to fetch all your configs.

Moreover, we appreciate the feedback, and we'll make it easier for you to use this API in the next release (coming very soon in the next few days).

You will be able to get all your configs by just hitting the "GET /configs" API route, and still be able to use pagination if you would prefer.

We are very excited to hear that you're creating configurations for 1000+ VMs! Please feel free to reach out to Steve (stilkens at vmware . com) and me (ppranay at vmware . com), we would love to learn more about your use-case!

Thank you,

Apr 19, 2022

Hi Pranay,

Thank you for your complete answer, we do really appreciate your availability.

This sunday, we had a first change on our dev environnement, with a first batch of ~200 VMs to rightsize.

The change, went well actually, without the GET /configs, because i didnt had time to implement it. But i iterate over /config for all the VMs to display the pending configurations (not ideal...)

Today, i just tried the API endpoint with start&count and it works as you described, thank you. But it's a good news that soon we'll be able to use the /configs to get all the configurations.

Just to let you know, we had some issues with the VMDSC appliance during the change.
When applying configurations over the ~200 VMs, we had to reboot the appliance because every API call (POST /config , DELETE /config, GET /config) returned an error :

"error": "pq: sorry, too many clients already"

The reboot solved it.
Otherwise, the mass reboot over the ~200 VMs was a sucess and the configurations were nicely applied.
Only a few gets the already-reported-bug "CPUID power on failed".


Apr 27, 2022

Hi Bryan,

VMDSC 1.1.0 was released on Monday 4/25 which includes a bunch of product enhancements. I would love to hear more about your use case... would you be open to chatting?


Apr 28, 2022

Hi Steve,

Thank you for your update, i'll try it out really soon.

Of course, i'm definitely open to chatting
You can reach me out on my professional email : myusername at