MyDailyITLessons

 Just recently i had an issue where i wanted to configure Workload management to test Tanzu I had trouble finding the intended portgroup. It turned out that my vDS was inside a network folder in the vCenter inventory. After moving it out of the folder, i was able to see the portgroups. Hope i could solve this for some of you strunggling ;)  cheers!

 Just recently i had multiple VMs that took about 20 minutes to boot. There is a very neat tool to analyse the Windows Boot process called xbootmgr Using "xbootmgr -trace boot" I was able to see that "autochk" was taking most time of the boot process.  Googling around lead to the point that autochk thinks that the disk is dirty, may do a checkdisk but doesn´r remove the dirty flag. Solution for me was manually adding that dirty flag to the partition and reboot, causing autochk do fully run a check and finally it cleand up the state. Setting the state is done by calling "fsutil dirty set C:" and if you have multiple partitions you may change the drive letter here. Hope it helps!

 As I was struggling a long time to get this done right and finally have a solution now I feel that it is a good thing to share with you. Using LDAP Authentication in iLO enables you to just use your domain credentials instead of endless lists of random passwords. For AD there is a neat thing and some caveats to consider that caused outages to the iLO login page when done wrong. The only things you have to fill in here is  - Directory Server Address - Directory User Context 1 (do not fill in DC=domain,DC=corp) but @domain.corp  - desired LDAP Port (636 by default) - Use Directory Default Schema Hope it´s helpful to you.

 I was updating a vCenter instance from 7.0 to 7.0.1a but got this error message but everything else seems to work fine.  I just cleared the install state using this procedure  and was able to use VAMI again. Oddly after clearing the update status VAMI was showing the old build number whereas the vSphere Client shows the new one.  After some days there was 7.0.1b released and I tried this again but was stuck again at that point. Just yesterday I tried it again with 7.0.1c but the "Stage" and "Stage and Install" buttons were grayed out. So I digged a little and prepared the VCSA, after that the buttons got clickable again: Backup your appliance first! root@vcsa [ /storage/core/software-update ]# mv install_operation install_operation.bak root@vcsa [ /storage/core/software-update ]# mv stage_install_operation stage_install_operation.bak root@vcsa [ /storage/core/software-update ]# mv stage_operation stage_operation.bak root@vcsa [ /storage/core/software-update/updates

 After some unsuccesful tries to update 7.0 to U1 i created a case with VMware to show them that i get a totally useless ESXi installation after the update to U1 17119627. The Case took a while but finally there is a workaround out for my specific case, actually i´m not thinking to be that specific as I'm just running ProLiant Gen10 and vSAN in a 10 Node cluster. The problem seems beeing with the software FCoE that i´m not using so it´s easy to just remove it from the configstore prior the update: configstorecli config current delete -c esx -g storage_fcoe -k fcoe_activation_nic_policies --all reboot (important)  update to 7.0U1 as usual There should be a patch out soon that hopefully will address this but meanwhile you can try it this way. cheers! -Update 7.0.1c is fixing this issue so you can easily update now.

 Was looking around yesterday for a problem I had with First Class Disk objects in vCenter that we are using via CNS in kubernetes. There is that GUI in vCenter that will list all PVCs and infos around but that will not show the physical path especially on a vSAN Datastore. Here is a small function I wrote that will give you something like this: To learn more about FCDs / IVDs there is a great post  https://cormachogan.com/2018/11/21/a-primer-on-first-class-disks-improved-virtual-disks/