vCloud Director has been adding an Auto Discovery feature for VMs in version 8.20 and it’s available for some time now. It’s a cool feature that can simplify migrations, but in practice there are some pitfalls that can make things difficult. To be more concrete: It only works under certain conditions. Tom Fojta has written an article about this feature some time ago (Thanks, Tom). But I think some details are missing and that inspired me to post this.
With the release of vCloud Director 9.5 it became known that only Postgres will be supported in the future as database backend. MS SQL was flagged as deprecated and Oracle is no longer supported with vCD 9.5 onwards. In addition vCloud Director has also been released as an appliance based on PhotonOS. Therefore, I would like to explain how you can switch to the new appliances and the database backend in a few steps.
Since upgrading to NSX 6.4, I get warnings for certain ESXi hosts because there is a VLAN and MTU mismatch. So I checked the vDS healthchecks and found the following error: VLAN 0 is not supported. But since we didn’t remove or add VLANs on the physical switches, I was very surprised. And VLAN 0 shouldn’t exist anyway. So, what is it about and why does the error suddenly occur?
We have recently upgraded from NSX-v 6.3.3 to NSX-v 6.4.3. The upgrade went well so far, but after the upgrade we noticed that the list of logical switches was no longer loaded correctly.
Depending on how we sorted the list, the list was either empty and the error message “Internal server error has occurred” was displayed or it happened while scrolling. In any case we couldn’t use the list with the logical switches anymore. And unfortunately the error message is quite useless.
So we went through the logs of the NSX Manager and found what we were looking for in the vsm.log.
VMworld is a major event lasting several days at which hundreds of activities and sessions are offered every day. So there are many reasons to go there. In fact, I think some people just go for the party. But the question for most of us is: How can I get the most out of my visit?
There are some great blogposts from other people with general tips, like comfortable shoes, big bags or that you should definitely network with other people. Besides these general and useful tips I try to point out some other aspects.
VMware recently released the latest version 2.5 of the vCloud Architecture Toolkit for Service Providers (vCAT-SP). But I know that many service and cloud providers around the globe don’t know what that is and that something like that even exists.
I will therefore try to give a brief overview and introduction to this topic and hopefully show how powerful this toolkit can be for your business.
Two of our vSAN clusters consist of VxRail S570 nodes with Intel X710 NICs. A few weeks ago the ESXi 6.5 hosts failed again and again. Not all at once but a different host every time. Failed means the host was displayed as “not responding” in the vSphere client and VMs stopped running and were restarted by vSphere Availability on other hosts.
Of course we thought of a network error at first, but on the physical upstream switches there were no related events in the logs and also all other hosts were not affected.
The vCloud Director API is a powerful and easy to use solution for getting information about organizations, VDCs, networking, vApps and eveything else. But that’s not all. You can use it for automate all aspects of vCloud Director, too.
You may think it’s difficult to use the vCloud Director API. But I’m trying to show how easy the usage is and what you can do with this API.
So, let’s get started.
If things go wrong in a VMware vSAN 6.x environment you may see congestion warnings and errors – usually in hybrid setups. I try to explain what congestion means in the world of vSAN, why it’s a problem and how to deal with it.
What is congestion?
In short, congestion occurs when you have a bottleneck in the lower layers of your vSAN infrastructure. Or, more concretely: The destaging process of the incoming data, from the flash cache to the capacity disks, is so heavy that one layer of vSAN cannot handle this amount of data.
By default, vCloud Director does not limit the size of memory, disks and number of vCPUs when creating a new virtual machine. This means the global configuration maximums for vSphere apply, which can be a problem for a service provider. Depending on the settings in the allocation model that a SP uses.