Quantcast
Channel: Tomas Fojta – Tom Fojta's Blog
Viewing all 242 articles
Browse latest View live

VCP-NV Exam Experience

$
0
0

VCP-NVDuring VMworld 2014 VMware released new certification track – Network Virtualization. There is already quite a big number of bootstrapped VCDX-NVs which is the highest certification level and it is also nowNV certification track possible to schedule the entry level VCP-NV exam.

 

As I think that NSX is a great technology I am going for this certification track and immediately scheduled VCP-NV in my nearby PearsonVue test center and today took the exam.

While not having much time for preparation I obviously downloaded the exam blueprint and was surprised how extensive it is –  nine objective categories ranging from the NSX architecture, VXLAN, distributed routing and firewalling, Edge services up to service composer, vSphere standard and distributed switch features and vCloud Automation Center integration. From the sheer content it looks like it is not going to be a simple exam.

I have been working with NSX for some time so was pretty confident in all the areas. Prior the exam I reviewed those areas I work less with (Service Composer, Activity Monitoring, dynamic routing protocols – BGP, IS-IS) and went through the packet walks (VM, VTEP, Controller, Multicast, Unicast, etc) for switched, routed and bridged traffic.

In April I passed Cisco CCNA certification so this gave me good opportunity to compare these two entry level networking exams from two major vendors with completely different SDN strategy.

VCP-NV is obviously heavily based on VMware NSX so do not expect much OpenFlow SDN or any Cisco ACI there. Compared to CCNA there is also no basic network theory (subnetting, OSI model, protocols). There are 120 questions in 2 hour time window which is quite a lot. But all are multiple choice questions – no CLI simulators or flash based questions. The questions cover all blueprint areas and my assumption is they are up to the level of VMware NSX: Install, Configure, Manage training which I did not take (only its VMware internal bootcamp predecessor). I was able to go through the test quite quickly – there is usually no reason to dwell on a particular question longer than 30s. You either know the answer or not.

The questions were mostly clearly written which made taking the exam quite enjoyable experience (well it might have been shorter). You get the result immediately and in my case it was a pass.

My recommendation for potential candidates: know vSphere networking (including the advanced features – NetFlow, Port Mirroring, …), have hands on experience with NSX – if you cannot get the bits or do not have a lab use the NSX Hands-On Labs, which are really good and lastly take the NSX ICM course!

Now back to my VCDX-NV design…



Multitenant Service Network in vCloud Director

$
0
0

Service providers often have to provide additional services to their cloud tenants. An example is providing licensing services (KMS) for Windows VMs deployed from provider managed catalog or RHEL Satellite servers for licensing and patching Red Hat VMs. The questions is then where to deploy these shared services virtual machines so they are securely available in multitenant environment?

In my older blog post Centralized Logging in vCloud Director Environments I described how a shared vCloud Director external logging network can be used to collect logs from Edge Gateways. So the idea is to use the same network for connection to the shared services VMs (KMS/Satellite) running in Administration Organization. The Edge Gateway can have only 10 interfaces so it is good that we do not waste another one. Let’s have a look at following diagram:

Edge GW Logging and admin services

We have 3 organizations and one Org VDC in each – Customer 1, Customer 2 (the tenants) and Admin Organizations (managed by the provider). The tenants connect their vApps to the shared internet network (yellow) via the Edge Gateways by using sub-allocated public addresses (8.8.8.x) utilizing source or destination NAT of their Org VDC network. Each Edge Gateway is connected to another vCloud external network (black) that is using both for Edge logging and access to shared services running in the Admin Organization.

Notice that there are two IP subnet ranges assigned to the service external network. The 10.0.5.0/24 is used solely for the Edge logging. The syslog server sits in this network (10.0.5.254) and firewall infront of it ensures that only Edge logs get there. The Edge Gateway IP from this network (10.0.5.1 and 10.0.5.2) is not sub-allocated for tenant use so they cannot create NAT rules with it. They could only route (one way) from their Org VDC networks and send UDP packets but the syslog firewall denies such traffic as it is coming from internal (192.168.1.2) IPs.

The second IP subnet range of the service network (172.16.254.0/24) is used for the communication to the service VMs running in Admin Organization. So how is this achieved securely?

  1. The provider sub-allocates the Edge IP to the tenant so he can create NAT rules. So 172.16.254.1 is sub-allocated to Customer 1, 172.16.254.2 is sub-allocated to Customer 2.
  2. The provider pre-creates SNAT rule for each deployed Edge Gateway. The rule must be applied on the Service network, original IP range is everything 0.0.0.0/0 and translated IP is the sub-allocated IP of the Edge.
    SNAT ruleThe tenant has to be told not to delete or alter the rule otherwise his access to shared services will not work anymore.
  3. The provider creates destination NAT rule for his service VMs running in Admin Organization. To do this he first needs to have sub-allocated IP addresses (in my example 172.16.254.3 and 172.16.254.4) and then DNATs them to the VM internal IPs 192.168.1.2 and 192.168.1.3. Obviously port forwarding could be used as well to save some IPs as long the port numbers of the services are not the same.

That’s it. Any traffic from the tenant’s VM to the external IP address of the service VM (e.g. 172.16.254.3) will be SNATed by the tenant Edge GW and DNATed by the Admin Edge GW and securely delivered without the tenants being able to contact each other (unless the create DNAT rules as well which could be prevented by MAC ACLs on the external network).

I would also advise to use some obscure IP ranges for the service network so they do not overlap with customer defined Org VDC network ranges.


How To Change VXLAN VTEP MTU Size and Teaming Policy

$
0
0

