All Posts

I am not sure this will work, but it is worth trying. Clone the whole disk. If you have some other program to make an image of the whole disk and then a VM from it, even better. If not - try with Converter - all volumes in and deselect reconfiguration. Configure machine is nothing special from a user's point of view; just select the VM you have created.

It's hard to give an advice without any knowledge of your environment. Anyway, wouldn't it be an option to temporarily add the standalone host to the vCenter Server environment, to perform a live migration? André

Thanks for the response. To clarify, do you mean select the entire d drive or just the Windows partition? I have not used Configure machine by itself, is there anything I need to do there? In fact this is the first time with this program, so any suggestions are appreciated.  I have made vm's from a DVD before with other programs, but never a working drive.   Thanks Rick

Check the status of the WCP service by SSH onto your vCenter and running service-control --status wcp if it's not started use service-control --start wcp There's also this Dell support KB Dell EMC VxRail: ESXi host fails to enter or exit maintenance mode with the Error message: Failed to enter name Namespaces Maintenance mode | Dell UK Which version of vCenter are you running as people have also resolved this issue by upgrading to a later version?

Hello This is a bit strange case. You may try conversion of your machine (e.g. install Converter in it and convert 'this local machine') but then select only drive and deselect reconfiguration. After the cloning completes, run c 'Configure machine' on the cloned VM. And cross fingers HTH, Plamen

Thanks for sending the script. I tried to run it but it errored out, but it got me thinking and I decided to troubleshoot my VMDIR issue. I logged directly into the vCenter and ran these commands: cd /usr/lib/vmware-vmdir/bin ./vdcrepadmin -f showservers -h localhost -u administrator ./vdcrepadmin -f showpartners -h localhost -u administrator I found a legacy 7.0.3 vCenter which I had decommissioned long ago, but had not removed it properly. I tried to use Using the cmsso command to unregister vCenter with External PSC or vCenter with Embedded PSC from Single Sign-On (2106736) (vmware.com) to remove it, but that also errored out. I was about to throw in the towel, but instead I pulled the old vCenter out of mothballs and brought it back online. Sure enough, that fixed the VMDIR error when upgrading the second 8.0 vCenter and the upgrade completed successfully. I'll attempt to decommission and unlink this old vCenter properly next. Thanks for the help!

I came across this thread when faced with the same issue. If you log directly into the web interface of the host - not via vCenter - then you can create a standard switch with a custom name.  You can then configure it as you like from vCenter.  

I would reach out to your VMware Account Manager for getting additional help in understanding the different solutions you have just mentioned. They may also be able to help you with contact of  people who have performed a similar move for similar customers.

Have the same problem? And now installed a new vCenter 8, and the same problem?? All the services on?? No certificate problem??   Actually we dont have internet connections, can it be the problem??   thanks   Dinis

