Learning NSX-Part-8-Installing Distributed Logical Router

In last post of this series we discussed about distributed logical router and went through some important terms and terminologies. In this post we will jump into lab and will deploy logical distributed router.

If you have missed earlier posts of this series, you can read them from below links:

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

6: Logical Switching

7: Distributed Logical Router Tidbits

Before jumping into deploying distributed router, I want to stress on the fact that your logical switches be ready. What i mean here since you wanna test routing between 2 or more different subnets, you should have logical switches ready in place and should have some live VM’s attached to it.

In my lab I have 3 logical switches created for this purpose.

dlr-0

Lets jump into lab now.

1: To Deploy Logical Router login to vSphere Web Client and navigate to Networking & Security -> NSX Edges .Click on ‘+’ to add NSX Logical router.

dlr-1

2: On the New NSX Edge page, select Logical Router option and provide a name,hostname and sweet little description description. If you want your edges highly available, select the checkbox that says “Enable High Availability”. Hit Next to continue.

dlr-2

3: Supply the admin password and set the log level to emergency (if you dont want disk space of your edge appliance getting filled quickly)

I like doing things over ssh, so I have enabled SSH on my edge appliance which will be deployed. Hit next.

dlr-3

Note: If password for your edge appliance is contains less than 12 characters, then you are going to get below warning.

dlr-4

4: On configure deployment page, select the virtual datacenter where LDR will be deployed.

Click on green ‘+’ button which says NSX edge appliances. This will deploy DLR Control VM.

dlr-5

5: Specify the Cluster, Datastore, Host and Folder to deploy the DLR Control VM and hit ok.

dlr-6

6: On the Configure interfaces page, click the select button.

dlr-7

It will open a new window from where you can select the management network for the edge interface.

A note about Management Interface Configuration

Management Interface is not a LIF, it’s local to the Control VM and does not require an IP address assigned and even if you configure one you wouldn’t be able to reach it via a routing protocol because there’s Reverse Path Forwarding (RPF) enabled.

dlr-8

It should look like as shown below. Click on “Configure interface of this NSX Edge” to define your LIF’s.

dlr-10.PNG

7: On the Add Interface dialog box, Enter the name of Interface, Select Type, Click Select Link for Connected To: and choose the desired Logical Switch and OK.

dlr-11

Select the logical switch to which your LIF will connect to.

dlr-12

After selecting the logical switch with which this LIF will connect to, we have to define IP address and subnet mask for the LIF.

dlr-13

Using the ‘+’ symbol repeat the wizard until you have created all the LIFs required in your environment.

dlr-14

8: Next and optional, configure a default gateway for the DLR. This typically would be the EGW ip address.

dlr-15

9: On ready to complete page, review your settings and hit finish to start deploying the DLR.

dlr-16

10: Post deployment of DLR, if you navigate to VM and templates view, you will see 2 VM’s deployed (as I chose HA option during deployment). One of these VM will be in active mode and other in standby mode.

dlr-17.PNG

Also if you click on NSX edges under Networking and Security, you will se ethe newly created edge listed there.

dlr-17-1.PNG

Double click on the edge and navigate to Manage > Configuration tab, and you can verify from here as well that 2 control VM’s are deployed and one of em is currently active.

You will also find options like changing the edge size from compact to Large or Quad Large, option to define syslog server where edge will route all the logs and option to change HA configuration.

dlr-19.PNG

11: On VM and Templates select Logical Router and select Summary tab. Here you will see all the IP’s assigned on your edge VM.

dlr-18

DLR deployment verification steps:

1:  Check DLR instance

From NSX Controller run

show control-cluster logical-routers instance all

This commands shows all the dLR instances and the corresponding hosts (VTEPs) that have joined. This command is very useful when something like routes are not propagated from the Control VM to the hosts.

dlr-20

2: Check Routing Table on ESXi host.

From ESXi, find the DLR name with the command

net-vdr -l -I

dlr-21

3: Check the routing table installed on the host coming from that dLR

net-vdr -l --route default+edge-1

dlr-22

4: On NSX Controller run following commands to see info about MAC Table/ARP table

show control-cluster logical-switches vni 5000 show control-cluster logical-switches mac-table 5001 show control-cluster logical-switches arp-table 5001

dlr-23

Note: In my lab ARP table/Mac Table returns as empty because I dont have any running VM’s connected to my logical switch yet.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX | 2 Comments

Learning NSX-Part-7-Distributed Logical Router Tidbits

In last post of this series we discussed about Logical Switching and understood when do we use logical switching. Also we deployed our first logical switch and moved a VM over to the newly created switch.

In this post we will discuss about Distributed Logical Router and look at the terms and terminology associated with it. We will not be diving into lab in this post as I intend to this in next post of this series

If you have missed earlier posts of this series, you can read them from below links:

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

6: Logical Switching

Overview

Physical Routers are the building block of any network infrastructure. They are essential for building a working network topology. As we know Routers comes into picture when we need communication between 2 different subnets. The problem with physical networking was that the topology becomes more and more complex as infrastructure is scaled out and the network devices had to process a lot of East-West and North-South traffic.

SDN  has simplified the networking and helped in breaking the silos of traditional physical networking. As we need routers in physical environments, we need to have similar capabilities in virtual networking world also.

With VMware NSX-v Routing between IP subnets can be performed in a logical space without traffic going out to the physical router. This routing is performed in the hypervisor kernel with a minimal CPU and memory overhead. This functionality provides an optimal data-path for routing traffic within the virtual infrastructure.

What is a DLR?

The Distributed Logical Router, or DLR, does what it says, it routes: it’s a router.

Like traditional routers, we can configure and use routing protocols such OSPF, IS-IS & BGP. DLR also provides a very cool feature known as “Layer 2 bridging”, which allows NSX VXLAN Logical Switch port group to talk to the regular VLAN out there on physical switch.

Distributed routing provides an optimized and scalable way of handling East – West traffic within a data center. If you are not familiar with what is East – West traffic, then it is the traffic which originates when virtual machines within a datacenter talk to each other. As virtualization has grown over time, virtual machines had replaced the physical servers and thus the amount of East–West traffic in the datacenter is growing.

In a vSphere environment virtual machines that are connected to different subnets (portgroups) want to communicate with each other, the communication between these VM’s has to go via physical adapter connected to the Esxi host to the physical switch and then it traverse to physical router which in turn does the routing and routes packets accordingly. The packets then follow the reverse path and reaches to destination VM. This non optimal flow of packet is referred to as “hair-pinning”

Distributed Router in VMware NSX prevents “hair pinning” by providing hypervisor level routing. Each hypervisor has a routing kernel module that performs routing between the logical interfaces (LIFs). We will discuss about LIF’s shortly.

Components of DLR