One of my customers has configured VXLAN in vCloud Director environment and then created multiple Provider and Org VDCs and deployed virtual networks. Then we found out that MTU and teaming policy configuration was set up incorrectly. Redeployment of the whole environment would take too much time, fortunately there is a way to do this without rip and replace approach.

First little bit of background. VXLAN VTEPs are configured in vShield Manager or in NSX Manager (via vSphere Web Client plugin) on cluster/distributed switch level. vShield/NSX Manager creates one distributed switch port group with given parameters (VLAN, teaming policy) and then for each host added to the cluster creates VTEP vmknic (with configured MTU size and DHCP/IP Pool addressing scheme). This means that teaming policy can be easily changed directly at vSphere level by direct edit of the distributed switch port group and MTU size can be changed on each host VTEP vmknic. However every new host deployed into the VXLAN prepared cluster would still use the wrong MTU size set in vShield/NSX Manager. Note that as there can be only one VTEP port group per distributed switch, clusters sharing the same vSwitch need to have identical VTEP teaming policy and VLAN ID.

The actual vCNS/NSX Manager VTEP configuration can be changed via following REST API call:

PUT https://<vCNS/NSX Manager FQDN>/api/api/2.0/vdn/switches/<switch ID>

with the Body containing the new configuration.

Example using Firefox RESTClient plugin:

  1. Install Firefox RESTClient plugin.
  2. Make sure vCNS/NSX Manager certificate is trusted by Firefox.
  3. In Firefox toolbar click on RESTClient icon.
  4. Create authentication header: Authentication > Basic Authentication > enter vCNS/NSX Manager credentials
  5. Select GET method and in the URL enter https://<vCNS/NSX Manager FQDN>/api/2.0/vdn/switches
    VDS Contexts
  6. This will retrieve all vswitch contexts in vCNS/NSX domain. Find ID of the one you want to change and use it in the following GET call
  7. Select GET method and in the URL enter https://<vCNS/NSX Manager FQDN>/api/api/2.0/vdn/switches/<switch-ID>
    VDS Context
  8. Now copy the Response Body and paste it into the Request Body box. In the XML edit the parameters you want to change. In my case I have changed:
    <mtu>9000</mtu> to <mtu>1600</mtu> and
    <teaming>ETHER_CHANNEL</teaming> to <teaming>FAILOVER_ORDER</teaming>
  9. Change the metod to PUT and add a new header: Content-Type: application/xml.
    PUT Request
  10. Send the request. If everything went successfully we should get Status Code: 200 OK response.
    OK Response

Now we need in vSphere Client change MTU size of all existing hosts to the new value and also change the teaming policy on VTEP portgroup (in my case from Route based on IP hash to Use explicit failover order).

vCloud Network and Security (vShield Manager) supports following teaming policies:

  • FAILOVER_ORDER
  • ETHER_CHANNEL
  • LACP_ACTIVE
  • LACP_PASSIVE
  • LACP_V2

NSX adds following two teaming policies for multiple VTEP vmknics:

  • LOADBALANCE_SRCID
  • LOADBALANCE_SRCMAC

Update 9/22/2014

Existing VXLAN VNI portgroups (virtual wires) will use original teaming policy, therefore they need to be changed to match the new one as well.

When using FAILOVER_ORDER teaming policy there must be also specification of the uplinks in the XML. The uplinks should use the names as defined at the distributed switch level.

<teaming>FAILOVER_ORDER</teaming>
<uplinkPortName>Uplink 2</uplinkPortName>
<uplinkPortName>Uplink 1</uplinkPortName>


Troubleshooting Multicast with Linux

$
0
0

I was looking for lightweight tool which would help me with troubleshooting multicast on VXLAN transport network (underlay). While both vCNS and NSX have built in tools (pings of various sizes and broadcast packets) I needed something more flexibile where I could do arbitrary IGMP joins and leaves.

I used CentOS VM with one interface directly on transport network and software SMCRoute. This link contains binary package that works on RHEL/CentOS. Some other notes:

  • if you have multiple interfaces make sure the multicast is routed through the correct one:
    route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
  • I had to install also glibc package:

    yum -y install glibc.i686

  • Make sure the kernel supports multicast

    cat /boot/config-<kernel version> | grep CONFIG_IP_MULTICAST

  • Enable ICMP ECHO on broadcast/multicast

    sysctl net.ipv4.icmp_echo_ignore_broadcasts=0

  • Start the smcroute daemon first:
    smcroute -d

To join and leave a multicast group use -j and -l commands:
smcroute -j eth0 239.0.0.1
smcroute -l eth0 239.0.0.1

To check current memberships use:
netstat -ng

or

ip maddr

IGMP version can be changed with following command:

echo “2” > /proc/sys/net/ipv4/conf/eth0/force_igmp_version

Additional useful statistics about IGMP joins:

cat /proc/net/igmp

To see which hosts are member of particular IGMP group just ping it and see who replies:

[root@CentOS~]# ping 239.1.0.10
PING 239.1.0.10 (239.1.0.10) 56(84) bytes of data.
64 bytes from 1.1.0.1: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 1.1.0.3: icmp_seq=1 ttl=64 time=0.256 ms (DUP!)

Hosts 1.1.0.1 and 1.1.0.3 replied to ping on 239.1.0.10 multicast group.


VXLAN on Routed Transport Network

$
0
0

One of the major benefits of VXLAN technology is that it allows creating virtual Layer 2 segments over Layer 3 routed networks. VTEPs (VXLAN Tunnel End Points) encapsulate and decapsulate ethernet frames of VMs on virtual networks and send them as UDP packets. However there still must be a mechanism that provides ability for sending VTEPs to find the receiving VTEPs for broadcast, unknown unicast and multicast (BUM) traffic.