This thread pops up in the search results for problems with the VCSA 8 certificate errors problem, I thought I would add my experience for future reference in case it helps point others to their solution.   I was trying to upgrade 7.0.3.01700 (22357613) to 8.0.2 (22617221), but it was failing with weak signature algorithm errors. I know about the main support article: https://kb.vmware.com/s/article/89424. However, it didn't address all the issues and potential troubleshooting steps. I would suggest testing your certificates with the vsphere8_upgrade_certificate_checks.py Python script at the bottom of that article link, since you can make changes and re-test quickly without going through the upgrade process.   2023-11-08 10:24:58.823Z ERROR #################### Errors Found #################### 2023-11-08 10:24:58.823Z ERROR 2023-11-08 10:24:58.823Z ERROR Support for certificates with weak signature algorithms has been removed in vSphere 8.0. Weak signature algorithm certificates must be replaced before upgrade. Refer to the vSphere release notes and VMware KB 89424 for more details. Correct the following 2 issues before proceeding with upgrade. 2023-11-08 10:24:58.823Z ERROR 2023-11-08 10:24:58.823Z ERROR 1. The certificate with subject '/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' in VECS store MACHINE_SSL_CERT has weak signature algorithm sha1WithRSAEncryption. The certificate thumbprint is D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49. The certificate Subject Key Identifier is A0:11:0A:23:3E:96:F1:07:EC:E2:AF:29:EF:82:A5:7F:D0:30:A4:B4. 2023-11-08 10:24:58.823Z ERROR 2023-11-08 10:24:58.823Z ERROR 2. The certificate with subject '/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' in VECS store TRUSTED_ROOTS has weak signature algorithm sha1WithRSAEncryption. The certificate thumbprint is D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49. The certificate Subject Key Identifier is A0:11:0A:23:3E:96:F1:07:EC:E2:AF:29:EF:82:A5:7F:D0:30:A4:B4. Caution: Verify that any certificates signed by the problematic certificate are not in use by vCenter Server. 2023-11-08 10:24:58.823Z ERROR 2023-11-08 10:24:58.823Z ERROR ######################################################   Our leaf certificate was issued by "InCommon ECC Server CA" (https://crt.sh/?id=12722102) which was issued by "USERTrust ECC Certification Authority" (https://crt.sh/?id=1282303296) which was issued by "AAA Certificate Services" (https://crt.sh/?id=331986). The last one is the problem, because its signature algorithm is sha1WithRSAEncryption. The "USERTrust ECC Certification Authority" is also a problem, because it's issued by the bad root.   [*] Store : TRUSTED_ROOTS Alias: d1eb23a46d17d68fd92564c2f1f1601764d8e349 Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services Subject: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services Subject Key Identifier: A0:11:0A:23:3E:96:F1:07:EC:E2:AF:29:EF:82:A5:7F:D0:30:A4:B4 [*] Store : TRUSTED_ROOTS Alias: ca7788c32da1e4b7863a4fb57d00b55ddacbc7f9 Signature Algorithm: sha384WithRSAEncryption Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USER Trust ECC Certification Authority Subject Key Identifier: 3A:E1:09:86:D4:CF:19:C2:96:76:74:49:76:DC:E0:35:C6:63:63:9A   Based on @BrianCunnie's reply and website, I knew I needed to remove not only the root certificate, but also remove & replace the "USERTrust ECC Certification Authority" at the next level down with its newer self-signed version (https://crt.sh/?id=2841410) that expires in 2038.   At that point, I used the common commands to list, unpublish, and publish.     /usr/lib/vmware-vmafd/bin/dir-cli trustedcert list /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text # This is the AAA Certificate Services root /usr/lib/vmware-vmafd/bin/dir-cli trustedcert get --id A0110A233E96F107ECE2AF29EF82A57FD030A4B4 --outcert /certs/A0110A233E96F107ECE2AF29EF82A57FD030A4B4.pem /usr/lib/vmware-vmafd/bin/dir-cli trustedcert unpublish --cert /certs/A0110A233E96F107ECE2AF29EF82A57FD030A4B4.pem # This is the USERTrust ECC Certification Authority issued by AAA Certificate Services /usr/lib/vmware-vmafd/bin/dir-cli trustedcert get --id 3AE10986D4CF19C29676744976DCE035C663639A --outcert /certs/3AE10986D4CF19C29676744976DCE035C663639A.pem /usr/lib/vmware-vmafd/bin/dir-cli trustedcert unpublish --cert /certs/3AE10986D4CF19C29676744976DCE035C663639A.pem     I then uploaded the new self-signed "USERTrust ECC Certification Authority" (https://crt.sh/?id=2841410) through the vSphere Certificate Manager GUI. I had to do that after the above, because it has the same Subject Key Identifier as the other version, otherwise vSphere would complain that it was already in the store.   At this point, I was still having problems. The VCSA 8 certificate check was still failing. Hmmmm??? I started looking and remembered about /etc/vmware-rhttpproxy/ssl/rui.crt and /etc/vmware-vpx/ssl/rui.crt. These files had the old intermediate+root chain in them, so I removed that (i.e., the "-----BEGIN CERTIFICATE-----" sections) and added the new certificate information to them and restarted the services. I went back to the GUI and got an error: "Error occurred while fetching machine certificates: com.vmware.vcenter.certificate_management.vcenter.tls". This was solved with a full VCSA reboot. For some reason stopping and starting the services wouldn't fix it.   After the reboot, everything looks great. The correct root is there and no errors in VCSA. BUT!!! The VCSA 8 certificate check still fails with: "The certificate with subject '/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' in VECS store MACHINE_SSL_CERT has weak signature algorithm sha1WithRSAEncryption." WHY???!!!   I figured that somewhere the old root information was still in VCSA, but I've replaced everything. Not so fast. Whenever you upload a new leaf certificate, VMware tells us to append the full chain to the end of that certificate. So when it's saying the problem is in MACHINE_SSL_CERT, it's talking about this. But this isn't mention anywhere in the notes and you can't easily troubleshoot it, at least I couldn't. I thought the easiest would be to create a new file that contained the old/current leaf, but with the new root chain appended. But VCSA won't let you do that, because: “MACHINE_SSL_CERT certificate replacement failed. SerialNumber and Thumbprint not changed after replacement, certificates are same before and after.” I understand the error, because the leaf is not changing. But the chain is changing. I kind of feel like I should be able to perform this action.   While reviewing https://kb.vmware.com/s/article/83276, it showed the procedure for extracting the current certificate and private key from the MACHINE_SSL_CERT. When I did that, I confirmed that the “__MACHINE_CERT” alias contained the WHOLE certificate chain (leaf, intermediates, root). So I created a new file that contained the old leaf, intermediate, and NEW root chain. I deleted and recreated “__MACHINE_CERT” and restarted VCSA services. That finally fixed it! The upgrade certificate check script succeeds.     /usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store MACHINE_SSL_CERT --alias __MACHINE_CERT --output ~/entry__MACHINE_CERT-getcert.txt /usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store MACHINE_SSL_CERT --alias __MACHINE_CERT --output ~/entry__MACHINE_CERT-getkey.txt openssl pkey -in entry__MACHINE_CERT-getkey.txt -pubout -outform pem | sha256sum openssl x509 -in leaf_MACHINE_CERT.pem -pubkey -noout -outform pem | sha256sum     I manually created my own leaf_chain_MACHINE_CERT.pem with the right certificates.     /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CERT /usr/lib/vmware-vmafd/bin/vecs-cli entry create --store MACHINE_SSL_CERT --alias __MACINE_CERT --cert leaf_chain_MACHINE_CERT.pem --key entry__MACHINE_CERT-getkey.txt     No more errors with the certificate checks.

Only the source and destination hosts need EnterprisePlus license. Not all hosts. We had 6.5 Enterprise (nonPlus) clusters as source and 7.0 EnterprisePlus clusters as destination. Fortunately we had two extra 6.5 EnterprisePlus licenses, so we re-licensed two hosts in our 6.5 environment.  Then to cross-site vMotion we had to first move within the source site to one of those two hosts. This works well for a migration.