At my current assignment, I got busy with the replacement of an existing vCenter Server and migration of all linked objects. This included migrating the vSphere Distributed Switch Port Group objects, settings and permissions.
Exporting the vSphere Distributed Switch configuration is an easy-to-do job using the GUI. However permissions are not included. This post is dedicated to the script I wrote to export and import these permissions.
As it’s getting cold and chilly outside, I though it was a good idea to get my hands on something hot. Something hot you say? Yeah, I know, it’s not a term which I usually mix up with IT-related stuff, but hey! I’ll promise you it’s good =) And no, I’m not talking about a hot tub.
A while ago I was asked to aid in some performance issues in a customers’ vSphere environment. This article is all about troubleshooting your own environment using esxtop in combination with a tool called PAL (Performance Analysis of Logs) which can generate a report including alerts and graphs.
Good morning everyone,
While implementing my first vCloud Director environment for testing purposes, I have created a high level design that I would like to share with the community. Hopefully this will help people understand some of the ways you can use vCloud Director to provide cloud functionality to your datacenter.
Currently my design is at version 0.3. If there would be any major adjustments, I will publish a new blog posting.
The first drawing shows the way vCloud Director uses a management cluster for the vCloud management VMs and have a separate resource cluster to deploy your VDC (Virtual Data Center) in. Next it shows how authentication is flexible for each organization you create and assign resources according to the needs of your customers.
The drawing below shows the communication lines from vApp inside vCloud Director to the physical networks you might have.
Internal organization traffic will be transported over the VXLAN network. The VXLAN network is, in my situation, VLAN25 and is transporting more then one organization. Because VXLAN adds extra information to the VLAN packet, it will not be possible to communicate between organizations without passing through the vCloud Edge.
Addresses used on the internal and external NICs do not have to be unique inside your infrastructure, because all of that traffic is VXLAN traffic. Communication to the external networks will always happen using the physical IP address(es) you assign to the vCloud Edge. The example I always give here is: “You have a customer that wants to move his virtual infrastructure to your vCloud environment. The customer has his own IP subnets and does not want to re-number all of his VMs. Because only IP addresses inside an VDC have to be unique, the customer can keep using his own IP addresses and use the NAT functionality of the vCloud Edge to provide physical network ‘talk’.”
External traffic also flows thru the vCloud Edge and gets NAT’ed to an IP address on the physical network and is therefor routable to the corporate network or the internet (and backwards).
SnowVM 