In NSX we can use multicast, hybrid and unicast modes. Hybrid and unicast modes leverage controller cluster that has knowledge of the entire VTEP topology. However in vCloud Network and Security (vCNS) we can use only multicast mode.

While setting up a multicast in a flat layer 2 network is very easy and only requires enabling IGMP snooping and querrier on the physical switch infrastructure, routed multicast is much harder. That is why hybrid and unicast modes that NSX provides are so useful. In unicast mode all BUM traffic is replicated by VTEPs. In hybrid mode, multicast is used in each L2 segment of the transport network while unicast is used to send for replication of the traffic to the other segments.

In my recent VXLAN deployment we however had to stick to pure multicast mode as we used vCNS. To route multicast traffic the physical router was enabled to use PIM-SM (Protocol Independent Multicast in Sparse Mode) with rendezvous point. However it turned out that setting up the VTEPs is not straightforward and not very well documented with some misinformation in blog post I found on the web.

Each VTEP needs to have an IP address assigned. In vCNS the assignment happens over DHCP protocol only,

Auto-assigned VTEP IP address

NSX provides next to DHCP also ability to use network pools. As we were using vCNS and had no DHCP servers in the VXLAN transport network we had to go into each host and manually assign the VTEP vmkernel port IP address through vSphere client. Unfortunately this is not enough for routed communication on the transport network. Default gateway in the VXLAN network stack must be defined.

Missing gateway

The default gateway must be added through ESXi CLI interface as can be seen in above screenshot it is not configurable via GUI. Originally we created a static route to the other segment, but that is not enough (actually not needed at all) and instead the default gateway must be defined with the following command.

esxcli network ip route ipv4  add -n default -g 1.1.1.1 -N vxlan

where 1.1.1.1 is the gateway IP address and vxlan is the networking stack.

The verification that gateway is set properly can be done with net-vdl2 -l command.

net-vdl2

 


Promiscuous Portgroup Myth

$
0
0

Topic of promiscuous portgroup on virtual switch came up lately from different directions therefore I decided to summarize some information and also debunk one particular myth.

What is promiscuous port? This is what Wikipedia says:

In computer networking, promiscuous mode or promisc mode is a mode for a wired network interface controller (NIC) or wireless network interface controller (WNIC) that causes the controller to pass all traffic it receives to the central processing unit (CPU) rather than passing only the frames that the controller is intended to receive. This mode is normally used for packet sniffing that takes place on a router or on a computer connected to a hub (instead of a switch)…

So how can this be related to virtual environment and virtual switch? VMware KB article 1002934 sheds some light here:

By default, a guest operating system’s virtual network adapter only receives frames that are meant for it. Placing the guest’s network adapter in promiscuous mode causes it to receive all frames passed on the virtual switch that are allowed under the VLAN policy for the associated portgroup. This can be useful for intrusion detection monitoring or if a sniffer needs to analyze all traffic on the network segment.

So does this mean enabling promiscuous port on a vSwitch will make all vSwitch frames visible to VM connected to such port? So let’s step back and explain how VMware vSwitch works. The main difference from a physical switch is that it does not learn MAC addresses by observing passing traffic (and that is why you hear sometimes networking people saying it is not a real switch). It instead relies on the the information the hypervisor (VMkernel) provides about VM vNIC MAC addresses. It basically knows that all vSwitch non uplink ports are used only by VMs (with known MAC addresses). So a frame originating on a VM connected to vSwitch will be either delivered to the right port on the same host (if it is in the same VLAN and matches the destination MAC) or sent to uplink (usually trunk) port. There it is either flooded or switched to the right port by the physical switching infrastructure depending if it is unknown or known unicast and eventually delivered to the right host (if it belongs to a VM) or to a physical device.

So if you think about this behavior described above it should be clear that VM connected to a promiscuous port or portgroup will not see all the vSwitch traffic but only the traffic that is accessible on the host where the VM resides.

Let’s have a look at the following example with three virtual machines (VM A, VM B, VM C) each on different ESX host (Host A, Host B, Host C) connected via physical switch (Port A, Port B, Port C):

Three Host Diagram

 

All VMs are in the same portgroup of VMware vSphere Distributed Switch in VLAN 100, while the port of VM A is set as promiscuous.

So which traffic between VM B and C will and will not VM A see?

When VM B (with MAC B) will try to talk to VM C it will send broadcast ARP packet to find VM C MAC address (MAC C). The physical switch will see the broadcast frame coming to Port B, will note the MAC B address on VLAN 100 is behind this port and will flood the frame to all other ports. vSwitch on host A will get this frame and forward it to all ports on VLAN 100 (it is a broadcast frame) thus to VM A.
VM B will get the ARP request and reply to it with unicast reply from MAC C to MAC B. Physical switch will enter the MAC C into its MAC table noting it is behind port C on VLAN 100 and switch the frame to already learned location of MAC B – to port B. vSwitch will then deliver the frame to VM B. As you can see no frame was delivered to host A and therefore VM A will not see the reply.

Now when communication between VM B and VM C has been established they can start talking with each other and physical switch knowing locations of MAC B and MAC C will switch the frames only between ports B and C of hosts B and C. VM A will see nothing from this unicast communication.

After while the MAC table on the physical switch will expire (if it has shorter timeout than VM B or C ARP cache). In such case it will forget the location of MAC B or C and will flood frame to B (or C) to all VLAN 100 ports and only then VM A will get the frame as the flooded frame reached host A as well.

