Chasing threats is like trying to find a needle in a haystack, and new threats continue to emerge every day. Learn how you can simplify application security with VMware AppDefense during the free webcast on May 21. RSVP now!
I must admit to not knowing about this until I stumbled upon it vSphere 6.7 has added a new feature called QuickBoot.
Quick Boot enables the ESXi host to restart straight into the ESXi load screen avoiding the initial POST and memory test screens. This is particularly cool when you are doing ESXi updates as the reboot time is dramatically shortened as shown below.
So how does it work?
- When a reboot is necessary, devices are shut down and the hypervisor restarts
- Hardware initialization and memory tests are not performed
- Improves host availability and shortens maintenance windows
- Supported server hardware (current: shortlist of Dell and HPE systems)
- Native device drivers only – no vmklinux driver support
- Secure boot not supported
How to enable it?
Quick Boot is primarily intended to benefit Update Manager workflows, there are stringent checks for compatibility, according to the following files
- /usr/lib/vmware/loadesx/whitelist.txt & platforms.txt
It is also possible to enable Quick Boot from the ESXi console
- loadESXEnable –e
To test whether or not the last reboot was quick or normal
- vsish -e get /system/loadESX/isBootLoadESX
Additional troubleshooting info can be found in the logs
I have just recently completed an SDDC deployment with my good friend @simoneady and while deploying NSX-V 6.4.5 we noticed we couldn’t ping any VXLAN backed networks which were connected to the newly deployed DLR.
It later transpired to be a firewall issue on the DLR and after some digging, we were able to pinpoint this to the options selected during the deployment wizard. Let me explain further;
If you log in to NSX via the HTML5 UI and create a DLR or ESG with the HTML5 wizard like below.
Continue on to the next page.
Leave auto rule generation ticked which is the default option. Now, this is where it gets interesting and let me explain why; I would normally enable the firewall on the below screen, set the default rule to accept then set the firewall back to disabled.
The rationale behind this is if someone later on accidentally enabled the firewall as the default rule is set to accept it wouldn’t create an outage. However, it appears if you do this within the HTML5 UI once you toggle the enable button it will always stay enabled and more importantly it ignores whether you set it to accept so all traffic is denied.
You can see why during deployment this may catch you out for a period of time as you disabled the firewall but in actual fact, it is not only enabled but enabled with a default deny.
Workflow is below…
What’s even more confusing is the firewall section didn’t make it into the HTML5 UI so on first glance you may assume it’s still disabled as it’s not visible. You need to open up the flex (Flash) UI to see the Edge Firewall section.
Note it does say Firewall configured
And bingo we can see the firewall is started with a default deny rule.
Hopefully, this may help others and I hope to raise an internal SR to make engineering aware of this issue as I do not believe its local to this customer.