A DLR consists of following components:

  • Data plane : Data plane is kernel module installed on each vSphere host. DLR get installed on vSphere hosts along with VXLAN and DFW modules when we prep it ( we have done this activity in previous post of this series.
  • Control Plane : Control plane is made up of virtual machines running as what we call as Logical Router Controller or LRC. Every time Distributed Router is deployed, a “Control VM” is deployed alongside.
  • LRC VM’s are the supervisor Module. They are responsible for doing the routing updates, pairing or neighbor relationship with Edge service gateways or other physical routers and then it passes that information to NSX controllers and down to the vSphere hosts. Controller VM’s are not in data plane and data continues to flow even if controller vm’s are down, but you will not get routing updates or changes. When no control VM is available, packets are routed with last known configuration.
  • Management Plane : The management plane for Distributed Logical Routers is, like every other NSX component, part of the vSphere Web Client. You’ll find everything you need to configure and manage your Distributed Router Instances under the NSX Edges tab.

Logical Interfaces (LIF’s)

The distributed logical router possess and manage the logical interfaces (LIF’s). The LIF concept is similar to VLAN interfaces on a physical router. A DLR can have a maximum of 1,000 LIF’s. We discussed above that the routing kernel module present on each vSphere host performs routing between the LIFs.

When the LIF is connected to a VLAN, the LIF has a pMAC and when the LIF is connected to a VXLAN, the LIF has a vMAC.

dlr2

Where does DLR fit in to NSX infrastructure?

The recommended use case for Distributed Logical Routers is East-West traffic. We already discussed above what is a East-West traffic. DLR helps in reducing East-West traffic as each vSphere host is capable of doing L3 routing and thus virtual machine communication traffic do not need to go out to physical router to get routed.

For handling North-South traffic (traffic that leaves your virtual infrastructure or datacenter),VMware recommendation is to use Edge Service Gateways. The main benefit of using Distributed Routers is to take advantage of the optimized data path that network takes when routed by a DLR. Using DLR’s you can avoid “hairpinning” problems and thus can achieve a low packet transit time and saves network bandwidth.

Below diagram taken from a cisco UCS environments explains how NSX reduces East-west or North-South traffic.

DLR4.png

For a deep-dive on different use cases for DLR or other NSX architecture related knowledge, have a look on this awesome document from VMware: Architecting-a-VMware-NSX-Solution

The below diagram gives a high level overview of how DLR fits into your infrastructure.

dlr3

DLR Interfaces type

In DLR we have three types of interfaces. These are called Uplink, LIFs and Management.

Uplink: This connects the DLR Control VM to the upstream router. In some documents you will see that uplink is also referred to as “transit”, and this interface is the transit interface between the logical space to the physical space. The DLR supports both OSPF and BGP on its Uplink Interface, but cannot run both at the same time. We can only enable OSPF on a single Uplink Interface.

LIFs: LIFs exist on the ESXi host at the kernel level; LIFs are the Layer 3 interface that act as the default gateway for all VM’s connected to logical switches.

Management: DLR management interface can be used for different purposes. The first one is to manage the DLR control VM remote access like SSH. Another use case is for High Availability. The last one is to send out syslog information to a syslog server.

The management interface is part of the routing table of the control VM; there is no separate routing table. When we configure an IP address for the management interface only devices on the same subnet as the Management subnet will be able to reach the DLR Control VM management IP, and the remote device will not be able to contact this IP.

The below image is diagrammatic explanation of above.

dlr2-1

 DLR Interfaces Type

I will wrap my post here else it will be a super large boring post, but believe me world of DLR has not finished yet. A lot of things about DLR is yet to cover, but instead of writing up everything here, I would recommend reading below articles from fine gentlemens.

1: How Distributed Routing or DLR works by Joseph Griffiths

2: A deep dive into NSX Distributed Routing by Roie Ben Haim

3: Distributed virtual and physical routing in VMware NSX for vSphere by Brad Hedlund

In next post of this series we will deploy a DLR and see how to configure it. Stay Tuned!!!

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX, Vmware | 4 Comments

Delete Stale Org Networks and Edge Gateway from vCloud Director

Today while working in production, I came across an issue where the edge VM’s backing the edge gateway were not present in vCenter (no idea how they got deleted). Due to this I was not able to delete the Org network from vCD. Any attempt to delete the Org network was failing with error


[ f3fcd1fd-cf1c-4a57-a920-504204dceba7 ] Cannot delete organization VDC network DMZ (0dff6592-df7c-4e02-a106-5f0ed722d601)
Cannot update edge gateway "urn:uuid:f41b9f5a-0389-4781-ae0d-4b9cd19e9756"

java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- Cannot update edge gateway "urn:uuid:f41b9f5a-0389-4781-ae0d-4b9cd19e9756"
java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

This is what I was seeing in vCloud Director

1.PNG

On further investigation I found that the virtual wires associated with the problematic network were present in vCenter but on selecting the virtual machine tab for the virtualwire (distributed portgroup), I was not seeing any VM connected. Typically an edge VM should appear in the list.

That is when I found that edge VM’s were gone from vCenter.

Tried to re-deploy edge gateway and it also failed. Got same error about edge VM’s not being present


[ 8580da07-1ce4-440f-b126-0e5c8cca6e3e ] Cannot redeploy edge gateway XYZ (urn:uuid:f41b9f5a-0389-4781-ae0d-4b9cd19e9756)
com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

In this situation there is nothing much you can do. You need to hack your VCD DB and remove the stale entries from the database which would cause those entries to disappear from vCD UI.

First of all delete all virtual wires corresponding  to the stale Org network from vCenter.

Secondly you need to analyze the database to look into the tables where info about those Org networks is stored. Typically you have to  use following queries:

1: Find Org vDC ID where your stale networks exists

select id ,vdc_id ,name FROM vdc_logical_resource where lr_type= ‘NETWORK’ AND name = ‘Org_nw_name’;

Output (Assuming your org network name is ABC)

id       vdc_id   name
0xAAAAAA 0xBBBBBB ABC

2: List all Org Networks in your Org VDC (In case you have more than one stale network)

Select id, name from vdc_logical_resource where vdc_id = 0xBBBBB AND lr_type = ‘NETWORK’;

In this example I am assuming that you have 3 stale Org network namely ABC,DEF and XYZ

id        name
0xAAAAAAA  ABC
0xNNNNNNN  DEF
0xTTTTTTT  XYZ

Note: In case you have several org networks associated with your edge gateway but there is only one problematic (stale) org network, then you can modify the above query as shown below.

Select id, name from vdc_logical_resource where vdc_id = 0xBBBBB  lr_type = ‘NETWORK’ AND name = ‘Org_nw_name’;

This query will specifically return record of the stale network and thus will prevent accidental deletion of any healthy org network

3: Find Logical network id and gateway id

select display_name, id, gateway_id, logical_network_id from gateway_interface where display_name = ‘ABC’;

display_name       id       gateway_id   logical_network_id
ABC             0xF41B9F      0x8EEB1C       0x9FCD1Y

4: Query for link_lnet_id

select id,link_lnet_id FROM logical_network WHERE name = ‘ABC’

id                                  link_lnet_id
0x8EEB1C757916483893A633FF3E459ECE  NULL

Once you have all the information in place, use following delete queries to remove the records of the stale networks from vCD UI

delete FROM vdc_logical_resource WHERE id = 0xAAAAAAA;

delete FROM gateway_assigned_ip WHERE gateway_interface_id = 0xF41B9F;

delete FROM gateway_interface WHERE logical_network_id = 0x9FCD1Y;

delete FROM logical_network WHERE name = ‘ABC’;

Once you have deleted all stale networks and intend to delete edge gateway as well, you can do so by firing the below query

delete FROM gateway WHERE id = Edge_gw_id;

Example:

delete FROM gateway WHERE id = 0xF41B9F5A03894781AE0D4B9CD19E9756;

Posted in vCloud Director | Leave a comment

Learning NSX-Part-6-Logical Switching and Transport Zones

In last post of this series we briefly looked what is VXLAN (In actual it’s an ocean of knowledge in itself) and also we configured VXLAN on our cluster/hosts.

In this post we will be talking about Logical switching and we will see how to create that and will cover prerequisites part as well.

If you have missed earlier posts of this series, you can read them from below links:

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

Let’s start with introduction to Logical Switching.

What is Logical Switching?

Functionality of a Logical switch is very similar to that of a physical switch i.e they allow isolation of applications and tenants for security purpose. A logical switch when deployed, creates a broadcast domain to allow isolation of the VM’s running in infrastructure.

Logical switches provides you with capability of creating VLAN’s (similar to in physical world) and these VLAN’s not only provides isolation but can also span across large compute clusters.

The logical switch is mapped to a VXLAN that encapsulates the traffic going over physical network.

Logical switches can be created as either local or as universal (which can span  across vCenter’s in a cross-vCenter NSX deployment architecture). Universal logical switch can aid you with capability of extending your VXLAN across two different sites.

Why logical switching?

To answer this question I am not gonna include a long paragraph with complex networking terms. Instead I will ask a simple question that inn a physical networking world why VLAN?

A cloud service provider or any organization can have multiple tenants running in their data center. In a public cloud environment a tenant can simply be referred as a customer while in an organization tenant can be the different departments of that organization.

Now these tenants are running their business critical applications deployed inside the VM’s running on top of virtualization stack and are sharing same piece of infrastructure (compute, storage and network).

Now the question arises how to stop each tenant from sneaking into other tenant’s VM or applications. These tenants require isolation from each other for various reason including security, fault isolation, and avoiding overlapping IP addressing issues.

So to solve the above problem we use logical switching.

Prerequisites for creating a Logical Switch

Before you go and start creating logical switches in your environment, you have to make sure you meet following requirements:

  • vSphere distributed switches must be configured. You cannot deploy logical switches on standard switches.
  • NSX controllers must be deployed.
  • Your compute host clusters must be prepared and ready to go.
  • VXLAN must be configured.
  • A Transport Zone and a segment ID pool must be configured.

In our last post covered all the above requirements. So let’s jump into lab and start creating logical switches.

To start creating Logical Switch, Login to your vCenter server Web Client and navigate to Home | Networking & Security | Logical Switches

Click on the green “+” button to start creating a new Logical Switch

ls-1

2. Provide a name and nice little description for your logical switch. Select the transport zone to which this logical switch will be mapped.

Also select the replication mode for the logical switch.

Note:

By default, the logical switch inherits the control plane replication mode set in the Transport Zone. You can change this by selecting one of the available modes.

IP discovery is enabled by default and allows Address Resolution Protocol (ARP) suppression between VMs connected to the same logical switch. There should not be any reason to disable this (optional).

Enable MAC learning setting if your virtual machines are having multiple MAC addresses or using virtual NICs that are trunking VLANs. This setting builds a VLAN/MAC pairing table on each vNIC.

ls-2

3. When you create a logical switch, a new dPortGroup is created on the vDS. You can verify this by going into your network inventory and checking the presence of the newly created portgroup.

ls-3

Migrating VM’s to Logical Switch

Once logical switch is created, we can migrate the workloads onto this switch. There are 2 methods of doing this.

A: Go to  Networking & Security | Logical Switches and clicking on the VM icon as shown in figure. This method will allow to migrate multiple VM’s at once from their current network (portgroup) to the logical switch.

ls-4.PNG

The second method is rather long and needs going VM by VM basis and edit their settings and changed the portgroup association of the vNIC.

Select the VM’s from the list and click on the blue arrow button to add them to selection window and hit next.

ls-5

ls-6

On vNIC selection page, select the vNIC’s (in case your VM has more than one vNIC) for which you want to change portgroup association and hit next. In my case all my VM was equipped with one vNIC.

ls-7

On ready to complete page review your settings and hit Finish to complete logical switch creation wizard.

ls-8

You can verify the change of portgroup association by selecting the VM and go to Manage > VM hardware tab.

ls-9

So now we have created our logical switch and migrated a few VM’s on that. In next post of this series we will learn about Distributed Logical Router.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

 

Posted in NSX, Vmware | 6 Comments

Learning NSX-Part-5-Configure VXLAN on the ESXi Hosts

In last post of this series we saw how to prepare Esxi host and Cluster for NSX. In this post we will be talking little bit about VXLAN, what are its benefits and how to configure VXLAN on Esxi hosts.

If you have missed earlier posts of this series you can read them from here:

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

Lets start our discussion with what is VXLAN.

Virtual Extensible LAN (VXLAN) is an encapsulation protocol for running an overlay network on existing Layer 3 infrastructure. An overlay network is a virtual network that is built on top of existing network Layer 2 and Layer 3 technologies to support elastic compute architectures.

In VXLAN the original layer 2 frame is encapsulated in a User Datagram Protocol (UDP) packet and delivered over a transport network. This technology provides the ability to extend layer 2 networks across layer 3 boundaries and consume capacity across clusters.

Why we should use VXLAN?

VXLAN enables you to create a logical network for your virtual machines across different networks. You can create a layer 2 network on top of your layer 3 networks.

If you are from networking background then you are aware that the traditional VLAN identifiers are 12-bits long—this naming limits networks to 4094 VLANs. If you are a cloud service provider, then it is likely to happen that you are going to hit this limit in nearby future as your environment grows.

The primary goal of VXLAN is to extend the virtual LAN (VLAN) address space by adding a 24-bit segment ID and increasing the number of available IDs to 16 million. The VXLAN segment ID in each frame differentiates individual logical networks so millions of isolated Layer 2 VXLAN networks can co-exist on a common Layer 3 infrastructure. As with VLANs, only virtual machines (VMs) within the same logical network can communicate with each other.

VXLAN Benefits?

  1. You can theoretically create as many as 16 million VXLANs in an administrative domain.
  2. You can enable migration of virtual machines between servers that exist in separate Layer 2 domains by tunneling the traffic over Layer 3 networks. This functionality allows you to dynamically allocate resources within or between data centers without being constrained by Layer 2 boundaries or being forced to create large or geographically stretched Layer 2 domains.

Since you have a bit of idea now about VXLAN, let’s jump into lab and see how to configure it on Esxi hosts.

VXLAN can be configured by logging into vCenter Web Client and navigating to Networking & Security > Installation > Host Preparation

You will see that VXLAN status is “Not Configured”. Click on that and a new wizard will open to configure VXLAN settings.

vxlan-1

Provide the following info to configure the VXLAN Networking.

  • Switch – Select the vDS from the drop-down for attaching the new VXLAN VMkernel interface.
  • VLAN – Enter the VLAN ID to use for VXLAN VMkernel interface. If you are not using and VLAN in your environment Enter “0″. It will pass traffic as untagged.
  • MTU – The recommended minimum value of MTU is 1600, which allows for the overhead incurred by VXLAN encapsulation.
  • VMKNic IP Addressing – You can specify either IP Pool or DHCP for IP addressing.

vxlan-2

If you have not created any IP Pool yet, then you can do so by selecting “New IP Pool” and a new wizard will be launched to create a new pool.

Provide a name for the pool and define the IP/Netmask/gateway/DNS etc along with Range of IP that will be used in this pool.

vxlan-3

Once you hit OK, you will return to the original window. Select the pool which you have just created.

Next setting is to select VMKNic teaming policy. This option is define the teaming policy used for bonding the physical NICs for use with the VTEP port group. The value of VTEP changes as you select the appropriate policy.

A very good read on various teaming policy available under NSX is explained here

I have left with the default Teaming policy to “Fail Over”. Hit OK once you are done with supplying all info.

vxlan-4

Now you will see VXLAN preparation on your cluster is started.

vxlan-5

Within a minute or so you will see that VXLAN status has been changed from busy to Configured.

vxlan-6

VXLAN configuration will create a new VMkernel port on each host in the cluster as the VXLAN Tunnel Endpoint (VTEP). You can verify this by selecting your host and navigating to Manage > Networking > VMkernel Adapters

vxlan-7

You can verify that IP allocated to these VMkernel interfaces are from your defined pool by clicking on Logical Network Preparation tab> VXLAN Transport.

vxlan-8

Next we need to Configure the VXLAN ID Pool to identify VXLAN networks:-

On the Logical Network Preparation tab, click the Segment ID button and Click Edit to open the Segment ID pool dialog box to configure ID Pool.

vxlan-9

Enter the Segment ID Pool and Click Ok to complete.

Note: VMware NSX™ VNI ID starts from 5000.

vxlan-10

Next task is to Configure a Global Transport Zone:-

A transport zone specifies the hosts and clusters that are associated with logical switches created in the zone. Hosts in a transport zone are automatically added to the logical switches that you create.

On the Logical Network Preparation tab, click Transport Zones and Click the green plus sign to open the New Transport Zone dialog box.

vxlan-11

Provide a name for the transport zone and select the Replication Mode as per your environment need.

A little note on Replication Mode

Unicast has no physical network requirements apart from the MTU. All traffic is replicated by the VTEPs. In NSX, the default mode of traffic replication is unicast.  Unicast has Higher overhead on the source VTEP and UTEP.

Multicast mode uses the VTEP as a proxy. In multicast, the VTEP never goes to the NSX Controller instance. As soon as the VTEP receives the broadcast traffic, the VTEP multicasts the traffic to all devices. Multicast has lowest overhead on the source VTEP.

Hybrid mode is not the default mode of operation in NSX for vSphere, but is important for larger scale operations. Also the configuration overhead or complexity of L2 IGMP is significantly lower than multicast routing.

vxlan-12

After clicking OK you will see the newly created Transport Zone

vxlan-13

We are done with configuring VXLAN on Esxi hosts here. In next post of this series we will learn about logical switching.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX, Vmware | 7 Comments

Learning NSX-Part-4-Preparing Esxi Hosts and Cluster

In previous posts of this series, we talked about NSX Manager and NSX Controllers Deployment and also validated NSX Control Cluster status.

If you have missed earlier posts of this series you can read them from here:

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

In this post we are going to learn about how to prepare Clusters and Esxi Hosts for NSX.

At this point we have NSX manager and controllers ready and established connection between control and management plane. Next step is to prepare cluster and Esxi hosts.

NSX installs three vSphere Installation Bundles (VIB) that enable NSX functionality to the host. One VIB enables the layer 2 VXLAN functionality, 2nd VIB enables the distributed router, and the 3rd VIB enables the distributed firewall. After adding the VIBs to a distributed switch, that distributed switch is called VMware NSX Virtual Switch.

Login to vCenter Server using vSphere Web Client and Navigate to Networking & Security > Installation > Host Preparation. Choose your cluster and click the Install link.

Once you click on install option, NSX will start installing the VIB’s on the Esxi hosts that are part of the cluster.

host-0

Give it a few seconds to install the VIB’s. Once installation is completed you can see Installation status as OK and also Firewall status as enabled.

host-1

At this point VXLAN is not configured and we will cover this part in next section.

Verify Status of NSX VIBs

You can verify the VIBs installation by logging onto Esxi hosts using ssh.

You can use following commands to check status of NSX VIBs

# esxcli software vib list | grep vxlan

# esxcli software vib list | grep vsip

host-2

You can also get detailed information about these VIBs by using command

# esxcli software vib get | less

You have to navigate through the output to search for vxlan and vsip VIBs info

host-3

host-4

Verifying NSX User World Agent (UWA) Status:

The user world agent (UWA) is composed of the netcpad and vsfwd daemons on the ESXi host. UWA Uses SSL to communicate with NSX Controller on the control plane. UWA Mediates between NSX Controller and the hypervisor kernel modules,except the distributed firewall. Communication related to NSX between the NSX Manager instance or the NSX Controller instances and the ESXi host happen through the UWA. UWA Retrieves information from NSX Manager through the message bus agent.

You can verify the status of User World agents (UWA) using the below command:

# /etc/init.d/netcpad status

host-6

On doing esxtop, we can verify the netcpa deamon is running

host-7.PNG

Post completion of Cluster Preparation, you can see the vxlan is loaded under custom stacks in TCP/IP configuration of the ESXi hosts.

host-5.PNG

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX, Vmware | 8 Comments

Learning NSX-Part-3-Deploying NSX Controllers

In last 2 posts of this series we understood what NSX is and how to install/configure NSX manager.

In this post we will be talking about NSX controllers. Before diving into lab, we will first discuss a little bit theory about NSX controllers and its importance.

NSX Controllers

NSX controllers are the control plane for NSX. They are deployed in a cluster arrangement, so as you deploy these, you can add more controllers for better performance and high availability so that if you loose one of em, you do not loose control functionality. These are important, if you loose enough of these, things stop working.

NSX controllers stores following tables:

1: MAC Table
2: ARP Table
3: VTEP Table

One or more VMkernel interfaces on each vSphere host for VXLAN functionality. NSX controller keep these tables and the reason is that you may have your NSX deployment spread over a big DC or multiple DC.

You may have your vSphere hosts and cluster spread over multiple layer 3 network, so as these VM’s or host need to talk to each other, because we overlay routing networks with what looks like single layer 2 adjacent VLAN’s for the VM’s, if they do things like ARP lookup table or MAC add lookup or you need to know the IP of the VTEP interface on other hosts, normally you will send out a broadcast.

But we dont want to broadcast the stuffs all over the place, so these controllers keep these tables and if a host need those, it will send a copy of these records and thus help in greatly reducing broadcast traffic that we want to get rid of.

NSX controllers considerations:

1: Deployed in odd numbers

Controllers uses a cluster and uses a voting quoram. They should be deployed in odd numbers and should be resilient. The min which you can deploy is 1 but 1 is not resilient and is not supported by VMware. (You can choose to deploy 1 controller in lab environments to test things).

If you have 3 node nsx controller cluster, it allows you to tolerate failure of 1 node. But if 2 goes down things would stop working. These clusters wants a voting majority. The idea here is that in case of a split brain or there is a segmentation and 2 controllers end up in one partition and other one in another partition, the side that has 2 controllers knows that they have majority as they started with 3 nodes and they can institute changes.

If you have only 2 nodes and they split into different partitions, they cant push any type of changes as both dont have majority. The max currently supported is 5.

2: Not in data path

But that doesn’t mean you allow all of them to fail. If you have a 3 node cluster and one of them fail, either fix it or deploy a new node so that you can always have voting majority available

3: Work is striped across the controllers using the concept of slices.

Controllers scale for both performance and availability. Slicing method is used to spread the workload. Every job is divided into slices and then its spread across available nodes. When a new controller is added or existing one fails, these slices can be redistributed.

This can be understood easily via below 2 pictures

In this picture there are 3 controllers and each one have been assigned a workload

slicing-1

Now controller 3 failed and workload are being shifted to available 2 controllers

slicing 2.PNG

NSX Controller Cluster Functions

NSX controllers mainly perform these 2 functions:

1: VXLAN functions

2: Distributed Router

An election is held to find out the master for each kind of roles. When a controller fails, a new election is held to promote a new controller as master.

Controllers are deployed by NSX manager. You dont need any kind of ova/ovf files for deploying these. Each deployed controller has 4 GB RAM and 4 vCPU by default.

We have talked enough of theory now. It’s time to jump into lab and see some action.

To deploy a new controller navigate to Installation section under Networking & Security and click on green ‘+‘ button

con-1

Type the name of the controller and select the Cluster/Resource Pool and datastore where you want to deploy the controller. Also in connected To option select the same layer 2 portgroup in which your NSX manager resides.

For IP Pool click on select

con-2

If you have not created any IP pool for the NSX controllers yet, do so by clicking on New IP Pool

con-3

 

Provide a name for the IP pool and Gateway, DNS and Prefix length (Netmask). Also define a pool of IP under Static IP Pool. It can be a continuous IP Range or comma separated if the IP’s are not continuous. Hit OK once you are done filling up the relevant entries.

con-4

Select the newly created pool and hit OK to continue.

con-5

At last type in the password for accessing controllers over SSH and hit OK to finish the wizard.

con-6

You will see that NSX manager is now deploying a new controller for you. Also in Recent Tasks pane you will see a task triggered for Deploying an OVF template.

con-7

Once the controller deployment is successful, you will see the status as connected. Now you can deploy additional controllers.

con-8

Again click on green ‘+’ button to spin up a new controller. Provide a name and necessary info and hit OK.

Note:- Password option will only appear for the First NSX Controller Node. For 2nd and 3rd node same Password will be used so there will not be password field.

con-9

I have deployed 3 controllers in my lab and all shows connected.

con-10

If you switch to Host and Cluster view in vCenter, you will see 3 VM’s deployed which corresponds to the 3 controllers.

con-11

Now let’s have a look on controller cluster status

NSX Control Cluster Status

Once you SSH to the controller, you can start asking some questions to them.

Say for example you can ask for the cluster status (How are you doing today buddy)

# show control-cluster status

con-12

You will see the output with controller stating that yea I am fine. My join status is complete. I am connected to cluster majority and I can be safely restarted. Here is my cluster ID and UUID. I am happy, I am activated and ready to go.

NSX Control Cluster Connection Status

To verify the Controller Node’s intra-cluster communication connections status we can use below command:

# show control-cluster connections

con-13

The master Controller listens on port 2878 (you can see “Y” in the “listening” column).The other Controller nodes will have a dash (-) in the “listening” column for Port 2878.

NSX Control Cluster Role Status

Next is to query about the controller role. You can ask the controller “Are you the one who is incharge here”. Are you the master of anything.

Below command can be used to query the role status

# show control-cluster roles

Below is the output from my 3 NSX controller node. Each controller node can be master for different role.

con-14.PNG

con-15

con-16

At this point we have NSX manager installed and NSX controllers deployed, so we have our management plane and control plane established. We are ready for the Host preparation and we will cover this part in our next post.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX | 11 Comments

Learning NSX-Part-2-Installing and Configuring NSX Manager

In last post of this series we had a look into what NSX is and how it fits in a software defined datacenter. We also had a look on core NSX components and discussed in brief about them.

In this post we will be talking about basic installation and configuration options of NSX manager.

NSX manager provides a centralized management plane across your datacenter. It provides the management UI and API for NSX. NSX manager runs as a virtual appliance on an ESXi host and during installation it injects a plugin into the vSphere Web Client through which it can be managed.Each NSX Manager manages a single vCenter Server environment.

There are few prerequisites that must be met before proceeding with installation of NSX manager. These are as follows:

1: vSphere infrastructure should be ready. At least there should be 2 cluster.

2: NSX can be managed only via vSphere Web Client . Make sure you have Web Client installed and ready to use.

3: For NSX 6.X , VMware vCenter Server 5.5 or later is recommended.

4: Make sure DNS and NTP servers are ready in your infrastructure. Also ensure all the components ESXi, vCenter and NSX Manager are in sync time with configured NTP servers. Also all name resolution should be working fine.

5: Ensure you have all the required System Resources (CPU and Memory) available in your cluster to deploy various NSX Components like NSX Manager, Controller,etc.

6: Ensure you have Configured your Distributed Switch to use Jumbo frames i.e. MTU 1600 or more.

Apart from that, NSX requires below ports for installation and daily operations:

  • 443 between the ESXi hosts, vCenter Server, and NSX Manager.
  • 443 between the REST client and NSX Manager.
  • TCP 902 and 903 between the vSphere Web Client and ESXi hosts.
  • TCP 80 and 443 to access the NSX Manager management user interface and initialize the vSphere and NSX Manager connection.
  • TCP 1234 Communication between ESXi Host and NSX Controller Clusters
  • TCP 22 for CLI troubleshooting.

The NSX Manager virtual machine is packaged as an Open Virtualization Appliance (OVA) file, which allows you to use the vSphere Web Client to import the NSX Manager into the datastore and virtual machine inventory. VMware NSX can be downloaded from Here

nsx-dl

Once NSX manager ova file is downloaded, we can start installation which is just a very straight forward process of deploying any other ova file.

nsx-01

Verify OVF template details and hit Next.

nsx-02.PNG

Accept EULA and hit Next.

nsx-03

Provide a name for your NSX manager and hit Next.

nsx-04

Select the cluster where you need to deploy the NSX manager and hit Next.

nsx-05

Select appropriate datastore for your installation and proceed.

nsx-06

If you are testing NSX manager in lab, you can go for thin provisioned scheme. In production it is recommended to go for thick provision deployment scheme.

nsx-07

Map the appropriate network for NSX manager management interface.

nsx-08

On the properties page, provide the password and the IP/Netmask information etc.

nsx-09

Once you have finished configuring all the installation options, power on the VM after deployment. If you launch console of the NSX manager at this moment, you will see the booting process which looks very similar to any other VMware appliance.

nsx-10

Once NSX manager boot process is complete, it can be accessed via https://<NSX FQDN>/login.jsp

nsx-11

At this point we have successfully installed NSX manager. Let’s configure it now.

Once you logged in NSX manager admin console, click on Manage Appliance Settings.

nsx-12

 

Verify NTP settings. Change the Timezone as per your country.

nsx-13

Verify Network settings and provide if there is any missing info by clicking on Edit button.

nsx-14

Now click on NSX management Service to associate this NSX manager with a vCenter Server.

nsx-15

First configure Lookup Service URL. This is the URL to machine where your PSC is running.

Note that with vSphere 6, lookup service is running on port 443 and not on port 7444.

Provide the Lookup service host, port and SSO admin credentials to configure lookup service. Hit OK once you have filled all relevant fields

nsx-16

Accept the SSL certificate that is presented.

nsx-17

Next is to enter the vCenter details.

NOTE: If the SSO admin is being used to connect NSX to the vCenter, only the SSO admin will have access to the NSX section in the vCenter web client. If you do use the SSO admin to connect, but use a different user to connect to the web client, you will need to login to the web client using the SSO admin first and give the desired user the appropriate permissions to access NSX

nsx-18

Hit OK after entering the vCenter Server details and accept the SSL certificate.

nsx-19

Once both Lookup and vCenter information is provided in NSX Manager,You should be able to see the status as “Connected” with Green light for Lookup service and vCenter Server.

nsx-20

Now click on Summary page to verify all services are running on NSX manager.

nsx-21

We are done with basic NSX manager configuration here. We have to login to vSphere web-client to explore more about NSX.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX | 8 Comments

Learning NSX-Part-1-Introduction

VMware NSX is the network virtualization and security platform that emerged from VMware after they acquired Nicira in 2012. This acquisition launched VMware into the software-defined networking (SDN)  and network functions virtualization (NFV) world.

VMware NSX® is a software networking and security virtualization platform that delivers the operational model of a virtual machine for the network. Virtual networks reproduce the Layer2 – Layer7 network model in software, allowing complex multi-tier network topologies to be created and provisioned programmatically in seconds, without the need for additional SoftLayer Private Networks. NSX also provides a new model for network security. Security profiles are distributed to and enforced by virtual ports and move with virtual machines.

With VMware NSX, virtualization now delivers for networking what it has already delivered for compute and storage. NSX can be configured through the vSphere Web Client, a command line interface (CLI), and REST API.

NSX includes a library of logical networking services – logical switches, logical routers, logical firewalls, logical load balancers, logical VPN, and distributed security. You can create custom combinations of these services in isolated software-based virtual networks that support existing applications without modification, or deliver unique requirements for new application workloads.

Virtual networks are programmatically provisioned and managed independent of SoftLayer networking constructs. This decoupling from hardware introduces agility, speed, and operational efficiency that can transform datacenter operations. benefits of NSX include:

  • DataCenter automation
  • Self-Service Networking services
  • Rapid application deployment with automated network and service provisioning
  • Isolate dev, test, and production environments on the same SoftLayer Bare metal infrastructure
  • Single SoftLayer Account Multi-tenant clouds

 

NSX Architecture

An NSX-V deployment consists of a data plane, control plane and management plane:

nsx-1

NSX Core Components

The 2 Major components that make up NSX ecosystem are:

NSX Manager

NSX manager provides a centralized management plane across your datacenter. It provides the management UI and API for NSX. NSX manager runs as a virtual appliance on an ESXi host and during installation it injects a plugin into the vSphere Web Client through which it can be managed.Each NSX Manager manages a single vCenter Server environment.

Along with providing management APIs and a UI for administrators, the NSX Manager also installs a number of VIBs to the Esxi host when initiating host preparation. These VIB’s are VXLAN, Distributed Routing, Distributed Firewall and a user world agent.

The below diagram shows NSX Manager Components Plugin and Integration inside vSphere Web Client

nsx-2

NSX Controller

The NSX controller is a user space VM that is deployed by the NSX manager. It is one of the core components of NSX and could be termed as the “distributed hive mind” of NSX. It provides a control plane to distribute network information to hosts. They are deployed in a cluster arrangement, so as you deploy these, you can add more controllers for better performance and high availability so that if you loose one of em, you do not loose control functionality.

NSX is a very vast topic and we will cover the parts in upcoming post. There is a lot to discuss about core components and NSX services and we will touch upon them one by one. Till then stay tuned.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX | 9 Comments

Learning VSAN:Part-3- Storage Policies and VSAN

In our last 2 posts of this series we discussed about VSAN Architecture and walked through steps needed to configure VSAN. If you have missed earlier posts of this series you can read them from here:

1: Overview and Architecture of VSAN

2: Installation and Configuration

In this post we will discuss Storage Policies and its role in a vSAN environment.

Storage policy based management and implementation is an important part of software defined storage and software defined datacenter. VMware vSAN is one of the most robust and most complete implementation of storage policy based management.

When you use Virtual SAN, you can define virtual machine storage requirements, such as performance and availability, in the form of a policy. The policy requirements are then pushed down to the Virtual SAN layer when a virtual machine is being created. The virtual disk is distributed across the Virtual SAN datastore to meet the requirements.

When you enable Virtual SAN on a cluster, a single Virtual SAN datastore is created which represents all the storage in vSAN cluster. In addition, enabling Virtual SAN configures and registers Virtual SAN storage providers.

You can locate vSphere storage providers by navigating to vCenter server > Manage > Storage Providers

This is where we see a VASA enabled/capable disk array. With vSAN this is supposed to have automatically been done for each of the Esxi hosts that are part of vSAN cluster.

VM storage profiles allows for the capabilities of the underlying storage to be presented to administrators for easier assignment to virtual machines.

Note: if you are ruuning older version of vSAN, then there was a known bug where vCenter Server and vSAN cluster get out of sync causing VASA providers did not get created automatically. And becuase of that you cannot create storage policies. To remediate this you have to manually create the entries for the storage providers.

The process to create storage provider entries is fairly simple. Navigate to vCenter Server > Manage > Storage Providers.

Click on green + button and add the entries as below:

Name: Name for the storage provider

URL : http://esxi-fqdn:8080/version.xml

Username: root

Password: Password of root user on esxi host

vsan-1

In my case Storage Providers were already listed as I am using latest version of vSAN in my lab

vsan-2.PNG

Note: Only one of the providers will be active, and rest others will be standby.

vsan-4.PNG

If you select your storage providers and look into storage System details section, it will tell you that it is providing support for policy based management profile.

vsan-5.PNG

No Once you create storage providers, you can go ahead with creating storage policies

Before Proceeding with creation of new Storage Policies, lets understand the capabilities offered by vSAN first:

vSAN Storage Capabilities

vSAN storage capabilities can be divided into 5 major categories:

Number of failures to tolerate – This option allows admins to configure the number of failures to tolerate. A failure can be network, disk failure or host failure within the vSAN cluster. This value is important when design for the resiliency of your cluster.

Number of disk stripes per object – When designing for the performance of a specific VM or group of VMs you can determine if you need to allow for additional capacity by striping the data across additional disk spindles. By default the value is a single spindle. If a read or write cannot be handled from cache it will resort to the spindle, by using more than one it can increase performance as needed.

Flash read cache reservation – There is the option to explicitly reserve an amount of flash capacity on the SSD for read cache on a per object basis. This is configured as a percentage of the virtual machine disk.

Object space reservation – You can also reserve a percentage of the VM disk space on the hard drives during provisioning. This would be similar to thick provisioning on a standard datastore.

Force provisioning – If a policy is created with any of previous options and it vSAN cannot provide the service, this option will forcefully provision the VM. If the resources become available at a later time, vSAN will attempt to bring the VM back into compliance.

Let’s jump into creating storage policy now.

1: To create Storage Policies, navigate to vCenter Server home screen and click on VM Storage Policies

vsan-6.PNG

On the VM storage Policy page click on  icon icon to create a new policy.

On the Create New VM Storage Policy wizard page, provide a name and description for the policy and hit next.

vsan-8

Next is to create Rule Set.

In this example we are going to create a policy for high availability of a VM.

Click on <Add Rule> and select Number of failures to tolerate

Number of Failures to Tolerate indicates resiliency against host, network, or disk failures in the cluster. Increasing this number will cause VSAN to create copies of the object on additional hosts, up to 4 copies total that would allow for three concurrent failures without data loss

vsan-10.PNG

 

Click on Next to continue.

Select the compatible datastore from the list and hit Next.

vsan-11.PNG

On Ready to complete page, review your settings and hit Finish to close the wizard.

vsan-12.PNG

Select the newly created policy and click on Summary tab, you will see its shows 0 Non-Compliant VM’s, 0 Complaint VM’s and 0 unknown VM’s. This is because we have not applied this policy to any VM yet

vsan-13.PNG

Now since our policy has been created, let’s apply this policy to one of the VM.

To apply storage policy to the VM, select the VM and right click on it and select VM Policies > Edit VM Storage Policies

Change the VM storage policy from Datastore Default to one which your created (Tier-1 in our example) and hit OK

vsan-15

If you go to VM Storage Policies again and click on summary page, it will tell you the VM to which you applied the storage profile is compliant or not. IF you are seeing a non-complaint VM it means vSAN doesn’t support the capabilities defined by you in the storage profile.

vsan-111.PNG

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

 

Posted in VSAN | Leave a comment

Learning VSAN:Part-2-Installation and Configuration

In our last post Overview and Architecture of VSAN we learnt what vSAN is. Why one should use vSAN in their environment and what is the architecture of vSAN.

In this post we will look at how to install and configure VSAN in lab/production environment.

Note: I am using vSAN 6.X in my lab.

Installation Requirements:

VMware KB-2106708 list all the requirements for installing VSAN 6.X in a greater details. Here are the minimum requirements to build a VSAN Lab:

1: Minimum of 3 ESXi 6.0 host that will contribute to storage.

2:At least one SSD and one Hard Disk per host

3: VMkernel port configured for VSAN traffic

4: 1 GB network for small environment Lab/test (For Production VMware recommends 10GB)

vSAN uses Esxi hosts locally attached storage to create a clustered datastore. vSAN is a software feature which is built into the hypervisor (Esxi).

VSAN can be used in 2 mode: hybrid or all-flash.

In hybrid mode we need to associate at least one HDD and one SSD in each of the Esxi host participating in the vSAN cluster. The SSD typically don’t contribute to the storage capacity. The SSD are doing just read caching and write buffer. The aggregation of HDDs from each server in the vSAN cluster forms a vSAN datastore. SSD disks of the Esxi hosts is used as read cache and write buffer in front of the HDDs. The HDDs are there to assure the persistent storage.

The below diagram typically explains the hardware requirements for vSAN

vsan-hw

Lab Preparation

1: Make sure you have created Port Group for VSAN and configured appropriate uplink for this portgroup

vsan-1

2: Host should be associated with this portgroup

vsan-2.PNG

3: vSAN traffic allowed on VMkernel portgroup designated for vSAN

vsan-3-2

4: Make sure you have at least 3 esxi hosts in the cluster

vsan-3.PNG

5: Each Esxi host have at least one SSD and one normal HDD

vsan-3

6: Your infrastructure is licensed for vSAN

Note: if you are running Nested Esxi hosts in your lab, then check this Article by Vladan Seget on how to fake a disk as SSD disk.

Now it’s time to enable vSAN on our cluster.

Note: Disable HA on the cluster before enabling vSAN.

To enable vSAN on the cluster ,login to vSphere WebClient and Select Cluster > Manage > Virtual SAN > Genneral

A: Click on configure button to enable VSAN on cluster.

vsan-6

B: Select manual for Disk Claiming and hit Next.

vsan-7.PNG

C: On Network validation page, hit next if everything looks green.

vsan-8.PNG

D: Select Host on Group by option and select the individual disks from host for capacity Tier and cache Tier. Hit next after making your selection

vsan-9

E: On ready to complete page hit Finish to complete the installation wizard.

vsan-10

With this installation of vSAN has been completed. We will explore vSAN more in upcoming posts of this series.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in VSAN | 3 Comments

Learning VSAN:Part-1-Overview and Architecture of VSAN

This week a new program “VSAN vExpert” was launched for vExpert’s and I was all excited to be a part of the VSAN vexpert community. I was thinking about learning VSAN since a while but due to time constraints I was not able to do so. Launch of this vExpert program provided me an opportunity to finally test my hands on highly talked VSAN.

Lets begin with Introduction of VSAN and we will look into its architecture and will see why it is becoming so popular among administrators these days.

What is VMware VSAN?

VMware Virtual SAN (VSAN) is a hypervisor-converged storage solution for your vSphere environment. It was built to be extremely easy to use and administrator, high performance and expandable.

VMware Virtual SAN is a new software-defined storage tier for VMware vSphere, bringing the benefits of the software defined data center to storage. By clustering server hard disk and solid state drives (HDDs and SSDs), Virtual SAN creates a flash-optimized, highly resilient shared datastore designed for virtual environments.

Why one should chose VSAN?

One of the main benefits of using VSAN is the simplified storage management, while delivering more performance. Using VSAN Administrator’s gets visibility into the storage layer through the virtual layer. It enables both compute and storage to be delivered to the VMs through a common virtualized platform.

VSAN can be setup as either hybrid or all-flash. In the hybrid setup the SSDs act as a cache. In the all-flash setup the SSDs act as both a cache and as data persistence enable overall better performance.

VSAN Architecture

VSAN is embedded in the vSphere kernel and optimized the I/O path to minimize the impact on CPU. Because it sits directly in the I/O data path, the product is able to deliver the highest levels of performance, scalability, and resilience without taxing the CPU with additional overhead.Administrators only need to create policies and assign them to VMs, VSAN automatically takes care of the rest and any changes will be applied by VSAN as well.

Virtual SAN has its own policy based approach to storage management. This management architecture enables administrators to specify storage attributes— such as capacity, performance, and availability—in the form of simple policies on a per-VM basis. These policies, governed by service-level agreements (SLAs), dynamically self-tune and load-balance the system so that each virtual machine has the right level of resources. The system can adapt to ongoing changes in workload conditions to ensure that each virtual machine has the storage resources it needs.

vsan

Graphic Thanks to VMware.com

Virtual SAN distributed architecture leverages enterprise grade SSDs for high-performance read/write caching and HDDs for cost-effective data persistence. Using server-side storage, Virtual SAN delivers unmatched price/performance compared to other Virtual Storage Appliances (VSA) or midrange hybrid arrays in the market today. The Virtual SAN datastore granularly scales up by adding more disks or scales out by adding more hosts, allowing users to configure the system to meet their needs flexibly.

To know more about architecture of VSAN, I would recommend reading this Blog

Thats its for this post. There is a lot to talk about VSAN and we will cover it in our upcoming posts of this series.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

 

 

Posted in VSAN | 3 Comments

vCloud Air Pricing Calculator

If you are looking for vCloud Air solution but don’t know about about vCloud Air offerings and associated prices, don’t worry. VMware has solution to this problem.

The vCloud Air Pricing Calculators below are available to help you estimate your costs of using various vCloud Air services. Configure the type of service and features you’re looking for and get pricing information quickly.

vCloud Air offers many solution including Virtual Private Cloud, Dedicated Cloud and Disaster Recovery. To know more about service offerings login to vCloud Air Portal and select service offerings to see list of all services offered.

vca-0

Once you have selected a suitable service for your organization, you can calculate how much that service is gonna cost you . To do a self calculation login to Public Configurator website.

Select the appropriate program type. Recently VMware has switched the pricing method to SPP credits. Hit continue after selecting the program type.

vca-1

Next is to select your Country and Customer Type. Continue after making the selection.

vca-2

Select VMware vCloud Air and hit continue.

vca-3

Select your region and service type

vca-4.PNG

Select storage type, number of months for which you want to use the service and billing type. After making the selection, hit Next to continue.

vca-5.PNG

If you want to add any Add-On to your selected service type, you can do so from below page.

vca-6

After making the selection, you can see a consolidated view of selected services/Add-On and total price for your selection.

You can also export the result to Excel.

vca-9.PNG

Note: You can also use this link to use the pricing calculator for various service offerings from vCloud Air.

vca-10.PNG

 

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in vCloud Air, Vmware | Leave a comment

Using Custom Certificates in vSphere Replication

In this post we will be working on using a custom signed certificates (CA Signed) on vSphere Replication Appliance.

Unlike vCenter Server, there is no automated way of replacing the default certificates on VR appliance and all it needs a bit of manual effort. VMware has outlined the steps in the official KB-2080395 to do so.

Before performing these steps, make sure you have already replaced the default certificates on your vCenter Server.

vSphere Replication appliance ships with openssl and you can use this to generate the certificate signing requests for the vSphere Replication appliance

Perform following steps to replace the default certs with CA signed certs:

1: Create openssl config file

SSH to your VR appliance and create an configuration file for Replication Appliance. Contents of this file would look like as shown below. You need to change the fields marked in bold.

vrs01:~ # vi vrs01.cfg

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS: vrs01, IP: 192.168.109.40, DNS: vrs01.alex.local

[ req_distinguished_name ]
countryName = IN
stateOrProvinceName = Karnataka
localityName = Bangalore
0.organizationName = Alex.Co
organizationalUnitName = Cloud
commonName = 192.168.109.40

2: Generate the certificate signing request:

vrs01:~/certs # openssl req -new -nodes -out vrs.csr -keyout vrs-orig.key -config vrs01.cfg

Generating a 2048 bit RSA private key
……………………………+++
…………………………………………………………………+++
writing new private key to ‘vrs-orig.key’
—–

3: Convert the key to the RSA format:

vrs01:~/certs # openssl rsa -in vrs-orig.key -out vrs01.key
writing RSA key

You will now see following files created in your current directory

vrs01:~/certs # ll
-rw-r–r– 1 root root 1675 Jun 24 14:14 vrs-orig.key
-rw-r–r– 1 root root 1171 Jun 24 14:14 vrs.csr
-rw-r–r– 1 root root 581 Jun 24 14:09 vrs01.cfg
-rw-r–r– 1 root root 1675 Jun 24 14:15 vrs01.key

4: Generate a signed certificate

Copy the vrs.csr file to your certificate authority and receive the signed certificate back.

  • Launch certificate authority web interface ( http://<servername>/CertSrv/)
  • Click Request a certificate > Advanced certificate request.
  • Open the certificate request in a plain text editor and copy the contents of tis file including —–BEGIN CERTIFICATE REQUEST—– to —–END CERTIFICATE REQUEST—– lines into the Saved Request box.
  • Click Web Server when selecting the Certificate Template and click Submit to submit the request.
  • Click Base 64 encoded on the Certificate issued screen and click Download Certificate.
  • save the certificate as vrs-ca.cer

transfer vrs-ca.cer to your VR appliance using winscp selecting Text Mode or ASCII mode to avoid the issue of special characters.

5: Convert the .cer file to .crt format

vrs01:~/certs # openssl x509 -in vrs-ca.cer -out vrs_01.crt

6: Convert the signed certificate to PKCS#12 format

vrs01:~/certs # openssl pkcs12 -export -in vrs_01.crt -inkey vrs01.key -name “vrs01” -passout pass:XXXXXX -out vrs01.p12

7: Add your certificate to the HMS trust store

By default vSphere Replication verifies remote server certificates using the thumbprint only. If you select the Accept only SSL certificates signed by a trusted Certificate Authority option in the VAMI, this causes vSphere Replication to verify the validity of the certificate as well as the thumbprint.

This means that the certificate authority that issued the certificates for vSphere Replication and vCenter Server must be trusted by vSphere Replication. By default, vSphere replication trusts all certificate authorities that the Java Virtual Machine trusts.

To do so perform the following steps:

7a: Download CA server root certificate. From CA server home page click on “Download a CA certificate,certificate chain or CRL”. Click on Download CA certificate and save the downloaded file as Root64.cer

7b: Copy Root64.cer file to the VR appliance using winscp in Text or ASCII mode transfer settings

7c: Run below command to import the certificate into the HMS truststore:

/usr/java/default/bin/keytool -import -trustcacerts -alias root -file /root/certs/Root64.cer -keystore /opt/vmware/hms/security/hms-truststore.jks -storepass Jf4HXhRTLERSgT10

Note: If you get this error “keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect” while running the above command, then run below command to find the truststore password

/opt/vmware/hms/bin/hms-configtool -cmd list | grep truststore

On successful completion of command you will see something like below:

Owner: CN=CASRV-CA, DC=alex, DC=local
Issuer: CN=CASRV-CA, DC=alex, DC=local
Serial number: 52e164a699c8b0a54887123a7f602a14
Valid from: Fri Jun 10 19:15:52 IST 2016 until: Thu Jun 10 19:25:51 IST 2021
Certificate fingerprints:
MD5: D2:4E:87:97:13:DD:E4:C2:2E:B1:93:22:71:A1:8A:B9
SHA1: F7:5B:70:29:C6:8C:8F:F7:25:99:49:03:95:07:44:EF:D6:4D:17:13
SHA256: 2D:CA:2E:65:BF:69:13:36:7E:83:77:01:94:06:C3:5D:84:52:2B:B7:3E:D0:6B:58:29:E0:D2:F0:F8:AA:B7:B7
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

#1: ObjectId: 1.3.6.1.4.1.311.20.2 Criticality=false
0000: 1E 04 00 43 00 41 …C.A

#2: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false
0000: 02 01 00 …

#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]

#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]

#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 3B 2E D1 3C 87 92 D1 85 78 05 70 49 EE 57 45 30 ;..<….x.pI.WE0
0010: 4D E4 CC 3F M..?
]
]