Broadcast and possibly multicast traffic from VM B or C will reach host A and thus VM A as well.

This should debunk the myth that promiscuous port can be used for packet sniffing. For that you need port mirroring.

There are however use cases for promiscuous port and these are related to the (non-)learning behavior of vSwitch. If VM A would like to see traffic for additional MAC address D which is not hardcoded to its vNIC promiscuous port is requirement. Examples of such use case are nested VMs (VM A is virtual ESXi host) or floating MAC for highly available load balancing VMs (MAC masquarade). As the MAC D responds to ARP requests the physical switch will learn that MAC D is behind port A and will deliver the frame properly. vSwitch on host A will then flood the traffic to all promiscuous ports in the VLAN on the host as it does not know otherwise where to deliver it. Read William Lam’s article how to improve efficiency of this through VMware Fling (VMkernel vib plugin) that gives vSwitch learning ability.

Nested VM


VCD-SP 5.6 Upgradability

$
0
0

Just a short post.

vCloud Director 5.6.3 – the first release solely for service providers was released on Tuesday. There is however no upgrade path from vCloud Director 5.5.2 which was released a month ago. So if you are a service provider do not upgrade to 5.5.2 unless you want to wait for the next VCD-SP release which will support the upgrade.


VCIX-NV Exam Experience

$
0
0

VCIX-NVAfter passing my VCP-NV – the entry level certification for VMware NSX network virtualization technology as soon as it was available I scheduled its advanced exam called VMware Certified Implementation Expert. While there is Expert in the name it should not be confused with VCDX (VMware Certified Design Expert) which is the next level certification. The VCIX is actually more similar to the vSphere or Cloud VCAP Administration exams (VCAP-DCA or VCAP-CIA). Although the exam was announced in October I had to wait till end of November to take it with one test center asking me to reschedule it elsewhere.

The exam concept is very similar to other VCAP Administration exams – cca 4 hours of lab tasks which are usually related to each other. The lab is a nested virtual environment hosted most likely somewhere in west coast USA. You are accessing it remotely while using small test center 4:3 low resolution monitor through a test app that switches screens between the questions and RDP jump box. The awkwardness of switching between questions and the environment (copy paste is not working) together with high latency that makes VM consoles screens redraw line by line (I had to make them smaller to actually see ping results in real time) and PDF manual reading impossible, all that makes the test experience very hard. vSphere Web Client slowness and browser crashes did not help either.

I also had issues understanding some of the questions – I provided feedback through the test tool (bad idea – you will loose precious time) and internally at VMware so I hope that will get fixed in the future.

On the other hand the tasks that you should be implementing or troubleshooting were actually a lot of fun. If I would do those in my lab they would not be that hard but I must admit that I ran out of time, did skip 2 tasks and did not solve 2 troubleshooting ones. As there is altogether about 17 questions I was not sure if I passed but today (after 1 week of waiting) I received email with a passing score.

So what about preparation? I would recommend going through the Hands on Lab or the NSX Install Configure Manage labs as those are very similar to the testing lab. For the troubleshooting I would propose building your own lab from scratch and redoing all the lab tasks from ICM course – this will provide experience of quickly finding the touch points to check when something is not working (emphasis on quick as there will not be enough time to read manual and experiment in the actual exam). Work through all the chapters mentioned in the blueprint. The exam covers most of them.

Good luck!



Homelab: Downsizing NSX Controller

$
0
0

One of the problems of testing NSX in homelab environment is that it is really resource hungry. For example NSX Manager VM deploys with 12 GB RAM. While it is simple to edit its settings and lower memory to about 8 GB without any major impact, VMs that are deployed by NSX automatically (Controllers and Edges) cannot be edited in vSphere Client as the Edit Settings menu option is disabled. Each NSX Controller requires 4 vCPUs and 2.05 GHz CPU reservation. If you go by the book and deploy 3 of them it creates quite a resource impact.

vCPUs can be changed by editing VMs VMX file or by hacking NSX Manager OVF file from which it is deployed from on NSX Manager (located in common/em/components/vdn/controller/ovf/nsx-controller-<version>.vxlan.ovf) if you know how to get to support engineer mode or are not afraid of mounting linux partitions. The CPU reservation cannot be changed this way.

The approach I use is to disable vCenter Server protection of NSX Controller VMs. Find their MoRefIDs (for example with vCenter Managed Object Browser) and then delete respective records from vCenter Server VPX_DISABLED_METHODS table. Afer a restart of vCenter service the VMs are no longer protected and you can simply edit their settings in vSphere Client.

Disclaimer: this is unsupported and should not be done in production environments.


Load Balancing HA vCenter Single Sign-On with NSX

$
0
0

NSX LBOne of the deployment options for vCenter Single Sign-On 5.5 (SSO) is high availability mode. It usually consists of two load balanced SSO nodes deployed in single site configuration. It is quite complex to set up and manage therefore I usually advise customers to avoid such configuration and instead co-deploy SSO together with vCenter Server on the same virtual machine – this results in the same availability of vCenter Service and SSO.

However there are reasons when you cannot do this and need to deploy highly available SSO instance. One is if you want to have multiple vCenter Servers in the same SSO domain with single pane of glass Web Client management. Another is vRealize Automation (vRA) deployment which also requires SSO.

VMware has published two whitepapers about the topic. The first VMware vCenter Server 5.5 Deploying a Centralized VMware vCenter Single Sign-On Server with a Network Load Balancer unfortunately unnecessarily adds even more complexity to the whole process. The paper also describes actve – active load balancing of the nodes which is however unsupported configuration (see here). While active – active load balancing might work with vCenter Server services it does not work with vRealize Automation (vCAC). This is due to the tokens used for solution authentication – WS Trust tokens are stateless but WebSSO are not. Also from what I heard vSphere 6 will not work in active – active configuration at all.

The second whitepaper Using VMware vCenter SSO 5.5 with VMware vCloud Automation Center 6.1 is more recent and while you see vCAC/vRA in its title it still very much applies for pure vSphere environments as well (skip the vRA specific chapters) and it is the one I would recommend. It also describes Active – Passive configuration of F5 Load Balancer.

The topic of this article is however usage of NSX load balancer instead of F5. Contrary to vCNS load balancer, NSX can be configured in Active – Passive mode and thus you can create supported HA SSO configuration with pure VMware solutions.

I will not go too deep in the SSO specific configurations in HA setup (did I mentioned it is complex?) as it is very well described in the second whitepaper mentioned above – instead I will focus on the NSX part of the configurations.

The architecture is like this: two SSO nodes with dedicated NSX load balancer in proxy – on a stick mode. This means LB is not inline of the traffic but instead has only 1 interface and SNAT and DNATs the traffic to the nodes. While inline transparent mode configuration is also possible I believe on a stick config is simpler and provides better resiliency (dedicated LB appliance for each application).

Here are the steps for NSX load balancer configuration:

  1. Deploy Edge Service Gateway for the Load Balancer with one interface preferably in the same subnet as SSO nodes.
  2. Enable Load Balancer feature
    NSX_LB
  3. Upload CA certificate and SSO certificate. See the second whitepaper on how to create SSO certificate.
    Certificates
  4. Configure service monitoring. While you could use the default TCP healh check, I prefer custom HTTPS type healthcheck which is monitoring /lookupservice URL.Service Monitoring
  5. Create Application Profile. During the SSO node configuration before the custom certificates are exchanged on each node you would use simple TCP profile or perhaps SSL passthrough profile (as the SSL certificate configured in NSX would not match self-signed certificate on the nodes). Another alternative is to edit /etc/hosts on each SSO node to fake the VIP hostname to point to the node (this is described in the first white paper). Once you replace the certificates on the nodes you can use SSL termination on the load balancer, configure VIP certificate and Pool Side certificate and also enable Insert X-Forwarded-For HTTP header so in theory we would see from where the authentication request is coming from (unfortunately SSO access log does not display the information). Application Profile
  6. Create Application Rule. Here we will define the logic that will perform the active – passive load balancing. Each SSO node will be in separate pool, with the primary node set up as default. ACL rule is defined to see if the primary node is up. If not we will switch the backend pool to the secondary node. The pool names must match the ones we will create in the next step.

    # detect if pool “SSO_primary” is still UP
    acl SSO_primary_down nbsrv(SSO_primary) eq 0
    # use pool “SSO_secondary” if “SSO_primary” is dead
    use_backend SSO_secondary if SSO_primary_down
    Applicaiton Rule

  7. Create SSO_primary and SSO_secondary pools. Each will have one SSO node with the healthcheck from step 4 and ports 7444. Notice that I have defined the pool member as vCenter VM container object so NSX will retrieve it’s IP address dynamically via VM Tools. While I could hardcode the node IP address this is nice showcase of NSX – vCenter integration. If inline mode you would check the Transparent checkbox for each pool.
    Pool
  8. Now we can create virtual server. We will select Application Profile from step 5, Default Pool from step 7, in the Advanced Tab Application Rule from step 6. For VIP I used the LB default IP (from step 1) and HTTPS 7444 port.
    Virtual Server
  9. As a last step do not forget to disable firewall or create firewall rule for the IP and port define in the previous step.

How to Generate SSL Certificates for vRealize Operations

$
0
0

vRealize Operations 6 (vRops) has different SSL certificate generation requirements than the older version. I have not found it publicly documented anywhere so here it is:

  1. Generate private key:
    openssl genrsa -out vrops.key 2048
  2. Create certificate signing request:
    openssl req -new -key vrops.key -out vrops.scr -days 365 -sha256
  3. Sign vrops.scr by your Certificate Authority
  4. Create PEM text file which contains signed cert from #2, private key from #1 and CA certificate (optionally intermediate certs as well)
  5. Go to vRops admin portal and click the certificate icon in the top right corner (next to admin). Install the new certificate by uploading the PEM file from #4.

Install CertificateWait a little bit and then re-login. Reboot is not necessary.

 


Source NAT Rule for All Internal Networks in vCloud Director

$
0
0

In order to access external network resources from internal Org VDC networks Source NAT (SNAT) rule must be created on the Edge Gateway which translates internal IP address to a sub-allocated IP address of a particular external interface.

The internal source IP address can be entered in these formats:

  • Single IP address
  • Range of IP addresses
  • CIDR format

As you can see it is not possible to put ‘Any’ as it is with firewall rules configuration.

After investigating what would be the easiest option to use, this is what I found out:

In case where Edge Gateway is deployed by NSX Manager then it is possible to use following CIDR entry 0.0.0.0/0.

SNAT Rule

Unfortunately this is not working with Edge Gateway deployed by vShield Manager (vCNS) where Edge configuration fails with the following error:

…- java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (15012): Invalid IP Address input ‘0.0.0.0/0′ for field ‘rules.natRulesDtos[4].originalAddress’.
– com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (15012): Invalid IP Address input ‘0.0.0.0/0′ for field ‘rules.natRulesDtos[4].originalAddress’.
– VSM response error (15012): Invalid IP Address input ‘0.0.0.0/0′ for field ‘rules.natRulesDtos[4].originalAddress’.