Trust this certificate? [no]: Yes
Certificate was added to keystore

7d: Run below command to verify the certificate is now present in the HMS truststore:

vrs01:~/certs # /usr/java/default/bin/keytool -list -v -keystore /opt/vmware/hms/security/hms-truststore.jks -storepass Jf4HXhRTLERSgT10

You will see following as output

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: root
Creation date: Jun 25, 2016
Entry type: trustedCertEntry

Owner: CN=CASRV-CA, DC=alex, DC=local
Issuer: CN=CASRV-CA, DC=alex, DC=local
Serial number: 52e164a699c8b0a54887123a7f602a14
Valid from: Fri Jun 10 19:15:52 IST 2016 until: Thu Jun 10 19:25:51 IST 2021
Certificate fingerprints:
MD5: D2:4E:87:97:13:DD:E4:C2:2E:B1:93:22:71:A1:8A:B9
SHA1: F7:5B:70:29:C6:8C:8F:F7:25:99:49:03:95:07:44:EF:D6:4D:17:13
SHA256: 2D:CA:2E:65:BF:69:13:36:7E:83:77:01:94:06:C3:5D:84:52:2B:B7:3E:D0:6B:58:29:E0:D2:F0:F8:AA:B7:B7
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

#1: ObjectId: 1.3.6.1.4.1.311.20.2 Criticality=false
0000: 1E 04 00 43 00 41 …C.A