The alternative is to use the following IP range: 0.0.0.1-255.255.255.253.


vCloud Director Portal Access over IPv6

$
0
0

I got interesting question from a colleague if vCloud Director portal can be accessed over IPv6. I suspected the answer is yes so I had little bit of fun and did a quick test.

With NSX load balancer in front of my two VCD cells I created IPv6 VIPs for HTTP, HTTPs and VMware Remote Console (TCP 443) traffic and used the existing IPv4 pools. I also added these IPv6 addresses to my DNS servers so name resolution and certificates would work and was ready to test.

Load Balancer Virtual IPs

 

As I terminate SSL session on the LB and insert client IP into the header with X-Insert-For-HTTP I could observe both IPv6 and IPv4 clients in the vCloud Director logs:

Client coming from IPv6 fd13:5905:f858:e502::20:

2015-01-16 19:06:06,431 | SECURITY | pool-eventPublishing-4-thread-1 | SyslogEventPublisher           | Event [id=6869f13c-0643-4afc-b083-982ecc920341, timestamp=1421431566380, type=com/vmware/vcloud/event/session/login, serviceNamespace=com.vmware.vcloud, properties={
...
currentContext.user.clientIpAddress=fd13%3A5905%3Af858%3Ae502%3A%3A20,
entity.name=administrator,
currentContext.user.proxyAddress=10.0.1.1,

Client coming from IPv4 10.0.2.104:


2015-01-16 19:29:46,879 | SECURITY | pool-eventPublishing-4-thread-1 | SyslogEventPublisher | Event [id=6a414e3f-19e7-45c2-83b7-5e0a7d90758b, timestamp=1421432986823, type=com/vmware/vcloud/event/session/login, serviceNamespace=com.vmware.vcloud, properties={
...
currentContext.user.clientIpAddress=10.0.2.104,
entity.name=administrator,
currentContext.user.proxyAddress=10.0.1.1,

Where 10.0.1.1 is load balancer internal interface. Remote Console proxy and OVF Tool also work.


Automate ESXi Host VTEP Default Gateway

$
0
0

As discussed in my older article VXLAN routed transport network requires to set default gateway of vxlan stack on each ESXi host. While NSX has concept of IP Pools which allows automatic VTEP configuration (including gateway), older vCloud Network and Security (vShield) technology does not have this feature and VTEP IP address must be configure via DHCP or manually.

Following quick and dirty PowerCLI script shows how this can be automated at cluster level:


$hosts = Get-Cluster Cluster1 |Get-VMHost
foreach($vihost in $hosts){
$esxcli = get-vmhost $vihost | Get-EsxCli
$vihost.name
$result=$esxcli.network.ip.route.ipv4.add("10.40.0.1","vxlan","default")
$esxcli.network.ip.interface.ipv4.get("","vxlan")|format-list IPv4Address
$esxcli.network.ip.route.ipv4.list("vxlan")|Format-Table
}

The script sets vxlan stack default gateway to 10.40.0.1 on each host in the cluster ‘Cluster1‘ and displays each host name, VTEP IP address and vxlan routing table.

VXLAN Routing Script

Credit for esxcli to PowerCLI command conversion goes to Virten.net.

 

 


vCloud Director: Online Migration of Virtual Data Center – Part II

$
0
0

About two years ago I have written a blog post describing how service provider (with cloud based on vCloud Director) can replace hardware without tenants actually noticing this. The provider can stand up new vSphere cluster with new hardware and migrate whole Provider VDC to it with running virtual machines. In my mind this is one of the distinguishing features from other cloud management systems.

Recently I had an opportunity to test this in large environment with vCloud Director 5.5 and would like to report how it is even more simplified compared to vCloud Director 5.1 which the former post was based on. No more API calls are needed and everything can be done from vCloud Administrator GUI in the following five steps:

  1. Prepare new cluster and create new provider VDC on it.
  2. Merge it with the old provider VDC. Disable its resource pool(s).
    Merge PVDCs
  3. Migrate all VMs from the old resource pool to the new one in vCloud Director (not in vSphere!!!)
    Migrate VMs
  4. Redeploy all Edge Gateways running on the old hardware.
  5. Detach the old resource pool.
    Detaching Resource Pool

While the first 4 steps are identical as in vCloud Director 5.1 the step 5 is where the simplification is. The last step takes care of both migration of catalog templates and deletion of shadow VMs.

As before this is possible only with Elastic VDCs (Pay-As-You-Go or Elastic Allocation Pool).

 



Deploy 500 Edge Gateways in 500 Seconds

$
0
0

I am working on a few vCloud and NSX API scripts that collect data about Edge Gateways and needed to test how they work at scale. With this little PowerShell script leveraging NSX API I created 500 Edges in 500 seconds. And yes – I cheated as they were in undeployed state.

get-date
$NumberOfEdges = 500
$Username = "admin"
$Password = "default"
$NSXManager="nsx01.fojta.com"


$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$Request = "https://$NSXManager/api/4.0/edges"


$count=0
DO
{
$count++
$body = "
<edge>
	<datacenterMoid>datacenter-2</datacenterMoid>
	<name>$count</name>
	<description>TEST</description>
	<vnics>
		<vnic>
			<label>vNic_0</label>
			<name>vnic0</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>0</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_1</label>
			<name>vnic1</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>1</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_2</label>
			<name>vnic2</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>2</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_3</label>
			<name>vnic3</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>3</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_4</label>
			<name>vnic4</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>4</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_5</label>
			<name>vnic5</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>5</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_6</label>
			<name>vnic6</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>6</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_7</label>
			<name>vnic7</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>7</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_8</label>
			<name>vnic8</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>8</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_9</label>
			<name>vnic9</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>9</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
	</vnics>
	<appliances>
		<deployAppliances>false</deployAppliances>
	</appliances>
</edge>"

$Response = Invoke-WebRequest -Uri $Request -Method 'Post' -Headers $head -ContentType "application/xml" -Body $body
Write-Host -NoNewline "#";
} Until ($count -ge $NumberOfEdges)
Write-Host
Write-Host "I have created $count Edges"
get-date

500 Edges in 500s

Well and you probably do not want to delete them by hand either.

Get-Date
$Username = "admin"
$Password = "default"
$NSXManager="nsx01.fojta.com"

$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$Request = "https://$NSXManager/api/3.0/edges"

$r = Invoke-WebRequest -Uri ($Request+"?startIndex=0&pageSize=1000") -Headers $head -ContentType "application/xml" -ErrorAction:Stop

foreach ($Edge in ([xml]$r.content).pagedEdgeList.edgePage.edgeSummary)
{
$edgeId = $Edge.objectId
If ($Edge.description -eq "TEST")
	{
	$count++
	$Response = Invoke-WebRequest -Uri ($Request+"/"+$edgeId) -Method 'Delete' -Headers $head -ContentType "application/xml"
	Write-Host Deleting Edge $edgeId
	}
}
Write-Host
Write-Host "I have deleted $count Edges"
Get-Date

Note: You need at least PowerShell 3.0.


How to Monitor Health of NSX Edge Gateways

$
0
0

NSX Edge Service Gateways are virtual machines deployed by NSX Manager that provide network services (routing, bridging, load balancing, VPNs, DNS relay, DHCP, …). This makes them quite a critical component in the infrastructure and thus there might be a need to keep a close eye on their availability.

While NSX Manager reports the status of the Edges in the GUI and logs it might take some time to register a change in the health. If you want up-to-date status of an Edge health you need to query the NSX Manager with NSX API. The NSX Manager then retrieves the current status of the Edge. The mechanism of the communication between NSX Manager and Edge appliance(s) depends on the Edge version and the vSphere cluster status:

VIX Communication

This is the legacy mode of communication. NSX Manager utilizes VIX API to query vCenter Server and the ESXi Host which runs the Edge appliance who then via VM Tools talks to the actual VM. This mode of communication is used for the legacy Edges version 5.5.x (deployed via  the compatibility vShield v2 API) and as failback mode when for some reason Message Bus Communication mode is not possible.

 

Message Bus Communication

This is direct (and faster) communication between NSX Manager and the ESXi host (vsfwd process) running the Edge appliance. During the Edge deployment the cluster where the Edge is deployed to must be prepared for NSX and without any issues.

Message Bus

source: NSXvSphereDesignGuidev2.1.pdf

 

To query the Edge health is an expensive operation – it takes time and creates load on NSX Manager. If there is large number of Edges (for example in service provider scenario) this should be considered.

To test the viability of checking at least once in a given time the status of all Edges health I have created simple Powershell function Get-NSXEdgeHealth:

function Get-NSXEdgeHealth {
<#
.SYNOPSIS Gathers Health Status of a NSX Edge
.DESCRIPTION Will query NSX Manager for the health of a particular NSX Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
ID of the Edge to gather health data for.
.EXAMPLE
PS> Get-NSXEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/3.0/edges"+"/"+$EdgeId+"/status"

$h = @{} | select Health, Detail

$r = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$rxml = $r.Content
$h.Health = $rxml.edgeStatus.edgeStatus
$Details = @()
foreach ($Feature in $rxml.edgeStatus.featureStatuses.featureStatus)
{
$n = @{} | select Service, Status
$n.Service = $Feature.service
$n.Status = $Feature.status
$Details += $n
}
$h.Detail = $Details

return ,$h

} # End of process

PowerShell 3.0 or higher and (at least audit) credentials (and connectivity) to NSX Manager are needed.

Usage example:

Example

 

As can be seen the function needs the Edge ID parameter and then returns the overall Edge health and also detailed status of all its network services.

Following health states are defined:

  • green – good. This is the only state that guarantees that the Edge is functional.
  • red – no backing appliance is in service state
  • grey – unknown status (for example undeployed Edge)
  • yellow – intermittent health check failures (if more than 5 consecutive health checks fail the status goes to red)

Following function Get-NSXEdges will collect all Edges in the environment:

function Get-NSXEdges {
<#
.SYNOPSIS Gathers NSX Edges from NSX Manager
.DESCRIPTION Will inventory all of your NSX Edges from NSX Manager
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.EXAMPLE
PS> Get-NSXEdges -NSXManager nsxmgr.fqdn -Username admin -Password password
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password
)

Process {
### Ignore TLS/SSL errors
add-type @"cd
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
### Connect to NSX Manager via API
$Request = "https://$NSXManager/api/3.0/edges"
$r = Invoke-WebRequest -Uri ($Request+"?startIndex=0&pageSize=1") -Headers $head -ContentType "application/xml" -ErrorAction:Stop
$TotalCount = ([xml]$r).pagedEdgeList.edgePage.pagingInfo.totalCount

$r = Invoke-WebRequest -Uri ($Request+"?startIndex=0&pageSize="+$TotalCount) -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$rxml = $r.Content

### Return the NSX Edges

$Edges = @()

foreach ($EdgeSummary in $rxml.pagedEdgeList.edgePage.edgeSummary)
{
$n = @{} | select Name,Id
$n.Name = $edgeSummary.Name
$n.Id = $edgeSummary.objectId
$Edges += $n
}
return ,$Edges

} # End of process

} # End of function

And here is a sample script leveraging both functions above that continuously displays health status of all the Edges in the environment and also displays the time needed to go through all of them.

$NSXManager = "nsx01.fojta.com"
$Username = "admin"
$Password = "default"

$AllEdges = Get-NSXEdges -NSXManager $NSXManager -Username $Username -Password $Password

DO
{
$StartTime = get-date
foreach ($Edge in $AllEdges)
{
$Health = Get-NSXEdgeHealth -NSXManager $NSXManager -Username $Username -Password $Password -EdgeId $Edge.Id
Write-Host $Edge.Name $Health.Health
}
$Duration = (get-date) - $StartTime
Write-Host
Write-Host "Duration:" $Duration.Minutes "Minutes" $Duration.Seconds "Seconds"
Write-Host
} While ($true)

In my lab it took at least cca 2 seconds to get status of an Edge (depending on the mode of communication and its actual health). It is obvious that most time NSX Manager spends on communication with the ESXi host – so the task should and can be parallelized. While running 5 sessions at the same time the retrieval of health status of one Edge went up to 3-4 seconds (for a green Edge) while the load on NSX Manager went up 14 % (I run NSX Manager only with 2 vCPUs in my lab).

Monitoring

While the article mentions only NSX the scripts should work also with vShield / vCloud Networking and Security Manager.


My New Role at VMware

$
0
0

After almost 4 years working for professional services at VMware I am transferring to new Architect role in Global Cloud Practice – vCloud Air Network. I am taking up the challenge to work in a global team of cloud architects with half of them VCDX certified which will support the largest vCloud Air Network Service Provider partners.

During my PSO days as Consulting Architect I was consulting, designing and implementing private and public clouds for global, large and also smaller customers all over Europe with most of them in German-speaking countries. Whenever I encountered an interesting problem I blogged about it on this blog and recently the most often topics blogged about were about vCloud Director and NSX.

So I feel it is a perfect fit for me that In the new role I will specialize on public cloud only for handful of large SPs which means you can expect more articles about vCloud Director and NSX :-).

Stay tuned…


Renaming Edge Gateway

$
0
0

Recently one of my customers changed naming convention of vCloud Director Edge Gateways. He renamed them in vCloud Director however the names of virtual machines backing the Edge Gateways stayed the same. Also the names in vShield Manager or NSX Manager did not change. He quickly found out that there is no way to change the name in the GUI of vShield/NSX Manager. This is unfortunate especially for troubleshooting purposes.

Just today I saw the same question internally on our mailing list and the answer is that you can rename the Edge via API. Just GET the particular edge configuration and PUT it back with the changed name. As I recently wrote Powershell scripts that leveraged NSX API I quckly modified it and created two functions – RenameEdgeV5 and RenameEdgeV6.

They both rename the Edge, however only the first one works with vShield Manager. When using NSX Manager you have to use the one that matches the Edge version. The legacy Edges deployed by vCloud Director are version 5. The new NSX Edges are version 6. The API calls to retrieve the Edge info and change it are very similar one uses api 3.0 the other api 4.0.

Here are the scripts:

function RenameEdgeV5 {
<#
.SYNOPSIS Renames vShield Edge
.DESCRIPTION Renames vShield or NSX legacy v5 Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your vShield or NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
.EXAMPLE
PS> RenameEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId -Name newname
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId,
[Parameter(Mandatory=$true)]
[String]$Name
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/3.0/edges"+"/"+$EdgeId
$s = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $s.Content
$sxml.edge.name = $Name
$r = Invoke-WebRequest -Uri $HealthRequest -Method Put -Headers $head -ContentType "application/xml" -Body $sxml.OuterXML -ErrorAction:Stop

return $r.StatusCode
function RenameEdgeV6 {
<#
.SYNOPSIS Renames NSX Edge
.DESCRIPTION Renames NSX Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
.EXAMPLE
PS> RenameEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId -Name newname
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId,
[Parameter(Mandatory=$true)]
[String]$Name
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/4.0/edges"+"/"+$EdgeId
$s = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $s.Content
$sxml.edge.name = $Name
$r = Invoke-WebRequest -Uri $HealthRequest -Method Put -Headers $head -ContentType "application/xml" -Body $sxml.OuterXML -ErrorAction:Stop

return $r.StatusCode

} # End of process

} # End of function

Usage example:Usage

vSphere Client recent task activity:
Recent Tasks

 

And NSX Manager Edge Gateway view.RenamedEdges


Custom vCenter Server Event and Alarm

$
0
0

Related to my previous post about monitoring Edge Gateways my customer asked me if he could leverage vCenter Server alarms as they are integrated with their monitoring and alerting infrastructure.

So basically is there a way to create vCenter alarm via scripted action (for example with PowerCLI)?

The answer is yes and it is not that difficult. There are two types of vCenter alarms: based on condition/state or an event. And it is possible to create custom user event via Loguserevent method of entity manager via vSphere API.

This is example of PowerCLI code the creates user event “Edge Gateway event” at the root datacenter folder.

$DCFolderEntity = Get-Folder -Name datacenters
$eventMgr = Get-View EventManager
$eventMgr.LogUserEvent($entity.ExtensionData.MoRef,"Edge Gateway event")

User logged event

Now it is easy to create custom alarm based on the user logged event. Create the alarm at the vCenter Server root level, as alarm type pick monitor vCenter Server and as triggers manually enter (type):

Event; vim.event.GeneralUserEvent 

That’s it.

Alarm


Viewing all 242 articles
Browse latest View live