#2: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false
0000: 02 01 00 …

#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]

#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]

#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 3B 2E D1 3C 87 92 D1 85 78 05 70 49 EE 57 45 30 ;..<….x.pI.WE0
0010: 4D E4 CC 3F M..?
]
]

*******************************************
*******************************************

8: Replace certificates on vSphere Replication Appliance

Connect to VR appliance VAMI console and log in as root: https://VRM IP:5480

Navigate to the Configuration tab.

Select Browse next to the Upload PKCS#12 (*.pfx) file and locate the certificate file you created.

vrs02.PNG

Click Upload, Install and enter the certificate password when prompted to install the new certificate.

As soon as new certificate is installed, VAMI will generate a message that it is going to kick you out of the console and you have to login again to pick the new certificate. You will see the green lock button telling you that it’s a trusted certificate.

vrs04.PNG

Thats it.  The new certificate is now applied

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in SSL Certficates, vSphere Replication | Leave a comment

Replacing vSphere 6 Solution user certificates with CA signed certificates

In our last post Replacing Esxi 6 SSL Certificates we learned how to replace Esxi host default certificates with CA signed certificates. In this post we will learn how to replace vSphere 6 solution user certificates with customer certificates signed by CA.

If you have missed earlier posts of this series, then you can read them from below links

1: Setup CA Server for vSphere Lab

2: Set Up Automatic Certificate Enrollment

3: Request Internal Certificate from CA Server

4: Everything You Should Know About Certificate Management in vSphere 6

5: Replacing vSphere 6 SSL Certificates

6: Replacing Esxi 6 SSL Certificates

Solution Users use SSL Certificates for internal communication and endpoint registration in vSphere 6. For vCenter with embedded PSC, there are four Solution User Certificates:

  • machine
  • vpxd
  • vpxd-extension
  • vsphere-webclient

We will be replacing certificates for all the solution user in this post.

Follow below steps to replace the solution user certificates:

1: Creating Certificate Signing Request

Launch the certificate manager utility

Press 5 to select “Replace solution user certificates with custom certificates”

Provide password of SSO account

Select option 1 “Generate Certificate signing Request(s) and key(s) for solution user certificates”

sol-1

Provide path to directory where you want to store the .csr files

sol-2.PNG

You will see following files created in the provided directory

sol-3

4: Get the signed certs from your CA server

Copy machine.csr, vpxd.csr,vpxd-extension.csr and vpshere-webclient.csr files to your CA server and repeat following steps foe each csr file

  • Launch certificate authority web interface ( http://<servername>/CertSrv/)
  • Click Request a certificate > Advanced certificate request.
  • Open the certificate request in a plain text editor and copy the contents of tis file including —–BEGIN CERTIFICATE REQUEST—– to —–END CERTIFICATE REQUEST—– lines into the Saved Request box.
  • Select  vSphere6 when selecting the Certificate Template and hit Submit to submit the request. For certificates templates please follow VMware KB-2112009
  • Click Base 64 encoded on the Certificate issued screen and click Download Certificate.

Save the files as machine.cer, vpxd.cer,vpxd-extension.cer and vpshere-webclient.cer respectively.

At last download the CA server root certificate. From CA server home page click on “Download a CA certificate,certificate chain or CRL”.

Click on Download CA certificate and save the downloaded file as Root64.cer.

Copy all the 5 files back to your vCenter Server.

5: Replace the certificates

Launch certificate manager again and select option 5 and then Option 2 (Import Custom certificate(s) and key(s) for Solution User Certificates).

sol-4.PNG

Provide path to the generated .cer files and respective key files to complete the certificate replacement process

sol-5

Thats it. We have now successfully replaced the defaults certs for solution users with CA signed certificate.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

 

 

Posted in Vmware | Leave a comment

Replacing Esxi 6 SSL Certificates

In our last post Replacing vSphere 6 SSL Certificates we learned how to replace Machine certificates and VMCA root certificates. In this post we will learn how to replace Esxi default ssl certificates with certificates signed by CA server.

If you have missed earlier posts of this series, then you can read them from below links

1: Setup CA Server for vSphere Lab

2: Set Up Automatic Certificate Enrollment

3: Request Internal Certificate from CA Server

4: Everything You Should Know About Certificate Management in vSphere 6

5: Replacing vSphere 6 SSL Certificates

ESXi host uses default certificates that are created during installation. These certificates are not verifiable and are not signed by a trusted certificate authority. If using default certificates do not fall under security policy of your organization, then you need the self-signed certificates from your CA server.

Note: ESXi hosts that are upgraded from vSphere 5.x to vSphere 6.0 will continue using their Certificate Authority signed certificates if they were replaced in the previous versions. However, ESXi 5.x hosts that were running self-signed certificates and then upgraded to vSphere 6.0 will have their certificates regenerated using VMware-signed.

We will be using openssl to create the self-signed certificates and then send them over to our CA server to sign them. Instructions for configuring openssl is described Here

The steps for replacing SSL certificates on Esxi hosts are as follows:

1: Configure openssl.cfg file

openssl.cfg file is located in C:\OpenSSL\bin directory. Make a backup of this file and edit the following fields in this file:


[ req_distinguished_name ]
countryName = IN
countryName_default = IN
stateOrProvinceName = Karnataka
stateOrProvinceName_default = Karnataka
localityName = Bangalore
0.organizationName = Alex.Co
0.organizationName_default = Alex.Co
organizationalUnitName = Cloud
commonName = vcentersrv01.alex.local
emailAddress = vcadmin@alex.com

2: Generate csr and key file by executing below command

Note: Create a directory before generating the cert files and navigate to that directory so that the below command will generate the certs in the present directory created.

openssl req -new -nodes -out rui.csr -keyout rui-orig.key -config C:\OpenSSL\bin\openssl.cfg

esxi-1

3: Convert the generated key in RSA format

openssl rsa -in rui-orig.key -out rui.key

esxi-2

Verify that rui.csr and rui.key files are generated. Copy rui.csr file to your CA server.

4: Generate a signed certificate.

  • Launch certificate authority web interface ( http://<servername>/CertSrv/)
  • Click Request a certificate > Advanced certificate request.
  • Open the certificate request in a plain text editor and copy the contents of tis file including —–BEGIN CERTIFICATE REQUEST—– to —–END CERTIFICATE REQUEST—– lines into the Saved Request box.
  • Click Web Server when selecting the Certificate Template and click Submit to submit the request.
  • Click Base 64 encoded on the Certificate issued screen and click Download Certificate.

esxi-3

save the certificate file as Esxi01.cer

5: Convert Esxi01.cer file format

ESXi hosts requires X.509 based certificate, so change the format of certificate file using the command below:

# openssl x509 -in Esxi01.cer -out Esxi_01.crt

6: Replace Esxi host old certificates with new certificates

Enable SSH on your Esxi host and place the host into Maintenance Mode. Navigate to /etc/vmware/ssl directory and move rui.crt and rui.key file to another location say for e.g. /tmp/oldcerts

Transfer the Esxi_01.crt file generated in step 5 and rui.key file generated in step 3 on your Esxi host using WinSCP using Text Mode or ASCII mode to avoid the issue of special characters.

Now restart management agent or reboot the host for new certificates to take effect.

Remove host out of Maintenance mode.

Now if you connect to the Esxi host directly from vSphere Client, it will prompt you to accept the new certificate. If you open the properties of this new certificate, you will see that it has been issued by your CA server

esxi-5

In my case the Esxi host got disconnected from vCenter Server after replacing the certs. restarting management agents did not fixed the issue for me. All I did was just rebooted the host and it connected automatically without any issues

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in SSL Certficates, Vmware | 3 Comments

Replacing vSphere 6 SSL Certificates

In our last post Certificate Management in vSphere 6 we had  a look on architecture of VMCA and what it do.

In this post I will walk through the steps needed to replace vSphere 6 SSL certificates.

In this post we will be covering following items:

1: Creating certificate templates for vSphere 6

2: Replacing Machine SSL certificates.

3: Replace VMCA Root certificate

If you have missed earlier posts of this series, then you can read them from below links

1: Setup CA Server for vSphere Lab

2: Set Up Automatic Certificate Enrollment

3: Request Internal Certificate from CA Server

4: Everything You Should Know About Certificate Management in vSphere 6

Lets the fun begin.

Create certificate templates

As per VMware KB Article 2112009 we need to create 2 certificate templates:

  • Machine SSL and Solution User certificates
  • Certificate template for VMCA as a Subordinate CA

To create the certificate templates, RDP to your Enterprise CA server  and click Start > Run, type certtmpl.msc, and click OK.

Right click on Certificate Templates directory and select Manage.

mks-1

 

From the list of the templates, right-click Web Server and click Duplicate Template.

mks-2

Under compatibility tab, select CA as Server 2008 and appropriate version of os family for certificate recipients

mks-3

Important Note: If you select Server 2012 as CA in above window, then the version of certificate template created will be v4 and it will not be visible while requesting a certificate.

On general tab, provide a name for the template and adjust validity period setting as per your need.

mks-4

Click the Subject Name tab. Ensure that the Supply in the request option is selected.

mks-5

Click the Extensions tab. Select Application Policies and click Edit.

mks-6

Select Server Authentication and click Remove.

mks-7

Note: If Client Authentication exists, remove this from Application Policies as well.

Now select Key Usage and click Edit. Select the Signature is proof of origin (nonrepudiation) option.

Leave all other options as default.

mks-8

At last click on security tab and make sure your user has rights to Enroll for certificates.

Hit OK to finish the template creation wizard.

mks-9

Now we will create certificate template for VMCA as subordinate.

To do so, select “Subordinate Certification Authority” template and click on Duplicate Template.

mks-10

Select Server 2008 as CA and appropriate os family as cert recipient.

mks-11

Click the General tab. In the Template display name field, enter name for the new template. Make sure that “Publish certificate in Active Directory” is selected.

mks-12

Click the Extensions tab. Select Key Usage and click Edit.

mks-13

Ensure that Digital Signature, Certificate signing and CRL signing are enabled.

mks-14

Under security tab, make sure user has permission to enroll for certificate.

mks-15

Hit OK to save the template.

Add newly created templates to Certificate Templates list

Right-click Certificate Templates and click New > Certificate Template to Issue.

mks-16

Select the newly created template and it OK. The newly created template will be then enabled.

mks-17

Creating Certificate Signing Request

Connect to your vCenter Server via RDP and perform following steps:

1: Browse to C:\Program Files\VMware\vCenter Server\vmcad\certool.cfg and edit as follows according to your environment

ssl-0

2: Run the command C:\Program Files\VMware\vCenter Server\vmcad\certificate-manager.bat to launch Certificate Manager menu.

ssl-1

3: Select Option 1 (Replace Machine SSL certificate with Custom Certificate)

Provide the administrator@vsphere.local password when prompted.

Select option 1 “Generate Certificate Signing Request(s) and Key(s) for machine SSL certificate”

Enter path to the directory in which you want to save the certificate signing request and the private key

ssl-2

4: Once the command completes, you will see 2 files in the directory name provided above.

Transfer these files onto your CA server

ssl-3

5: Open machine_ssl.csr file in a notepad and copy the contents of the file including

ssl-4

6: Log in to the Microsoft CA certificate authority Web interface. By default, it is http://CA_server_FQDN/CertSrv/

Click the Request a certificate link.

Click advanced certificate request.

ssl-5

7: Paste the content of file (including –BEGIN CERTIFICATE REQUEST– to –END CERTIFICATE REQUEST– lines) copied in step 5 in Base-64-encoded box.

From the Certificate Template dropdown, select the template which you created earlier and hit submit.

ssl-6

8: Select Base 64 encoded on the Certificate issued screen and click the Download Certificate link.

Also download the certificate chain from the same screen.

ssl-7

9: Copy the downloaded files to the directory where your csr and key files (generated in step 4) are stored. Rename the downloaded file in step 8 to machine.cer and chain file to cachain.p7b

ssl-8

10: Right click on cachain.p7b file and select open

In the newly opened window, select Certificates folder and from right hand side pane select CA Server cert > All Tasks > Export

ssl-9

Hit next to continue certificate export wizard

ssl-10

Select Base-64 encoded x.509 and hit next.

ssl-11

Browse to the directory where certificate will be exported. Name the exported file as root64.cer

ssl-12

Now copy the machine.cer, machine_ssl.key and root64.cer file on your vCenter Server.

Launch Certificate Manager again and choose option 1.

Now select option 2 i.e  Import Custom Certificate option and

  • Provide the path to the new certificate
  • Provide the path to the key
  • Provide the path to your Root certificate

Press “Y” when asked for confirmation for replacing the SSL certs

Capture

Now Login to vCenter Web Client and you will see your URL appears as green

vc.PNG

If you see the certificate info by clicking on the green lock icon you will see this cert has been issued by your CA server

cert

Replace VMCA Root certificate

Step 1. Edit the certool.cfg file – template file for CSR

The file is located at: C:\Program Files\VMware\vCenter Server\vmcad\certool.cfg

Modify this file as per your environment. My certool.cfg file looks like below


#
# Template file for a CSR request
#

# Country is needed and has to be 2 characters
Country = IN
Name = Alex Co.
Organization = Cloud
OrgUnit = Alex CLoud
State = Karnataka
Locality = Bangalore
IPAddress = 192.168.109.2
Email = vcadmin@alex.com
Hostname = vcentersrv01.alex.local

Step 2. Generate CSR files

Select Option 2 to “Replace VMCA Root certificate with Custom Signing Certificate and replace all Certificates”

Enter your SSO Password

Select Option 1 to “Generate Certificate Signing Request(s) and Key(s) for VMCA Root Signing certificate”

Provide the path to store your CSR and Key

vmca-1

Once the script completes you will see the csr and key file created in the directory provided by you

vmca-2

Transfer these files over to your CA server.

Step 3. Sign your CSR

Loin to your CA server and click on Request a certificate > Advanced Certificate Request

When you sign this certificate make sure you select the template which you duplicated from “Subordinate Certificate Authority”

vmca-3

Select Base 64 encoded and “Download certificate ”

vmca-4

Rename the downloaded file to vmca.cer

Also download CA server root certificate. From CA server home page click on “Download a CA certificate,certificate chain or CRL”

vmca-5

Click on Download CA certificate and save the downloaded file as rootca.cer

vmca-6

Now open vmca.cer and rootca.cer in notepad. Create a new text file and first copy the contents of vmca.cer into the new file and then paste the content of rootca.cer file. Save the file as chain.cer

Copy chain.cer file and root_signing_cert.key to your vCenter Server.

Step 4: Import Custom certificate(s) and key(s) for VMCA Root Signing certificate

Launch certificate-manager tool and select option 2 to “Import Custom certificate(s) and key(s) for VMCA Root Signing certificate”

Provide the chain.cer
Provide the root_signing_cert.key
Select ‘Y’

vmca-7.PNG

Verify the configuration of certool.cfg file and then wait for completion of cert replacement process

vmca-8

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

 

Posted in SSL Certficates, Vmware | 5 Comments

Everything You Should Know About Certificate Management in vSphere 6

SSL certificates played an important role in vSphere 5.1, and managing the certificates that the vSphere environment emerged as another challenge for most of the vsphere Admins. Replacing SSL certs in prior versions of vSphere (5.5 and 5.1) was a big headache.

Although vSphere 5.5 simplified the process of certificate replacement easy via the command line tools, but still it required a lot of steps to replace certs on each endpoint (vCenter Server, Single Sign On, Inventory Service, Web Client).

People like Derek Seaman’s done an excellent service for VMware community and developed a tool (vSphere Toolkit) which further simplified the process of replacing certificate and took much of the pain out of it. You can download vSphere toolkit for previous version of vSphere from here.

In past I wrote a blogpost on how to replace vSphere (vCenter + Esxi) certificates, and you can read it from Here.

In vSphere 6 VMware tried to address SSL certificates in a different manner and made managing SSL certificates a lot easier than previous releases.

Introduction to VMware Certificate Authority (VMCA)

In vSphere 6, VMware has shipped their own certificate authority (VMCA). VMCA is a built-in certificate authority, which is included in the Platform Services Controller (PSC) service. If you are using vCenter with embedded PSC, you will have one endpoint cert to replace, and with an external PSC you will have two endpoint certificates to replace.

VMCA is itself a fully functional CA and can be used to issue certificates to all vSphere 6 components (vCenter and ESXi hosts) in your environment. VMCA dont have any graphical interface like Microsoft CA and is totally command line driven.

You can either use it as your Root CA, which is the default configuration, or it can be used as a Subordinate CA which will be signed by an Enterprise CA.

By default, the VMCA will self-sign its own certificate to be used as a CA certificate that will sign all requests for certificates. This self-signed CA certificate can be replaced by a certificate that is signed by a 3rd party root CA or your own root CA. Any certificate signed by the VMCA, which is an intermediate CA to your root CA, can then be validated by clients with the root CA and VMCA certificates installed.

To read more about deployment options for VMCA read this blog from Derek Seamen.

VMCA can be managed using certool.exe command which is located typically  in

C:\Program Files\VMware\vCenter Server\vmcad\

on vCSA certtool can be found under

/usr/lib/vmware-vmca/bin/certool

VMware Endpoint Certificate Store (VECS)

The VMware Endpoint Certificate store (VECS) is a local repository for certificates and private keys. This is where all certificates within the PSC are stored, with the only exception of the ESXi certificates that are stored locally on vSphere hosts, so here you can:

  • Store certificates and keys
  • Sync trusted certificates
  • Sync CRLs
  • Use the UI
  • Use the CLI to perform various actions

The VECS includes a number of keystores including machine SSL certificates, trusted roots, CRLs, solution users (machine, vpxd, vpx-extension, vSphere-webclient) and other keystores such as those for vVols. VECS holds stores that contain certificates and their keys. These stores are shown as below

untitled (1)

 

Graphic Thanks to virtually-limitless.com

VECS itself can be managed via VECS-CLI which is located in the following directories.

C:\VMware\vCenter Server\vmafdd\

You can learn more about vecs-cli by following this link from Sean Whitney.

Certificate Type in vSphere 6

There are 3 types of certificates in vSphere 6:

  1. ESXi Certificate: This certificate is used by the ESXi host to encrypt nearly all communications.
  2. Machine SSL Certificate: Each node (embedded installation, management node, or PSC) has its own machine SSL certificate. All services running on this node use this certificate for endpoint encryption. The vCenter service (vpxd), VMware directory service (vmdir) also use these certificates.
  3. Solution User Certificates: These certificates are used for authentication to the vCenter SSO service. Once the certificate is presented to SSO, SSO will issue a SAML token. The service, such as vpxd, can then use this token to authenticate to other services. Baseline solution user certificates include vpxd, vpxd-extensions, and webclient.

With vSphere 6.0 there are more components but these components are now being grouped together into what’s being called Solution Users (SU). SUs now hold the certificate for the group rather than each component.

su

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in SSL Certficates | 3 Comments

Request Internal Certificate from CA Server

In last post Set Up Automatic Certificate Enrollment we walked through the steps for completing automated certificate enrollment.

In this post I will walk through the process on how to request an internal SSL certificate from an IIS web server in the domain, against our internal deployed CA.

Create Web Server Certificate Template for SSL Certs

Connect to the Enterprise CA and open the Certification Authority console.

Expand the certification authority so that you can see Certificate Templates. Right-click Certificate Templates and then click Manage.

caa-1

In the details pane of the Certificate Templates console, right-click the Web Server template and then click Duplicate Template.

caa-2

If you are prompted to select a template version, select Window Server 2008 R2 and then click OK.

caa-3

caa-4

In the General tab, under Template display name, type a name that you want to use for the template. For example, Lab Certs. Change the validity period as per your config.

caa-5

On the Subject Name tab select Build from this Active Directory information. Set the Subject name format to Common name. Under Include this information in alternate subject name, select the DNS name checkbox and clear the User principal name (UPN) checkbox.

caa-6

On Cryptography tab and ensure that the template is set to use a Minimum key size of 1024 bits or higher; 2048 bits or higher is preferred. Click OK.
caa-7

Close the Certificate Templates console and return to the Certificate Authority console.

In the console tree of the Certification Authority console, right-click Certificate Templates, click New, and then click Certificate Template to Issue.

caa-8

In the Enable Certificate Templates dialog box click the new certificate template that you created and then click OK.

caa-9

Complete an Internal Certificate Request

Launch IIS Manager and click on Server Certificates and click on Open feature.

ca-37

On the right, click on Create Certificate Request.

ca-38.PNG

Enter the fields in the request template.

ca-39

Leave the cryptographic service provider to default and change the key Bit Length to 4096 and hit next.

ca-40

Save the file to any location you like on the server and hit finish.

ca-41

Logon to your CA server using your browser (http://<CAserver>/certsrv)

1: Select Request a Certificate> Select Advanced Certificate Request.

caa-10

2: In the Certificate Template select Web Server.

3: Copy/paste the contents from your certificate request file (excluding the first and last line “— beginning of new request file —” and “— end of new request file —“).

caa-11

4: Save your certificate output as Base 64 encoded  CER-file.

caa-12

5: From within IIS, select Complete Certificate Request.

caa-132.PNG

caa-133.PNG

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in SSL Certficates | 3 Comments

Set Up Automatic Certificate Enrollment

In our last post Setup CA Server we saw installation/configuration of CA server. In this post we will see how to automate certificate enrollment process.

For fewer number of components you can generate and sign certificates manually and then replace it one by one. in a small environment. But if you have many servers running in lab or say you are using CA in production where you have 100’s of servers, then replacing the certs manually is a time consuming and very tedious job.

We can automate the automate the certs enrollment via Active Directory to save time. Using Active Directory domain with an Enterprise CA; we can deploy certificates on clients that are part of domain automatically using a process known as autoenrollment. This saves a lot of time and reduces the amount of administrative overhead required to deploy certificates on to client systems. For this to work, we need GPO linked to our domain or an OU configured with the autoenroll policy.

Prerequisites:

1: Active Directory installed and configured.

2: Enterprise Root CA installed/configured.

3: Client system joined to AD domain

Let see how to automate the cert enrolment process.

Log in to one of domain controllers and open the Group Policy Management console.

gp-1

If you want the policy to apply to all clients in your domain, create and link the GPO to the root of the domain.

To create the GPO, right-click the root of the domain or the OU and choose Create a GPO in this domain, and Link it here.

gp-2

Provide a name for the GPO and click OK.

gp-3.PNG

Right click on newly created GPO and edit it.

Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.

Here you will see Certificates Services Client – Autoenrollment policy.

gp-4

Select Enabled on the Configuration Model box, then check the boxes Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates. Hit OK after making the changes.

 

Next is to tell the clients what type of certificate they can request and this can be done by creating a Certificate Request Setting.

To do so expand the Public Keys Policies folder, right-click Automatic Certificate Request Settings and choose New > Automatic Certificate Request.

gp-7

Hit Next on the Welcome screen of the wizard.

gp-8

Select computer from the Certificates Templates page and hit next. Click finish to complete the wizard.

Log in to any of you client computer which is part of your AD domain and open the certificate store from Start > Run > mmc. Once the console opens, from the File menu choose Add/Remove Snap-in.

gp-11

Select Certificates from left side of window and click on Add >

gp-12

Choose Computer account > Local computer.

 

At this moment there are no certificates in the Personal folder. AD will take some time to distribute the certs on client system. Generally group policy will take 90 to 120 minutes for enforce the policy on all client systems.

gp-15

To view the certificate in real time do a gpupdate/force on the client computer.  The client system will immediately update the group policy and you will see a cert under personal folder.

gp-16

You can see in below screenshot that this cert is distributed by my CA server under Issued By column.

gp-17

Double click on the cert to view its properties.

gp-18

In our Next post we will see how to create certificate templates for VMware products.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in SSL Certficates | 3 Comments

Setup CA Server for vSphere Lab- Say Good Bye to Self-Signed Certs

A while back I wrote a post on Configuring CA Server on Server 2008 so that one can use signed certificate in lab or even in production.

Most vSphere appliances/softwares comes with a self-signed certs and works just fine in home lab. But if you are like me and get annoyed by  the warning message “Your connection is not secure”, then generate signed certificates to use in your lab and get rid of the ugly browser warning message.

As I stated in my earlier post on SSL certs that self-signed certs works just fine but it’s good to know how to work with signed certificates as in production environment organizations don’t use self-signed certificates and rely on SSL certificates bought from 3rd party like Thawte or Verisign.

There are 2 types of CA server: Standalone and Enterprise.

Enterprise Root CA: The enterprise root CA is the most trusted CA in an organization and should be installed before any other CA. All other CAs are subordinate to an enterprise root CA. This CA should be highly physically secured, as a compromise of the enterprise CA effectively makes the entire chain compromised.

Enterprise Subordinate CA:  An enterprise subordinate CA must get a CA certificate from an enterprise root CA but can then issue certificates to all users and computers in the enterprise. These types of CAs are often used for load balancing of an enterprise root CA.

Standalone Root CA: A standalone root CA is the root of a hierarchy that is not related to the enterprise domain information. Multiple standalone CAs can be established for particular purposes. A standalone root CA is often used as the root for other enterprise subordinate CAs to improve security in an environment. In other words, the root is configured as standalone, and subordinate enterprise domain integrated CAs are set up within the domains in a forest to provide for autoenrollment across the enterprise.

Standalone Subordinate CA: A standalone subordinate CA receives its certificate from a standalone root CA and can then be used to distribute certificates to users and computers associated with that standalone CA.

An enterprise CA is typically used to issue certificates to users, computers, and services, and is not typically used as an offline CA. Enterprise CA requires AD DS, which can be used as a configuration and registration database. An enterprise CA also provides a publication point for certificates issued to users and computers.

In this post we will be setting up Enterprise CA Server.

Users can request certificates from an Enterprise CA using the following methods:

  1. Manual Enrollment
  2. Web Enrollment
  3. Auto enrollment
  4. Enrollment agent

For more information on CA please read this Article

In this post I am going to share the steps needed to configure a Windows 2012 R2 Server as Certificate Authority.

Prerequisites

  • Active Directory Domain already setup and configured.
  • Server 2012 installed and joined to domain.

Let’s jump into action now.

1: Launch Server Manager and click on Add Roles and features.

ca-1

2: Select Role-based or feature-based installation.

ca-2

3: From the list of roles available select “Active Directory Certificate Service” and hit Next.

ca-3

4: A new window will pop-up. Click on Add Features

ca-4

5: On Select features page hit Next.

ca-5

6: Hit Next to continue.

ca-6

7: On select role page, select “Certification Authority” and hit Next.

ca-7

8: On the confirmation page hit Install.

ca-8

9: Once installation is complete hit Close.

ca-9

Note: The above steps can be achieved via command line as well. You can run following command to add the windows cert role


Add-WindowsFeature ADCS-Cert-Authority, ADCS-Web-Enrollment -IncludeManagementTools

10: Click on Manage button on top of Server Manager window and click on “Configure Active Directory Certificate Services” option to complete the post-deployment configuration of CA server.

ca-10

11: On specify Credentials page specify the user accounts that have local administrator rights on the server where you are configuring CA server role. Hit Next to continue.

ca-11

12: On Role Services page select “Certification Authority” and hit Next.

ca-12

13: Select “Enterprise CA” on Setup type page. Hit Next to continue.

ca-13

14: On CA Type page select “Root CA” and hit next.

ca-14

15: On Private Key page select “Create a new private key”

ca-15

16: Select SHA 1 and key length as 4096 as cryptographic options. The bigger is the key length, the most secure it is and most hard to break.

ca-16

Update: 08/06/2016

Since SHA-1 is has been retired, update hash algorithm on CA server by running the command from powershell:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

Reboot the server after that for changes to take effect.

17: Dont change the defaults on CA name page and hit next.

ca-17

18: Default validity period is 5 years. Change this to any value as per your need and hit next.

ca-18

19: Choose default for CA Database location and hit next.

ca-19

20: On the confirmation page click on configure to finish configuration.

ca-20

21: On Results page hit close to complete the configuration wizard.

ca-21

Add Certification Authority Web Enrollment service

The Web Enrollment service is very useful while making requests for certificates from computers that are not members of AD domain. This essentially allow certificates to be enrolled directly over HTTP, enabling non-domain or Internet-connected clients to connect and request certificates from a CA server.

Once “Certificate Authority” role is installed completely, you can add Certification Authority Web Enrollment service to it from server manager page.

22: Launch server manager again select “Certification Authority Web Enrollment” and hit Next.

ca-22

23: Click on Add features to add IIS role.

ca-23

24: On select features page just hit next.

ca-24

25: Hit next to continue.

ca-25

26: Add the roles as shown in below screenshot and hit next.

ca-26

27: Hit Install to start the role installation process

ca-27

28: Once installation is completed, continue with Post-deployment configuration.

ca-28

29: Specify the credentials and hit next.

ca-29

30: Make sure “Certification Authority Web Enrollment” role is selected. Hit next.

ca-30

31: On confirmation page click on configure.

ca-31

32: Hit close once configuration is succeeded.

ca-32

Verify Certificate Authority Functionality

To verify that the CA server is operational, we can check both from within our browser as well as by checking the Certificate Authority management console. On your CA server, start the Certificate Authority Management tool. If all is well, this will show your CA server with a green icon, it means the CA services are up and running.

ca-229

Once the installation/configuration of web-enrollment completes,  open a browser and see if the certificate enrollment web page is working.

From a client, type your CA server name followed by /certsrv (http://CA-SRV-FQDN/certsrv). If you opened browser on the CA server itself you can use localhost followed by /certsrv.

Access CA server over https

By default the web portal for CA server is accessible over http. However if you want to access CA server over secure connection, you can change the protocol to https.

Launch IIS manager and navigate to default Web Site. You will see  a virtual directory “CertSrv” created. Select certsrv and look on right hand side pane and you will see it can be browsed over http.

ca-33

To make it accessible over https, select the default web site and right click on it and choose “Edit Bindings”

ca-34

Click on ADD

On Add Site Binding page, select type as https and select the IP address of the CA server. Provide a hostname for the ca srv and hit OK.

ca-35

You will see now https has been added now. You can chose to remove http from site bindings if you wish. This means your ca srv web portal will be accessible only over https.

ca-36

In our Next post we will see Set Up Automatic Certificate Enrollment.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in SSL Certficates | 6 Comments

Install vCloud Director 8 with High Availability

vCloud Director 8.0 is the latest version available for service providers and can be downloaded from here.

It’s been quite sometime that I am dealing with vCloud Director in our production environment and as well as my test lab. In past I have written a post on how to install vCloud Director 5.5. You can also read the entire vCloud Director post series from Here

Since v8 is out there in market for sometime, I decided to try my hands on it and implement that in my homelab.

There are various posts available on internet about what is vCloud Director and what it does. So I will not talk much about it and jump directly into action.

In this post we will be going to learn how to deploy vCloud Director with high availability.

Pre-requisites before installing vCloud Director:

1: Two server (for 2 vcd cells) with Redhat as guest operating system installed and configured. Hostname and DNS should be configured. Also make sure your Redhat guest os is synching its time from NTP server.

2: The Redhat Server must have 2 NIC’s and each with different IP address (preferred) for HTTP and Console connection. This server should be reachable to your database server over the network.

3: vCloud Director installation file (bin file) downloaded and copied to server where it will be installed.

4: Certificates must be generated for http and console-proxy connection.

5: vCloud Director database configured.

6: Additional Redhat server (or any other linux flavour) configured as NFS server.

Let’s see configuration of each component one by one.

1: vCloud Director database configuration

Run the following script on your SQL server to configure database for vcloud Director. In my lab I am running SQL 2014 as database.


//Create Database

USE [master]
GO
CREATE DATABASE [vcloud] ON PRIMARY
(NAME = N’vcloud’, FILENAME = N’E:\MSSQL\VCDDB\Data\vcloud.mdf’, SIZE = 100MB, FILEGROWTH = 10% )
LOG ON
(NAME = N’vcdb_log’, FILENAME = N’E:\MSSQL\VCDDB\Logs\vcloud.ldf’, SIZE = 1MB, FILEGROWTH = 10%)
COLLATE Latin1_General_CS_AS
GO

//Set the transaction isolation level

USE [vcloud]
GO
ALTER DATABASE [vcloud] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [vcloud] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [vcloud] SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT;
ALTER DATABASE [vcloud] SET MULTI_USER;
GO

//Create the database user and password

USE [vcloud]
GO
CREATE LOGIN [vcloud] WITH PASSWORD = ‘YourPWD’, DEFAULT_DATABASE =[vcloud],
DEFAULT_LANGUAGE =[us_english], CHECK_POLICY=OFF
GO
CREATE USER [vcloud] for LOGIN [vcloud]
GO

//Assign permissions to the user
USE [vcloud]
GO
sp_addrolemember [db_owner], [vcloud]
GO

Make sure your sql server is reachable from both vcd cells at port 1433

[root@vcd01 ~]# telnet sqlsrv01 1433
Trying 192.168.109.3...
Connected to sqlsrv01.
Escape character is '^]'

[root@vcd02 ~]# telnet sqlsrv01 1433
Trying 192.168.109.3...
Connected to sqlsrv01.
Escape character is '^]'

2: Create  NFS Mounts

Login to your NFS server and create a directory which will be mounted as NFS share on VCD cell. I am running my NFS server on RHEL 6.


<strong>Verify the NFS Export settings</strong>

[root@vcdnfs ~]# cat /etc/exports
/home/data/ 192.168.109.0/24(rw,sync,no_root_squash)

<strong>Start NFS Services</strong>

[root@vcdnfs ~]# service nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS mountd: [ OK ]
Starting NFS daemon: [ OK ]
Starting RPC idmapd: [ OK ]

<strong>Make sure NFS service is set to start on system boot</strong>

[root@vcdnfs ~]# chkconfig --list | grep nfs
nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off
[root@vcdnfs ~]# chkconfig nfs on

3: Generate Certificates on VCD cell

a: Certificate for http

[root@vcd01 ~]# keytool -keystore vcd.ks -storetype JCEKS -storepass vcl@2016 -vali
dity 9999 -genkey -keyalg RSA -alias http
What is your first and last name?
  [Unknown]:  Alex Hunt
What is the name of your organizational unit?
  [Unknown]:  Cloud
What is the name of your organization?
  [Unknown]:  Virtual reality
What is the name of your City or Locality?
  [Unknown]:  Bangalore
What is the name of your State or Province?
  [Unknown]:  Karnataka
What is the two-letter country code for this unit?
  [Unknown]:  IN
Is CN=Alex Hunt, OU=Cloud, O=Virtual reality, L=Bangalore, ST=Karnataka, C=IN correct?
  [no]:  yes

Enter key password for &amp;lt;consoleproxy&amp;gt;
        (RETURN if same as keystore password):

b: Certificate for console proxy

[root@vcd01 ~]# keytool -keystore vcd.ks -storetype JCEKS -storepass vcl@2016 -validity 9999 -genkey -keyalg RSA -alias consoleproxy
What is your first and last name?
  [Unknown]:   Alex Hunt
What is the name of your organizational unit?
  [Unknown]:  Cloud
What is the name of your organization?
  [Unknown]:  Virtual reality
What is the name of your City or Locality?
  [Unknown]:  Bangalore
What is the name of your State or Province?
  [Unknown]:  Karnataka
What is the two-letter country code for this unit?
  [Unknown]:  IN
Is CN=" Alex Hunt", OU=Cloud, O=Virtual reality, L=Bangalore, ST=Karnataka, C=IN correct?
  [no]:  yes

Enter key password for &amp;lt;consoleproxy&amp;gt;
        (RETURN if same as keystore password):

c: List the generated certificates

[root@vcd01 ~]# keytool -storetype JCEKS -storepass vcl@2016 -keystore vcd.ks -list

Keystore type: JCEKS
Keystore provider: SunJCE

Your keystore contains 2 entries

consoleproxy, Jun 4, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): B5:66:36:28:D3:E1:6A:07:9A:16:9C:75:BA:BF:D9:95:3E:17:14:D6
http, Jun 4, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): 45:FE:93:61:67:C3:49:D6:B3:D3:BF:5A:95:43:BE:B0:72:09:80:51

4: Install vcloud Director

Run the vCloud Director bin file but don’t invoke configuration script as of now. We will invoke the script later after doing some modifications on server.

[root@vcd01 ~]# ./vmware-vcloud-director-8.3.1-3168797.bin
Checking free disk space...done
Checking for a supported Linux distribution...Detected Red Hat Linux system
done
Checking for necessary RPM prerequisites...done
Extracting VMware vCloud Director. Please wait, this could take a few minutes...
vmware-vcloud-director-8.3.1-3168797.x86_64.rpm
vmware-vcloud-director-rhel-8.3.1-3168797.x86_64.rpm
done
Verifying RPM signatures...done
Installing the VMware vCloud Director RPMs...
warning: vmware-vcloud-director-8.3.1-3168797.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID 66fd4949: NOKEY
Preparing...                ########################################### [100%]
   1:vmware-vcloud-director-########################################### [ 50%]
   2:vmware-vcloud-director ########################################### [100%]

You should now run the configuration script
(/opt/vmware/vcloud-director/bin/configure) to perform other required
post-installation configuration.

If you will be deploying a vCloud Director cluster you must mount the shared
transfer server storage prior to running the configuration script. If this
is a single server deployment no shared storage is necessary.

If you are not ready to do this right now, you may run the script later
prior to starting the vmware-vcd service.

Would you like to run the script now? (y/n)? n

Skipping. You may run the configuration script at a later time by executing
/opt/vmware/vcloud-director/bin/configure

5: Mount NFS share on vCloud Cell

a: List the NFS mount

[root@vcd01 transfer]# showmount -e 192.168.109.32
Export list for 192.168.109.32:
/home/data 192.168.109.0/24

b: Mount the NFS share in /opt/vmware/vcloud-director/data/transfer directory

[root@vcd01 transfer]# mount -t nfs 192.168.109.32:/home/data/ /opt/vmware/vcloud-director/data/transfer

c: Verify that NFS share has been mounted on VCD Cell

[root@vcd01 transfer]# mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
192.168.109.32:/home/data/ on /opt/vmware/vcloud-director/data/transfer type nfs (rw,vers=4,addr=192.168.109.32,clientaddr=192.168.109.30)

d: Mount the NFS share permanently on the vCD Cell by editing /etc/fstab file and making an entry as shown below

192.168.109.32:/home/data/ /opt/vmware/vcloud-director/data/transfer nfs defaults 0 0

e: Change the owner of transfer directory to vcloud user and set the permission to RW

[root@vcd01 ~]# chown -R vcloud:vcloud /opt/vmware/vcloud-director/data/transfer

[root@vcd01 ~]# chmod -R 750 /opt/vmware/vcloud-director/data/transfer

6: Move the certificate file  which we generated in step 3 to /opt/vmware/vcloud-director. Why we need to do so is explained here

[root@vcd01 ~]# cp /root/vcd.ks /opt/vmware/vcloud-director/

Also import the public key from VMware

[root@vcd01 etc]# rpm –import https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub

[root@vcd01 etc]# rpm –import https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub

7: Invoke the VCD configuration script.

We need to specify following:

  • IP Address for the HTTP service
  • IP Address for the Console Proxy IP
  • Location of the certificate keystore certificates.ks
  • IP Address for the Syslog server (which I skipped as I dont have syslog server in lab)
[root@vcd01 ~]# /opt/vmware/vcloud-director/bin/configure
Welcome to the vCloud Director configuration utility.

You will be prompted to enter a number of parameters that are necessary to
configure and start the vCloud Director service.

Please indicate which IP address available on this machine should be used for
the HTTP service and which IP address should be used for the remote console proxy.

The HTTP service IP address is used for accessing the user interface and the
REST API. The remote console proxy IP address is used for all remote console (VMRC)
connections and traffic.

Please enter your choice for the HTTP service IP address:
        1. 192.168.108.15
        2. 192.168.109.30
        3. 192.168.122.1
        4. 127.0.0.1
        5. [fe80:0:0:0:250:56ff:febe:5869]
        6. [fe80:0:0:0:250:56ff:febe:6964]
        7. [0:0:0:0:0:0:0:1]
Choice [default=1]: 2

Please enter your choice for the remote console proxy IP address:
        1. 192.168.108.15
        2. 192.168.122.1
        3. 127.0.0.1
        4. [fe80:0:0:0:250:56ff:febe:5869]
        5. [fe80:0:0:0:250:56ff:febe:6964]
        6. [0:0:0:0:0:0:0:1]
Choice [default=1]: 1

Please enter the path to the Java keystore containing your SSL certificates and
private keys: /opt/vmware/vcloud-director/vcd.ks
Please enter the password for the keystore:

If you would like to enable remote audit logging to a syslog host please enter
the hostname or IP address of the syslog server. Audit logs are stored by
vCloud Director for 90 days. Exporting logs via syslog will enable you to
preserve them for as long as necessary.

Syslog host name or IP address [press Enter to skip]:
No syslog host was specified, disabling remote audit logging.

Next is to specify the database details.

The following database types are supported:
        1. Oracle
        2. Microsoft SQL Server
        3. vPostgres
Enter the database type [default=1]: 2
Enter the host (or IP address) for the database: sqlsrv01.alex.local
Enter the database port [default=1433]: 1433
Enter the database name [default=vcloud]: vcloud
Enter the database instance [Press enter to use the server's default instance]:
Using server's default instance name.

Enter the database username: vcloud
Enter the database password:
Connecting to the database: jdbc:jtds:sqlserver://192.168.109.3:1433/vcloud;socketTimeout=90;prepareSQL=2
......................................../Database configuration complete.

vCloud Director configuration is now complete.

Once the vCloud Director server has been started you will be able to
access the first-time setup wizard at this URL:
        https://vcd01.alex.local

Installer will ask you to start the VCD cell service. Press “Y” to continue

	
Would you like to start the vCloud Director service now? If you choose not
to start it now, you can manually start it at any time using this command:
service vmware-vcd start

Start it now? [y/n] y

Starting vmware-vcd-watchdog:                              [  OK  ]
Starting vmware-vcd-cell                                   [  OK  ]

The vCD service will be started automatically on boot.  To disable this,
use the following command: chkconfig --del vmware-vcd

You can tail cell.log to see the startup progress.

[root@vcd01 ~]# tail -f /opt/vmware/vcloud-director/logs/cell.log
Application startup event: Subsystem 'com.vmware.vcloud.computeservice.broker' startup initiated.
Application startup begins: Subsystem 'com.vmware.vcloud.computeservice.broker' at 6/5/16 5:25 PM
Application Initialization: 'com.vmware.vcloud.computeservice.broker' 50% complete. Subsystem 'com.vmware.vcloud.backend-core-base' started
Application Initialization: 'com.vmware.vcloud.computeservice.broker' 100% complete. Subsystem 'com.vmware.vcloud.computeservice.broker' started
Application Initialization: 'com.vmware.vcloud.computeservice.broker' complete. Server is ready in 0:00 (minutes:seconds)
Application Initialization: 'com.vmware.vcloud.common.core' 95% complete. Subsystem 'com.vmware.vcloud.jax-rs-servlet' started
Application Initialization: 'com.vmware.vcloud.common.core' 100% complete. Subsystem 'com.vmware.vcloud.ui-vcloud-webapp' started
Application Initialization: 'com.vmware.vcloud.common.core' complete. Server is ready in 1:28 (minutes:seconds)
Successfully posted pending audit events: com/vmware/vcloud/event/cell/start
Successfully verified transfer spooling area: /opt/vmware/vcloud-director/data/transfer

Installation of first cell has been completed here. Let’s see how to deploy additional cell for failover

8: Deploy Additional cell for failover

Copy the certificate file which you created on first vcd cell to your second vcd cell. Also copy the response.properties file to the second cell. The default location for response.properties file is /opt/vmware/vcloud-director/etc/

This file contains the location of the keystore certificates.ks and also the DB server information such as IP, Database instance name, login etc.

a: Install vCloud Director on second cell and press ‘n’ when it invokes for configuration script

[root@vcd02 ~]# ./vmware-vcloud-director-8.3.1-3168797.bin
Checking free disk space...done
Checking for a supported Linux distribution...Detected Red Hat Linux system
done
Checking for necessary RPM prerequisites...done
Extracting VMware vCloud Director. Please wait, this could take a few minutes...
vmware-vcloud-director-8.3.1-3168797.x86_64.rpm
vmware-vcloud-director-rhel-8.3.1-3168797.x86_64.rpm
done
Verifying RPM signatures...done
Installing the VMware vCloud Director RPMs...
Preparing...                ########################################### [100%]
   1:vmware-vcloud-director-########################################### [ 50%]
   2:vmware-vcloud-director ########################################### [100%]

You should now run the configuration script
(/opt/vmware/vcloud-director/bin/configure) to perform other required
post-installation configuration.

If you will be deploying a vCloud Director cluster you must mount the shared
transfer server storage prior to running the configuration script. If this
is a single server deployment no shared storage is necessary.

If you are not ready to do this right now, you may run the script later
prior to starting the vmware-vcd service.

Would you like to run the script now? (y/n)? n

Skipping. You may run the configuration script at a later time by executing
/opt/vmware/vcloud-director/bin/configure

b: Mount same NFS share in transfer directory which you mounted on cell-a

3: Invoke the configuration script with -r /path_to_response_file option. Make sure you copy response.properties file on /opt/vmware/vcloud-director/ folder. Also make the owner of the file vcloud user and assign appropriate permission on the file

[root@vcd02 vcloud-director]# chmod 755 /opt/vmware/vcloud-director/responses.properties
[root@vcd02 vcloud-director]# chown vcloud:vcloud /opt/vmware/vcloud-director/responses.properties

This time the configuration script will only ask for http and http_proxy ip.

[root@vcd02 vcloud-director]# /opt/vmware/vcloud-director/bin/configure -r /opt/vmware/vcloud-director/responses.properties
Welcome to the vCloud Director configuration utility.

You will be prompted to enter a number of parameters that are necessary to
configure and start the vCloud Director service.

Please indicate which IP address available on this machine should be used for
the HTTP service and which IP address should be used for the remote console proxy.

The HTTP service IP address is used for accessing the user interface and the
REST API. The remote console proxy IP address is used for all remote console (VMRC)
connections and traffic.

Please enter your choice for the HTTP service IP address:
        1. 192.168.108.16
        2. 192.168.109.31
        3. 192.168.122.1
        4. 127.0.0.1
        5. [fe80:0:0:0:250:56ff:febe:2fc4]
        6. [fe80:0:0:0:250:56ff:febe:711d]
        7. [0:0:0:0:0:0:0:1]
Choice [default=1]: 2

Please enter your choice for the remote console proxy IP address:
        1. 192.168.108.16
        2. 192.168.122.1
        3. 127.0.0.1
        4. [fe80:0:0:0:250:56ff:febe:2fc4]
        5. [fe80:0:0:0:250:56ff:febe:711d]
        6. [0:0:0:0:0:0:0:1]
Choice [default=1]: 1

Connecting to the database: jdbc:jtds:sqlserver://192.168.109.3:1433/vcloud;socketTimeout=90;prepareSQL=2
DB credentials read successfully from response file.
...\Database configuration complete.

vCloud Director configuration is now complete.

Once the vCloud Director server has been started you will be able to
access the first-time setup wizard at this URL:
        https://vcd02.alex.local

Would you like to start the vCloud Director service now? If you choose not
to start it now, you can manually start it at any time using this command:
service vmware-vcd start

Start it now? [y/n] y

Starting vmware-vcd-watchdog:                              [  OK  ]
Starting vmware-vcd-cell                                   [  OK  ]

The vCD service will be started automatically on boot.  To disable this,
use the following command: chkconfig --del vmware-vcd

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in vCloud Director, Vmware | 3 Comments

Replicate VM to vCloud Air using vSphere Replication

In my last post Disaster Recovery with vcloud Air we discussed what is vcloud Air Disaster Recovery service and saw how to prepare your infrastructure for replicating VM’s to Vcloud Air.

This post is continuation of my last post where I will be demonstrating how to replicate VM from on premise datacenter to vCloud Air. Let’s jump into action straightaway.

1: Login to your on-premise vSphere Web-Client and select the VM which you want to replicate, right click on it and chose All vSphere Replication Action > Configure Replication

Note: Make sure the VM which you want to replicate has HW version is less than 11 because VCA doesn’t support VM’s with HW v11 yet.

rep-1

2: Select “Replicate to a cloud provider” in the new window which popped up. Hit Next to continue.

rep-2

3: Select the target vDC in Cloud and make sure it shows as connected. Hit next to continue.

rep-4

4: Select the appropriate storage policy for the VM which you are replicating. vCloud Air provides two types of storage: Standard and SSD on the basis of what you have purchased.

Hit next to continue.

rep-5

5: If you are running a VM which is generating a lot of IOPS (like a DB server) or produces more transactions then it’s best to select Guest OS quiescing. Optionally you can select Enable network compression for VR data. This policy only works when you have vSphere 6 running on both sides. Hit Next to continue.

rep-6

6: Select the RPO settings for the VM. This setting determines how often a VM will be replicated to Cloud.

Note: First time when a VM is configured for replication, vSphere Replication is going to copy entire disk contents and will replicate it over the WAN link  to Cloud. This is known as “Initial full sync

For subsequent replications after that only the delta changes will be replicated to cloud.

You should plan your RTO settings carefully. the configured value of RPO settings is min 15 mins to max 24 hours

Choosing a value too low say for e.g 15 mins will produce overhead on your on prem infra as VM will be snapshotted time and again and delta changes will be replicated over your WAN link. Choosing this value too high say for e.g 8 hours, can cause you lose more data in event of catastrophic failure in your on premise datacenter.

So you have to analyze what type of VM you are going to replicate to cloud. You would like to chose low value of RTO for a VM which  is very business critical and which is writing data very frequently to disk. Such a VM can produce a huge amount of delta changes say just in an hour.

Hit Next to continue.

rep-7

7:  On ready to complete page review your settings and hit finish.

rep-8

8: Now Navigate to vSphere Replication page and click on Monitor tab to see the status of replication. It will show you various states of replication. The very first one which you would likely to see will be configuring replication.

rep-9

After a few minute the status will change to Initial Full Sync

rep-10

At the same time if you login to vcloud Air and navigate to your Org VDC, you will see the same status there as well

rep-12

At last you will see an OK status for your replicated VM. Which means that your VM has been replicated to cloud successfully.

rep-13

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

 

Posted in Vmware, vSphere Replication | Leave a comment

Disaster Recovery with vCloud Air

Why you need DR solution?

Business continuity and disaster recovery are paramount for ensuring your business critical environment, data, and online presence are available with minimal downtime. The availability services offered on vCloud Air help ensure that your data is protected, recoverable, and accessible by you and your customers.

What is VMware vCloud Air Disaster Recovery Solution?

VMware vCloud Air Disaster Recovery is a recovery-as-a-service (DRaaS) offering. It provides simple, affordable protection in the cloud for your vSphere environment. It leverages vSphere Replication to provide powerful, asynchronous replication capabilities at the hypervisor layer.

Some of the advantages of using DR with vcloud Air can be summarized as below:

  1. Allows virtual machines in vSphere to be easily configured for disaster recovery
  2. Removes traditional dependencies on underlying infrastructure hardware or data center mirroring
  3. Provides per-virtual-machine replication and restore granularity
  4. Uses vCloud Air as a scalable platform for compute infrastructure and storage capacity

What vCloud Air Disaster Recovery Does?

Self-Service Protection
Protect up to 500 virtual machines per subscription, on an as-needed basis.

Custom Recovery Point Objectives
Set a unique recovery point objective (RPO) value per virtual machine from 15 minutes to 24 hours.

Flexible Failover Testing
Test various failover scenarios as often as necessary during the service period.

Elastic Cloud Compute and Storage
Flexible subscription options can be expanded as needed. One-time compute capacity can be added for short-term failover and recovery requirements.

In this post we are going to see how to setup DR to Vcloud Air.

Pre-requisites for setting DR

1: You must have subscription to vCloud Air DR service. If you have subscription to vCloud Air DR service and when you login to vCloud Air portal (vca.vmware.com)  you will see a subscription tile labelled DR as shown below:

dr2c-1

2: You must have an Org vDC created in your vCloud Air DR subscription.

dr2c-2

 

3: Your Org vDC must be enabled for replication. (By default when you purchase a DR subscription, this is done in backend for you by the operations team)

4: You must have networks created for recovery in your Org vDC.

You need 2 networks, one for testing the DR functionality and other one for VM communication when you recover a VM in vcloud Air at the time of disaster in your on-prem datacenter.

dr2c-3

5: vSphere Replication Appliance deployed in your on-prem datacenter and registered to your vCenter Server.

Also you must have internet running on your vCenter Server, Esxi host and your vSphere Replication Appliance.

Suppose you have everything ready in place, let’s see how to configure your on-prem to Cloud DR.

6: vSphere Replication can be used for Site to Site Replication or for replicating VM’s to cloud provider. in this post I am going to demonstrate how to configure vCloud Air as endpoint in vSphere Replication.

Login to web-client of your on-prem vCenter Server and navigate to Home > vSphere Replication and click on Manage tab. Click on the Icon marked in yellow in below screenshot to add a cloud endpoint.

dr2c-4

7: A new wizard will be launched where you have to define the URL of the cloud provider. Name of your organization, and credentials to authenticate against vCloud Air portal. The credentials which you use must have access to your Org in vcloud Air.

dr2c-5

8: Accept the SSL certificate present by clicking yes.

dr2c-6

9: Select the Org vDC where you want to replicate your VM’s.

dr2c-7

10: On ready to Complete page hit finish to complete your configuration.

dr2c-8

11: You will see a task triggered in recent tasks pane indicating your configuration is completed.

dr2c-10

12: Now under your target sites in vSphere Replication, you will see your Org vDC added as endpoint (target) and also a warning “Missing network settings”. Dont worry about this warning.

dr2c-11

13: Right click on “Missing Target Network” and select configure target networks option.

dr2c-12

14: Select the Recovery and Test Network and hit Next.

dr2c-13

15: Map the recovery network in your cloud to network in your on-prem network and click on Add mappings.

dr2c-14

16: Do the same for the test network and hit next.

dr2c-16

17: On Ready to complete page, review your settings and hit finish.

dr2c-17

18: Now you are ready to replicate workloads from your on-prem datacenter to vCloud Air

dr2c-20.PNG

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in vCloud Air, Vmware, vSphere Replication | 1 Comment

Unable to start vApp-Invalid vApp properties:Invalid property value size

I recently deployed vSphere replication appliance in vCloud Director and while powering it on I was facing one error

Unable to start vAPP- Invalid vApp properties:Invalid property value size

Due to this power on operation on vApp was failing time and again.

I checked the vCD logs and did not found any error messages for my vApp. All I got was few debug messages:


<em>2016-05-29 09:56:25,597 | INFO | nf-activity-pool-272 | VC20VirtualServer | Created device change list for [name = vrs01 (3fd990d6-6ee2-4618-8446-9067f8ecdd02), valref = [vcId=03dc414f-6385-43e5-b95f-1d7ca8db3aa8, moref=vm-5205]] for synchronizing nics. | requestId=cf0ea3dc-8541-4d5a-b37b-fad3b3cde71b,request=POST https://x.x.x.x/cloud/amf,requestTime=1464515782276,remoteAddress=172.20.1.2:58308,userAgent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML...,accept=*/* method=vAppService.updateVAppVmWithStorageClass vcd=1d114aae-e514-4fc6-a30d-8d5fc7c8c286,task=1fb5f553-e269-4a76-8632-ccf9bb1c5b9d activity=(com.vmware.vcloud.backendbase.management.system.TaskActivity,urn:uuid:1fb5f553-e269-4a76-8632-ccf9bb1c5b9d) activity=(com.vmware.vcloud.fabric.net.activities.ConstituteNetworkedVmActivity,urn:uuid:56dc4e55-a460-4ac9-9dab-7eb5f76e5248)</em>

<em>2016-05-29 09:56:25,599 | INFO | nf-activity-pool-272 | VC20VirtualServer | Invoking reconfigure vm [name = vrs01 (3fd990d6-6ee2-4618-8446-9067f8ecdd02), valref = [vcId=03dc414f-6385-43e5-b95f-1d7ca8db3aa8, moref=vm-5205], changeVersion 2016-05-29T09:52:33.186794Z] for synchronizing nics. | requestId=cf0ea3dc-8541-4d5a-b37b-fad3b3cde71b,request=POST https://x.x.x.x/cloud/amf,requestTime=1464515782276,remoteAddress=172.20.1.2:58308,userAgent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML...,accept=*/* method=vAppService.updateVAppVmWithStorageClass vcd=1d114aae-e514-4fc6-a30d-8d5fc7c8c286,task=1fb5f553-e269-4a76-8632-ccf9bb1c5b9d activity=(com.vmware.vcloud.backendbase.management.system.TaskActivity,urn:uuid:1fb5f553-e269-4a76-8632-ccf9bb1c5b9d) activity=(com.vmware.vcloud.fabric.net.activities.ConstituteNetworkedVmActivity,urn:uuid:56dc4e55-a460-4ac9-9dab-7eb5f76e5248)</em>

<em>2016-05-29 09:56:26,617 | DEBUG | val-activity-pool-273 | TaskManager | result null (or not a moref type) for task [moref=task-55625, state=SUCCESS, taskName=ReconfigVM_Task, progress=null, entityName=vrs01 (3fd990d6-6ee2-4618-8446-9067f8ecdd02)] when waiting for inventory update | requestId=cf0ea3dc-8541-4d5a-b37b-fad3b3cde71b,request=POST https://x.x.x.x/cloud/amf,requestTime=1464515782276,remoteAddress=172.20.1.2:58308,userAgent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML...,accept=*/* method=vAppService.updateVAppVmWithStorageClass vcd=1d114aae-e514-4fc6-a30d-8d5fc7c8c286,task=1fb5f553-e269-4a76-8632-ccf9bb1c5b9d activity=(com.vmware.vcloud.backendbase.management.system.TaskActivity,urn:uuid:1fb5f553-e269-4a76-8632-ccf9bb1c5b9d) activity=(com.vmware.vcloud.fabric.net.activities.ConstituteNetworkedVmActivity,urn:uuid:56dc4e55-a460-4ac9-9dab-7eb5f76e5248) activity=(com.vmware.vcloud.val.internal.impl.ReconfigureVmActivity,urn:uuid:0b07e9fd-fb2c-4926-95d1-22f063ca77db)</em>

<em>2016-05-29 09:56:27,163 | DEBUG | backend-activity-pool-46 | JobString | Job object - Object : vrs01(com.vmware.vcloud.entity.vm:3fd990d6-6ee2-4618-8446-9067f8ecdd02) operation name: VAPP_UPDATE_VM | requestId=cf0ea3dc-8541-4d5a-b37b-fad3b3cde71b,request=POST https://x.x.x.x/cloud/amf,requestTime=1464515782276,remoteAddress=172.20.1.2:58308,userAgent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML...,accept=*/* method=vAppService.updateVAppVmWithStorageClass vcd=1d114aae-e514-4fc6-a30d-8d5fc7c8c286,task=1fb5f553-e269-4a76-8632-ccf9bb1c5b9d activity=(com.vmware.vcloud.backendbase.management.system.TaskActivity,urn:uuid:1fb5f553-e269-4a76-8632-ccf9bb1c5b9d)</em>

This issue generally occurs when you are deploying pre-built ovf templates like vCAC appliance or vSphere Replication appliance or appliance from any other vendors in vCD. The reason of this error is there are some configurable parameters associated with vApps which needs a value before you attempt to power-on a VM. These parameters can be found on guest os properties as shown below:

vapp

In my case password field was left blank which was preventing the vApp from getting powered on. Once I supplied the password, the vApp booted up without any further issues.

If you have vCD in your environment or if you are running your VM’s in vCloud Air and face the same issue, try following steps:

Check the properties of each VM in the vApp. When appliances are deployed in vCloud Director you will need to fill in the guest properties prior to starting the vApp/VM. If required properties are missing in order to configure the VM, the start up process will fail due to null values.

  1. Right-click the VM and click Properties.
  2. Click the “Guest Properties” tab.
  3. Enter the property requirements for each appliance and click OK.

Once you complete the steps that are highlighted in red for each appliance the vApp should start.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable:)

Posted in vCloud Director, Vmware | Leave a comment

vCloud Air: External Catalog Publishing

I am running my lab on top of vCloud Air and I have 2 organizations created in vCloud Air, one in Australia and one in US. I have all lab components running in Australia location and was setting another environment in US which will be exact replica of Australia.

I have my vApp templates and ISO media files uploaded in catalog at Australia location, and in order to setup everything from scratch, I needed to upload everything again in US location.

I was looking for a solution where I can share resources from one location to another in vCloud Air and then came across a cool concept of “External Catalog Publishing”. This feature was introduced in vCloud Director 5.5

Let’s see how to share contents from one Datacenter to another within vCloud Air.

The very first requirement for this is that your Org should be enabled for either Publish or Subscribe to a catalog. You need this to be enabled on both org (source and destination datacenter)

To do so, login to vCloud Director and select your organization and right click on it to open the properties of the organization.

cat-1

Select the “Allow sharing catalogs” and “Allow publishing external catalogs” option and hit OK.

cat-2

Navigate to your catalogs and select the catalog which you want to share to destination location. Right click on your catalog and select Publish/Subscribe Settings.

cat-3

Go to External Publishing tab and select “Enable Publishing”. Optionally supply a password for sharing. You  need to enter this password when you will be subscribing to this catalog at the destination org. Hit OK to finish the task.

cat-4

Once again open the properties of catalog and navigate to External Publishing tab. You will see a URL generated there. Copy this URL by clicking on Copy Link. You need to supply this URL at the destination while creating a new catalog.

cat-5

on your destination datacenter, create a new catalog in your org. Go to Catalogs tab and click on green ‘+‘ button to add a new catalog.

cat-6

Provide a name for the catalog and select Subscribe to external catalog and paste the link of the URL which you copied in above steps. Also supply the password which you entered while allowing Publish Catalog at your source datacenter.

If you want all vApp templates/Iso files should be downloaded from source catalog to destination catalog, check mark the “Automatically download content” box. Hit next for remaining steps of creating catalogs.

cat-9

Now select your catalog and click on vApp Templates. You will see all your templates getting synched at your destination datacenter.

cat-10

If you have any iso files at your source catalog, those will be synch’ed too

cat-11

The only gotcha in above method is size of transfer area on vCloud’s Cells.

During the synchronization, the templates are first exported to vCloud’s Cell transfer area then copied to the datastore of the destination. Your transfer area should be big enough to accommodate all your vApp templates/ISO files.

In my case I had plenty of space available in transfer area on my vcloud cell:

[root@vcd-a transfer]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
12G 6.5G 4.5G 60% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
/dev/sda1 485M 32M 428M 7% /boot
vcd-nfs:/share/my-share 493G 8.8G 459G 2% /opt/vmware/vcloud-director/data/transfer

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable:)

Posted in vCloud Air, Vmware | 2 Comments

vRealize Log Insight: Part-2: Installation/Configuration

In last post Log Insight Introduction of this series we had a look on what is vRealize Log Insight and where did it came from. What is the advantage of using it and how it fit together with other VMware components.

In this post we are going to see basic installation/configuration of the Log Insight appliance.

vRealize Log Insight is available in the form of OVA file and you can evaluate the product by registering and downloading it from here

You can choose to deploy the downloaded ova file as it is or can convert it to ovf file using ovftool. You can use the command shown in following example to do so:

PS C:\Users\Administrator> ovftool “C:\Users\Administrator\Downloads\VMware-soft\OVA Files\Log-Insight-3.3.1.ova” “C:\Us
ers\Administrator\Downloads\VMware-soft\OVA Files\Log-Insight-3.3.1.ovf”

Output:

=======================================================
Opening OVA source: C:\Users\Administrator\Downloads\VMware-soft\OVA Files\Log-Insight-3.3.1.ova
Opening OVF target: C:\Users\Administrator\Downloads\VMware-soft\OVA Files\Log-Insight-3.3.1.ovf
Writing OVF package: C:\Users\Administrator\Downloads\VMware-soft\OVA Files\Log-Insight-3.3.1.ovf
Transfer Completed
Warning:
– ExtraConfig option ‘keyboard.typematicmindelay’ is not allowed, will skip it.
– No manifest entry found for: ‘VMware-vRealize-Log-Insight-3.3.1-3644329-system.vmdk’.
– No manifest entry found for: ‘VMware-vRealize-Log-Insight-3.3.1-3644329-cloud-components.vmdk’.
– No manifest file found.
Completed successfully
Once the OVA file is converted into OVF file, you can import and deploy it in vCenter Server. The import process is very simple and I am not covering the steps for it. Once the ovf file is deployed (with all configuration) as VM and powered-on you will see following screen from vCenter console of the VM.

ls-1

Initial configure of Log Insight Appliance

Open a web-browser of your choice and enter http://Log-Insight_FQDN/ and hit enter to start the configuration wizard.

You will be presented with Welcome screen. Hit Next to continue.

ls-2

since this is the first deployment, click on Start New Deployment.

ls-3

Enter an email address for the admin account and also a password. Click Save and Continue

ls-4

On the General Configuration page, enter an email address that will receive system notifications.

System notification emails are used to send information about important system events. This information is not readily displayed in the web UI and it is highly recommended that you configure this field.

If you dont want to join customer experience improvement program you can leave the send weekly trace data option checkbox unchecked and hit Save and Continue.

ls-5

You can choose to sync the server time with NTP servers or with the ESXi Host.

Note: If you are going to use NTP servers, be sure to validate that they are working by using the Test button. Log Insight does not validate the NTP servers specified or confirm that time can be collected from the sources specified.

In my lab I chose NTP server option and configured my NTP server IP for time synchronization. Hit Save and continue.

ls-6

Enter the SMTP server settings and a sender email address so you can receive notifications from Log Insight. Once entered you can send a quick Test Email to confirm the settings are correct.

You can also choose to skip this. Click Skip or Save and Continue depending on how you w

ant this section configured.

ls-7

Hit finish to complete the setup process.The message says ‘All done!’ but it’s lying to you and several other config is needed

ls-8

At this point you can choose to ingest syslog data from any source, agents installed directly on a linux or windows server to gather the logs (you can download and install the agents also from the link) and integrate with vSphere.

On Ready to Ingest Data page, click on vSphere Integration to add your Esxi host/vCenter Server to log insight.

 

ls-9

You will be directed to an administration screen where it will automatically select vSphere under Integration. Enter the hostname for vCenter that you want to integrate to and enter a valid username and password. Click on test connection to verify the credentials work. Click Save.

Note: You can add multiple vCenters if you have multiple Log Insight appliances deployed.

ls-10

Click on Advanced options to see if your Esxi hosts have been configured by Log insight appliance to collect logs from them.

ls-12

With this the basic installation of Log Insight have been completed. There are several other options with which you can play around such as configuring vRealize Operations Manager or integrating 3rd party devices to collect logs.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

 

Posted in Vmware | Leave a comment

vRealize Log Insight: Part-1: Introduction

This week I decided to test my hands on the log management tool from VMware i.e vrealize Log Insight. We have this tool in our production environment and have to jump into analysis of Alerts received from this tool. Due to lack of knowledge troubleshooting sometime becomes very difficult so I decided to deploy this in my lab and play around options.

What is vRealize Log Insight?

vRealize Log Insight is a log management tool that aggregates logs from various systems into one place.The cool aspect of Log Insight is that it supports the collection of logs either from VMware infrastructure (i.e. ESXi hosts) either from physical infrastructure (i.e. physical servers, physical switches, etc.) either from application (i.e. virtual/physical machines guest operating systems).

With the introduction of vCenter Log Insight (Later renamed as vRealize Log Insight) VMware joined the already crowded log analytics market. There are several other products in market such as Splunk, LogRhythm, Sumo Logic and Loggly which are used for data center log consolidation and analysis. The advantage of Log Insight is its seamless integration with other VMware products.

What is the advantage of using Log Insight?

Log Insight is used for operational analytics in traditional data center and cloud environments. It has the ability to discover emerging patterns and guide administrators to the root cause of problems.

Log Insight makes it possible to do all sorts of queries and analytics on the data retrieved. Log Insight is just not for vSphere or other Vmware products, but can interact with other products such as Microsoft OS, SQL Server, IIS Server, Sharepoint, the .NET CLR, networking/storage products from Cisco (ASA, Nexus), Arista, Brocade, EMC (VNX), NetApp, Synology and even for compute products from VCE and Cisco (UCS) via Management packs for these products.

Loginsight-ingress

As of now Log Insight can be integrated with:

1: vSphere (Esxi + vcenter)
2: vRealize Automation,
3: vRealize Operations,
4: vCloud Director
5: NSX
6: Horizon View

Where did Log Insight come from?

As we all know VMware is known for acquiring the small companies and then re-design and rebrand the product under VMware name. Log Insight is no exception to this and  is a result of VMware’s acquisition of Pattern Insight in August 2012.

The current version of Log Insight is 3.3.1 and is available for download in form of ova file from vmware.com.

How Log Insight works?

Log Insight is deployed as a virtual appliance in vSphere Infrastructure. The virtual appliance contains the Log Insight application installed on a SUSE Linux operating system and database. The Log Insight database is a special designed database and contains something called “just-in-time schema” which enables it to ingest syslog data from hundreds of syslog agents and store the unstructured data without modifying the database.

Log Insight appliance contains the customizable dashboards which gives a visual representation of what’s going on with infrastructure. Dashboard contains custom graphs of log events that are coming from different pieces of infrastructure.

If you want to know more about Log Insight product, I would encourage you to read following blogs:

1: Log insight FAQ’s

2: What’s new in Log Insight 3.3

In next post of this series we will look into Installation and Configuration of Log Insight appliance. Stay Tuned !!!

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable

Posted in Vmware | 1 Comment

Unregistering vSphere Replication Plugin from vCenter

This week I was having some trouble with vSphere Replication appliances in my lab and decided to rip apart my replication setup. I logined to my VR appliance VAMI address and unregistered VRMS from vCenter Server. Deleted my replication appliance in order to deploy it from scratch.

To my surprise vSphere Replication plugin was still present in my vCenter Server, even after I logged out and logged in back to webclient.

mob-0

I tried to reboot my vCenter Server to see if it clears the plugin, but that trick didn’t worked for me.

Now the only option left was to uninstall the plugin was using vSphere MOB. If you are like me and dont know much about MOB then I would recommend reading this blogpost.

I followed following steps to successfully remove replication plugin from my vCenter Server.

1; Open your favourite browser and point it to URL https://vCenter-FQDN/mob and login.

2: Click on content.

mob-1

3: Click on Extension Manager to open list of installed plugins.

mob-2

4: Search and click on the plugin you want to uninstall. The name for vSphere replication plugin is com.vmware.vcHMS. I was not sure if it is the right plugin (however since VR applaince has HMS service running inside it, it gave me a clue).

mob-3

5: If you are unsure about if the selected plugin is correct or not, right click on it and open it in new tab. Click on description and you will see from where this plugin is coming from. As you can see in below screenshot it shows “VR Management”, so yeah my guess was right.

mob-4

6:  After clicking on plugin which you want to uninstall, note down the plugin key id which will be used to remove the plugin:

mob-5

7: Now return to previous page and locate “Unregister Extension” and click on that option.

mob-6

A new window will be launched. Enter the plugin key id which we noted in step 6 and click on the “Invoke Method” to remove the plugin.

 

mob-8.PNG

Now the plugin has been uninstalled. If you are still login’ed to webclient then logoff and log back in to confirm plugin has disappeared from vCenter. In rare case restart of web-client is required for changes to take effect. Fortunately in my case logoff and login just worked fine. I was no longer seeing vSphere Replication plugin.

mob-9.PNG

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable

Posted in Vmware, vSphere Replication | Leave a comment

LUN Zoning in Openfiler: Presenting a subset of Luns to Esxi hosts

I am currently working on Disaster Recovery  in my lab and as a result I have setup 2 sites: Primary and DR site. On both site I am having one vCenter and 2 Esxi hosts.

For centralized storage I am using openfiler v2.99 in my lab and I have created 2 LUN’s (100 GB each) on openfiler which are presented to Esxi hosts at my primary site.

1

If you are new to openfiler then I would recommend reading this document which I uploaded on VMTN sometime back.

I was looking for a way to create 2 more LUN’s and expose those LUN’s only to Esxi hosts that are on my DR site. I did not wanted that all my Esxi host should have visibility to all LUN’s that are created on openfiler. In short I was looking for LUN Zoning kind of things with openfiler in my home lab.

I have never done this and did not had much Idea on how to achieve that. I started searching google for this but unfortunately there is very little help on this topic available out on internet. I found a cool Blog post by Mike Brown who has demonstrated how to achieve that, but I felt his blog to be a bit complex for newbies so I decided to write my own post on this.

Before diving into how to achieve this in Lab, I would like to first explain my infrastructure a bit:

Primary Site:

1 vCenter Server (vcentersrv01.alex.local, Management Network: 192.168.109.20)

2 Esxi hosts (optimus.alex.local & megatron.alex.local, Management Network: 192.168.109.6/7)

1 openfiler (openfiler.alex.local, Management Network: 192.168.109.4).

DR Site:

1 vCenter Server (vcentersrv02.alex.local, Management Network: 192.168.109.21)

2 Esxi hosts (harry.alex.local & ron.alex.local, Management Network: 192.168.109.11/12)

my DR site currently has no shared storage.

Enough of background now. Let’s jump into lab and see how to achieve LUN zoning with openfiler:

1: Add a new disk to your openfiler server.

If you are running openfiler as VM and have added the new disk as SCSI then run below command to get that disk identified by openfiler without rebooting the appliance:

[root@openfiler ~]# echo “- – -” > /sys/class/scsi_host/host0/scan

2: Navigate to systems tab and ensure that the network on which your Esxi hosts are residing is allowed in openfiler.

openfiler-1

Note: If you have hosts residing on different subnets then make sure all subnets are added here and your openfiler appliance have access to all subnets.

3: Navigate to Volumes tab and click on block devices to see the newly added disk. You will see it does not contain any partitions yet. Click on the disk to create a new partition.

openfiler-2

4: Select partition type as Physical volume and click on Create.

openfiler-3

5: Click on Volume Groups to create a new vol group for this disk.

openfiler-4

Provide a name for the volume group and select the disk  to add to this volume group and click on “Add Volume Group”

openfiler-5

6: Now click on Add Volume from right hand side menu to add a volume in the Volume Group created in above step.

openfiler-6.PNG

7: From Select Volume Group select the newly created VG

openfiler-7.PNG

Provide a name and description  for the Volume and select the size. Under Filesystem select Block(iSCSI,FC) option and hit create button.

openfiler-8

Post creation of volume, verify the details such as Volume size etc.

openfiler-9

8: Next is to create a new iSCSI target.

The approach here is to create different target and map a subset of LUN’s to each target and then expose only a particular target to the Esxi host. Click on ISCSI targets from right hand side menu and click on Add to add a new target.

openfiler-11

Current target in my lab has following name and to this target 2 LUN’s are mapped as explained earlier in the post.

openfiler-13

On selecting the existing target and moving on to LUN Mapping tab, I can see the newly created LUN (iSCSI-3) appears in the list but I am not going to map this LUN to current target as it is exposed to Esxi hosts on my primary site.

openfiler-14

I created a new target by name “iqn.2006-01.com.openfiler-DR:tsn.877ef7dfaa2b”. Notice the name, I have put DR after openfiler in name so as to make things simple and help me to identify that this target will be only mapped to my DR site. Make a note of this name as we will e needing this while configuring targets on esxi hosts.

As of now this target do not have any LUN’s mapped to it. I am going to map iSCSI-3 to this target.

openfiler-15

Once the LUN was mapped to the newly created target, configuration looks like as shown below

openfiler-16

9: Verify that your subnet is allowed to access this target.

openfiler-17.PNG

10: Add a new software iSCSI adapter to Esxi host to access the targets on openfiler devices. Open properties of newly added iSCSI adapter to configure targets.

 

11: Important: Add the newly added target as Static discovery and not as dynamic discovery. If you select dynamic discovery and provide the IP address of then openfiler applaince here, it is going to discover both of your traget (newly created one and existing one) and as a result all your LUN’s (3 in my case) will start appearing on Esxi host.

On selecting Static Discovery click on Add button, in the newly launched window provide IP/FQDN of your openfiler appliance with 3260 as port and under iSCSI target name paste the name of target which we created in Step 8. Hit OK once you are done with configuration.

openfiler-19.PNG

11: Perform a rescan of iSCSI adapter and you will see one connected target.

openfiler-24.PNG

12: Create Datastore

Go to Storage tab on your Esxi host and click on Add Storage.

openfiler-26.PNG

Select the appropriate LUN id to create datastore on LUN. While writing this post I quickly added a new 50 GB LUN on openfiler and mapped it to the target created for DR site and that is why I am seeing 2 LUN’s here.

openfiler-27

13: Verify configuration on Esxi hosts. As you can see Esxi hosts on my Primary and DR site are mounting different LUN’s.

2

3

PS: The only configuration change which I did not demonstrated here is that on my Primary Site I removed the targets from dynamic discovery(which I had done at time of building my lab) and added it again as static discovery.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

 

Posted in Vmware | Leave a comment