Archives For Sysadmin

Fedora 22 was released a few months ago and amongst many new features it came with a replacement for yum as package manager called dnf, or DaNdiFied YUM, oh yes yum is still around but it is now considered legacy software. Also DNF will become in the near future the default package manager for RHEL and CentOS so it is for the best that you get familiarized with it sooner than later.

DNF Commands

The first thing you need to understand about dnf is that many commands are basically still the same but there are differences. Package management commands can be executed with almost the same syntax previously used with yum.

Search for a package,

[jrey@fed22-srv ~]$ sudo dnf search htop
Last metadata expiration check performed 1:25:54 ago on Mon Oct 5 23:47:45 2015.
=================================== N/S Matched: htop ====================================
htop.x86_64 : Interactive process viewer
php-lightopenid.noarch : PHP OpenID library
[jrey@fed22-srv ~]$

Install a package.

[jrey@fed22-srv ~]$ sudo dnf install htop

Remove a package.

[jrey@fed22-srv ~]$ sudo dnf remove htop

Get information about a package

[jrey@fed22-srv ~]$ sudo dnf info htop
Last metadata expiration check performed 1:47:13 ago on Mon Oct 5 23:47:45 2015.
Available Packages
Name : htop
Arch : x86_64
Epoch : 0
Version : 1.0.3
Release : 4.fc22
Size : 91 k
Repo : fedora
Summary : Interactive process viewer
URL : http://hisham.hm/htop/
License : GPL+
Description : htop is an interactive text-mode process viewer for Linux, similar to
 : top(1).

[jrey@fed22-srv ~]$

Group and repository management commands are still the same as well.

[jrey@fed22-srv ~]$ sudo dnf repolist

Querying the available repositories for a specific command.

[jrey@fed22-srv ~]$ sudo dnf repoquery --whatprovides htop
Last metadata expiration check performed 1:54:52 ago on Mon Oct 5 23:47:45 2015.
htop-0:1.0.3-4.fc22.x86_64
[jrey@fed22-srv ~]$

dnf comes with some powerful capabilities like history query.

[jrey@fed22-srv ~]$ sudo dnf history list
Last metadata expiration check performed 11 days, 19:14:54 ago on Wed Oct 7 02:56:21 2015.
ID | Command line             | Date a           | Action  | Altere
-------------------------------------------------------------------------------
 9 | history undo 8           | 2015-10-06 01:53 | Install | 1 
 8 | erase htop               | 2015-10-06 01:28 | Erase   | 1 
 7 | install htop -y          | 2015-10-06 01:28 | Install | 1 
 6 | remove htop              | 2015-10-06 01:14 | Erase   | 1 
 5 | install htop             | 2015-10-06 01:14 | Install | 1 
 4 | install make gcc kernel- | 2015-09-30 16:21 | Install | 9 
 3 | update                   | 2015-09-30 15:43 | I, U    | 112 
 2 | update                   | 2015-09-16 11:45 | I, O, U | 297 
 1 |                          | 2015-09-16 10:59 | Install | 658 EE
[jrey@fed22-srv ~]$

This can be specially helpful if you need to rollback a change, like clean up dependencies after uninstalling a package or reinstall a package.

[jrey@fed22-srv ~]$ sudo history undo 8

You can also look for duplicated within the installed ones.

[jrey@fed22-srv ~]$ sudo dnf repoquery --duplicated
Last metadata expiration check performed 0:30:42 ago on Tue Oct 6 02:48:41 2015.
kernel-core-0:4.0.4-301.fc22.x86_64
kernel-core-0:4.1.6-201.fc22.x86_64
kernel-core-0:4.1.7-200.fc22.x86_64
kernel-modules-0:4.0.4-301.fc22.x86_64
kernel-modules-0:4.1.6-201.fc22.x86_64
kernel-modules-0:4.1.7-200.fc22.x86_64
[jrey@fed22-srv ~]$

Retrieve all available packages providing a specific software of capability.

[jrey@fed22-srv ~]$ sudo dnf repoquery --whatprovides curl
Last metadata expiration check performed 0:38:00 ago on Tue Oct 6 02:48:41 2015.
curl-0:7.40.0-3.fc22.x86_64
curl-0:7.40.0-7.fc22.x86_64
[jrey@fed22-srv ~]$

This is a very basic introduction to dnf capabilities but hopefully you have been able to get how it works. My advice is to review DNF documentation for all the details.

The Photon Connection

VMware Photon comes with tdnf (Tiny DNF); this is a development by VMware that comes with compatible repository and package management capabilites. Not every dnf command is available but the basic ones are there.

Package installation and updates.

Screen Shot 2015-10-11 at 19.41.00

Repository management.

Screen Shot 2015-10-11 at 18.54.47

In the future if I find the time I’ll write a new post with some advanced examples of dnf commands. Comments are welcome.

Juanma.

FirewallD, or Dynamic Firewall Manager, is the replacement for the IPTables firewall in Red Hat Enterprise Linux. The main improvement over IPTables is the capacity to make cahnges without the need to restart the whole firewall service.

FirewallD was first introduced in Fedora 18 and has been the default firewall mechanism for Fedora since then. Finally this year Red Hat decided to include it in RHEL 7, and of course it also made its way to the different RHEL clones like CentOS 7 and Scientific Linux 7.

Checking FirewallD service status

To get the basic status of the service simply use firewall-cmd --state.

[root@centos7 ~]# firewall-cmd --state
running
[root@centos7 ~]#

If you need to get a more detailed state of the service you can always use systemctl command.

[root@centos7 ~]# systemctl status firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2014-11-19 06:47:42 EST; 32min ago
 Main PID: 873 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─873 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Nov 19 06:47:41 centos7.vlab.local systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 19 06:47:42 centos7.vlab.local systemd[1]: Started firewalld - dynamic firewall daemon.
[root@centos7 ~]#

To enable or disable FirewallD again use systemctl commands.

systemctl enable firewalld.service
systemctl disable firewalld.service

Managing firewall zones

FirewallD introduces the zones concept, a zone is no more than a way to define the level of trust for a set of connections. A connection definition can only be part of one zone at the same time but zones can be grouped  There is a set of predefined zones:

  • Public – For use in public areas. Only selected incoming connections are accepted.
  • Drop – Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.
  • Block – Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated within this system are possible.
  • External – For use on external networks with masquerading enabled especially for routers. Only selected incoming connections are accepted.
  • DMZ – For computers DMZ network, with limited access to the internal network. Only selected incoming connections are accepted.
  • Work – For use in work areas. Only selected incoming connections are accepted.
  • Home – For use in home areas. Only selected incoming connections are accepted.
  • Trusted – All network connections are accepted.
  • Internal – For use on internal networks. Only selected incoming connections are accepted.

By default all interfaces are assigned to the public zone. Each zone is defined in its own XML file stored in /usr/lib/firewalld/zones. For example the public zone XML file looks like this.

root@centos7 zones]# cat public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="dhcpv6-client"/>
</zone>
[root@centos7 zones]#

Retrieve a simple list of the existing zones.

[root@centos7 ~]# firewall-cmd --get-zones
block dmz drop external home internal public trusted work
[root@centos7 ~]#

Get a detailed list of the same zones.

firewall-cmd --list-all-zones

Get the default zone.

[root@centos7 ~]# firewall-cmd --get-default-zone
public
[root@centos7 ~]#

Get the active zones.

[root@centos7 ~]# firewall-cmd --get-active-zones
public
  interfaces: eno16777736 virbr0
[root@centos7 ~]#

Get the details of a specific zone.

[root@centos7 zones]# firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eno16777736 virbr0
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

[root@centos7 zones]#

Change the default zone.

firewall-cmd --set-default-zone=home

Interfaces and sources

Zones can be bound to a network interface and to a specific network addressing or source.

Assign an interface to a different zone, the first command assigns it temporarily and the second makes it permanently.

firewall-cmd --zone=home --change-interface=eth0
firewall-cmd --permanent --zone=home --change-interface=eth0

Retrieve the zone an interface is assigned to.

[root@centos7 zones]# firewall-cmd --get-zone-of-interface=eno16777736
public
[root@centos7 zones]#

Bound the zone work to a source.

firewall-cmd --permanent --zone=work --add-source=192.168.100.0/27

List the sources assigned to a zone, in this case work.

[root@centos7 ~]# firewall-cmd --permanent --zone=work --list-sources
172.16.10.0/24 192.168.100.0/27
[root@centos7 ~]#

Services

FirewallD can assign services permanently to a zone, for example to assign http service to the dmz zone. A service can be also assigned to multiple zones.

[root@centos7 ~]# firewall-cmd --permanent --zone=dmz --add-service=http
success
[root@centos7 ~]# firewall-cmd --reload
success
[root@centos7 ~]#

List the services assigned to a given zone.

[root@centos7 ~]# firewall-cmd --list-services --zone=dmz
http ssh
[root@centos7 ~]#

Other operations

Besides of Zones, interfaces and Services management FirewallD like other firewalls can perform several network related operations like masquerading, set direct rules and manage ports.

Masquerading and port forwading

Add masquerading to a zone.

firewall-cmd --zone=external --add-masquerade

Query if masquerading is enabled in a zone.

[root@centos7 ~]# firewall-cmd --zone=external --query-masquerade
yes
[root@centos7 ~]#

You can also set port redirection. For example to forward traffic originally intended for port 80/tcp to port 8080/tcp.

firewall-cmd --zone=external --add-forward-port=port=80:proto=tcp:toport=8080

A destination address can also bee added to the above command.

firewall-cmd --zone=external --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=172.16.10.21

Set direct rules

Create a firewall rule for 8080/tcp port.

firewall-cmd --direct --add-rule ipv4 filter INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT

Port management

Allow a port temporary in a zone.

firewall-cmd --zone=dmz --add-port=8080/tcp

Hopefully you found the post useful to start working with FirewallD. Comments are welcome.

Juanma.

Being used to have Cockpit in my Fedora 21 Server VMs I decided that having it also on my CentOS machines would be awesome, unfortunately I quickly found that Cockpit was not available in CentOS repositories. Of course I knew that Cockpit comes installed and enabled by default in CentOS 7 Atomic host image so I figured out that those packages had to be hidden in some Atomic related repo.

After looking a bit I finally found in GitHub the sig-atomic-buildscripts repository that belongs to CentOS Project. This repository contains several scripts and files intended to build your own CentOS Atomic host including virt7-testing.repo, the Yum repository file needed for Cockpit.

Clone the GutHub repository.

git clone https://github.com/baude/sig-atomic-buildscripts

Copy virt7-testing.repo file to /etc/yum.repos.d and install Cockpit.

yum install cockpit

Enable Cockpit service.

[root@webtest ~]# systemctl enable cockpit.socket
ln -s '/usr/lib/systemd/system/cockpit.socket' '/etc/systemd/system/sockets.target.wants/cockpit.socket'
[root@webtest ~]#

Add Cockpit to the list of trusted services in FirewallD.

[root@webtest ~]# firewall-cmd --permanent --zone=public --add-service=cockpit
success
[root@webtest ~]#
[root@webtest ~]# firewall-cmd --reload
success
[root@webtest ~]#
[root@webtest ~]# firewall-cmd --list-services
cockpit dhcpv6-client ssh
[root@webtest ~]#

Start Cockpit socket.

systemctl start cockpit.socket

Do no try to access Cockpit yet, there is an issue about running Cockpit on stock CentOS/RHEL 7. To be able to start it we need first to modify the service file to disable SSL.Edit file /usr/lib/systemd/system/cockpit.service and modify ExecStart line to look like this.

ExecStart=/usr/libexec/cockpit-ws --no-tls

I know this procedure will invalidate Cockpit for a production environment in RHEL7 at least for now but this is for my lab environment and I can live with it.

Reload systemd.

systemctl daemon-reload

Restart Cockpit.

systemctl restart cockpit

Access Cockpit web interface, login as root and have fun :-)

Screen Shot 2015-01-09 at 01.57.51

Juanma.

 

fedora_infinity_140x140Cockpit is a new web based server manager to administer Linux server, it will provide the system administrators with a user friendly interface to manage their Linux servers, it includes multiserver managing capacity and more importantly it will create no interference or disconnection between the tasks done from the web and from the command line. This last feature is specially useful

By default Cockpit, stable version, comes installed and enabled in Fedora 21 Server. It also can be found in CentOS/RHEL 7 Atomic, Fedora 21 Atomic and Fedora 21 Cloud, and there are plans in the near future to support Arch Linux.

Lets review now some of the features of Cockpit, as said before multiple servers can be managed from the same Cockpit instance.

Screen Shot 2014-12-31 at 19.26.00

Once you access one of managed nodes it will present general overview of the server with real-time charts of CPU, Memory, Disk I/O and Network Traffic.

Screen Shot 2014-12-31 at 19.37.53

On the left pane there are a series of actionable items that will give you access to the different subsystems of the node like Networking, Storage, User Accounts and even the status of the Docker containers running on the server, if the Docker service has been enabled.

System services view.

Screen Shot 2014-12-31 at 19.52.53

When a process is selected Cockpit will display its details.

Screen Shot 2015-01-08 at 12.11.27

Networking area displays traffic for the selected interface, the journal of the networking system and even allows you to create a new bond interface, a new bridge or add a new VLAN tag to the interface.

Screen Shot 2014-12-31 at 19.53.18

The Storage view will display similar info for the disks, and will display detailed information for each of them, review the LVM configuration of the server and perform different storage related operations.

Screen Shot 2014-12-31 at 19.53.45

Journal view lets you review systemd journal. You can go back seven days into the log and filter on the type of messages.

Screen Shot 2014-12-31 at 19.54.29

After using Cockpit for some time in my lab I can say that I genuinely love it, the interface is pretty fast, it uses systemd for everything and it does not interface with my console-based admin habits, on the contrary is a great complement to them.

Juanma.

A question I’ve heard a few times, what are the command equivalencies between a standard Open vSwitch, running inside a Linux box, and the NSX vSwitch running inside ESXi? I have written this post to clarify this a bit.

There are four commands in NSX CLI that have equivalencies in the OVS world:

NVS Command OVS Command
nsx-dbctl ovs-vsctl
nsx-dpctl ovs-dpctl
nsx-appctl ovs-appctl
nsx-flowctl ovs-flowctl

nsx-dbctl

ovs-dbctl command, like its OVS equivalent ovs-vsctl, Sub-commands are the same, and for example nsx-dbctl show will produce a similar output to ovs-vsctl show.

~ # nsx-dbctl show
ec451c1a-0258-423a-b406-dec83af4b241
    Manager "ssl:192.168.110.201:6632"
        is_connected: true
    Bridge "br-vmnic1"
        fail_mode: standalone
        Port "vmk3"
            Interface "vmk3"
        Port "vmnic1"
            Interface "vmnic1"
    Bridge br-int
        Controller "ssl:192.168.110.201:6633"
            is_connected: true
        Controller "unix:ovs-l3d.mgmt"
            is_connected: true
        fail_mode: secure
        Port "vNic.3000004"
            Interface "vNic.3000004"
        Port "vNic.3000006"
            Interface "vNic.3000006"
        Port "vNic.3000005"
            Interface "vNic.3000005"
    ovs_version: "2.0.2.31704"
~ #

nsx-dpctl

nsx-dpctl command maps to ovs-dpctl and much like it allow you to manage Open vSwitch datapaths.

~ # nsx-dpctl show
system@nsx-vswitch:
        lookups: hit:1770781 missed:192476 lost:0
        flows: 14
        port 50331650: vmnic1
        port 50331651: vmk3
        port 50331652: vNic.3000004
        port 50331653: vNic.3000005
        port 50331654: vNic.3000006
~ #

nsx-appctl

nsx-appctl will allow the administrator to manage and configure OVS daemons. It maps to ovs-appctl command.

~ # nsx-appctl dpif/show
system@nsx-vswitch: hit:2230477 missed:148652
        flows: cur: 17, avg: 17, max: 33, life span: 1918447ms
        hourly avg: add rate: 66.907/min, del rate: 66.880/min
        daily avg: add rate: 43.476/min, del rate: 43.461/min
        overall avg: add rate: 60.918/min, del rate: 60.909/min
        br-int: hit:142949 missed:8461
                vNic.3000004 1/50331652: (system)
                vNic.3000005 2/50331653: (system)
                vNic.3000006 3/50331654: (system)
        br-vmnic1: hit:2087528 missed:140191
                vmk3 2/50331651: (system)
                vmnic1 1/50331650: (system)
~ #

nsx-flowctl

nsx-flowctl is the equivalent of ovs-flowctl and will allow you to manage NSX vSwich flow tables, ports, etc.

~ # nsx-flowctl show br-bond0
OFPT_FEATURES_REPLY (xid=0x3): dpid:0000725d4492c540
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 1(vmnic4): addr:00:50:56:01:08:c6
     config:     0
     state:      0
     current:    1GB-FD
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD
     speed: 1000 Mbps now, 1000 Mbps max
 2(vmnic5): addr:00:50:56:01:08:c8
     config:     0
     state:      0
     current:    1GB-FD
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD
     speed: 1000 Mbps now, 1000 Mbps max
 3(vmk3): addr:00:50:56:66:57:18
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x6): frags=normal miss_send_len=0
~ #

Courteous comments are welcome.

Juanma.

VMware has released a new vRealize Operations Manager management pack for NSX Multi-hypervisor. This new management pack will allow vROps to extend its management capabilities into any NSX-MH infrastructure.

This management pack provides a great set a features, including:

  • Operational visibility into the different NSX-MH components, from NSX Manager to Controllers, transport nodes and logical elements of the network.
  • Search and drill down functionality to help the administrator monitor the health of the NSX objects.
  • Alerts and root cause problem solving capabilities by detecting configuration, connectivity and health deficiencies into the NSX environment.
  • Report templates for NSX Multi-Hypervisor environment.

The management pack requires vRealize Operations Manager 6.0 and can be downloaded from VMware Solutions Exchange.

Installation

To install this management pack go to Administration in the left pane.

Screen Shot 2014-12-16 at 01.15.10

From there go to Solutions and on the right pane click on the plus sign to add the new management pack.

Screen Shot 2014-12-16 at 01.15.24

Browse for the pack installation file, click Upload and then click Next when the installation file is uploaded.

Screen Shot 2014-12-16 at 01.16.27

Accept the EULA and proceed to the last screen. Wait until the management pack is installed and then click Finish.

Screen Shot 2014-12-16 at 01.19.10

Configure the adapter instance

The first task is to create the credentials for the solution. Access Administration -> Credentials and create a new credential for the NSX-MH Adapter.It has to include the administration credentials for the NSX Controller, NSX Manager and vCenter Server.

Screen Shot 2014-12-16 at 02.19.17

Next access Administration -> Solutions, select the NSX-MH pack and click on the gear icon.

configure-nsx-mh

On the pop-up window enter the IP address or the FQDN for:

  • NSX Controller
  • NSX Manager
  • vCenter Server

Only the first NSX Controller is needed.

configure-nsx-mh_2

Test the connection, accept the certificates for the different components and click Save Settings. After this the adapter is configured and will start collecting data, it will take a some time until it displays data, depending on the size of the NSX environment, to have a full collection of data.

NSX-MH dashboards

Out of the box the management pack comes with three dashboards.

  • NSX-MH Main: It provides an overview of the health of the different network objects

Screen Shot 2014-12-16 at 01.29.26

  • NSX-MH Topology: Provides details about the topology of a selected object, how it connects in the networks and a view of the related alerts and metrics.

Screen Shot 2014-12-15 at 02.30.37

  • NSX-MH Object Path: This dashboard enables the administrator to visually depict a the path between two selected objects and verify how they are connected between each other and other objects.

Screen Shot 2014-12-16 at 01.32.14

Juanma.

 

In the series of posts about OpenStack and KVM we saw how to add a KVM node to NSX for multi-hypervisor environments as a transport node. In this post we will discuss how to perform the same procedure for an ESXi host.

NSX vSwitch installation

Before proceeding with the installation keep in mind that NSX vSwitch can run on an ESXi host simultaneously only with VMware Standard Switch, distributed switches are not supported.

Install the NSX vSwitch vib file using esxcli.

~ # esxcli software vib install --no-sig-check -v /tmp/vmware-nsxvswitch-2.1.3-35984-prod2013-stage-release.vib
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: VMware_bootbank_vmware-nsxvswitch_2.1.3-35984
   VIBs Removed:
   VIBs Skipped:
~ #
~ # esxcli software vib list | grep nsx
vmware-nsxvswitch              2.1.3-35984                           VMware  VMwareCertified   2014-07-13
~ #

Check that the a new virtual switch has been created on the host, don’t use esxcli but the good old esxcfg-vswitch command because for now there is no namespace available in esxcli for NSX vSwitch.

~ # esxcfg-vswitch -l
Switch Name      Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch0         1536        7           128               1500    vmnic0,vmnic1

  PortGroup Name        VLAN ID  Used Ports  Uplinks
  vMotion               0        1           vmnic0,vmnic1
  Management Network    0        1           vmnic0,vmnic1

Switch Name      Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch1         1536        6           128               1500    vmnic2,vmnic3

  PortGroup Name        VLAN ID  Used Ports  Uplinks
  vsan                  0        1           vmnic2,vmnic3

Switch Name      Num Ports   Used Ports  Uplinks
nsx-vswitch      1536        1

~ #

NSX vSwitch configuration

With NSX vSwitch installed proceed to the conifguration. First connect an uplink to the switch, this will create an NVS bridge which is the equivalent of an OVS bridge in Open vSwitch.

nsxcli uplink/connect vmnic4

Set an IP address for the uplink, this IP address will be used later to create the transport tunneling endpoint when we connect the ESXi as a transport node to NSX. You can also specify the VLAN tag by appending vlan=<vlan_id> as an additional parameter to the command.

nsxcli uplink/set-ip vmnic4 192.168.110.123 255.255.255.0

Validate that the bridge is correctly configured. Use nsxcli port/show to verify the bridge and nsxcli uplink/show for the uplink.

~ # nsxcli port/show
br-int:
-------

br-vmnic4:
----------
vmnic4
vmk3

~ #

In the uplink/show output look for an entry like the one below.

==============================
vmnic4:
MAC       : 00:50:56:01:08:ca
Link      : Up
MTU       : 1500
IP config :
------------------------------
VMK intf  : vmk3
MAC addr  : 00:50:56:6b:ca:dd
Services  : NSX-Tunneling
VLAN      : 0
IP        : 192.168.110.123(Static)
Mask      : 255.255.255.0(Static)
..............................
------------------------------
Connection : NVS (uplink0)
Configured as standalone interface
==============================

You can also check the status of the vmkernel interface with esxcli and with nsxcli.

 ~ # esxcli network ip interface ipv4 get -i vmk3
Name  IPv4 Address     IPv4 Netmask   IPv4 Broadcast   Address Type  DHCP DNS
----  ---------------  -------------  ---------------  ------------  --------
vmk3  192.168.110.123  255.255.255.0  192.168.110.255  STATIC           false
~ #
~ # nsxcli vmknic/show vmk3
vmk3:
MAC addr  : 00:50:56:6b:ca:dd
Services  : NSX-Tunneling
VLAN      : 0
IP        : 192.168.110.123(Static)
Mask      : 255.255.255.0(Static)
Assoc with: vmnic4
..............................
~ #

The next step is configure the gateway  for NSX vSwitch.

~ # nsxcli gw/set tunneling 192.168.110.2
~ #
~ # nsxcli gw/show tunneling
Tunneling:
Configured default gateway       : 192.168.110.2
Currently active default gateway : 192.168.110.2 (Manual)
~ #

Connect NSX vSwitch instance to NSX controller cluster.

~ # nsxcli manager/set ssl:192.168.110.31
~ #
~ # nsx-dbctl show
e42912a7-693f-43ee-84d5-11b5bb3491eb
    Manager "ssl:192.168.110.31:6632"
    Bridge br-int
        fail_mode: secure
    Bridge "br-vmnic4"
        fail_mode: standalone
        Port "vmk3"
            Interface "vmk3"
        Port "vmnic4"
            Interface "vmnic4"
    ovs_version: "2.1.3.35984"
~ #

Create an opaque network. An opaque network is basically a transport bridge that will provide the network backend for the virtual machines. Opaque networks must be identified during its creation based on its type and ID.

In this particular case the ESXi will be added later to a cluster acting as nova compute backend for my OpenStack lab so the network type must be nsx.network and the UUID have to match the configured one for the integration_bridge setting in nova.conf file. We also need to specify the port attach mode, for OpenStack environments is manual.

~ # nsxcli network/add NSX-Bridge NSX-Bridge nsx.network manual
success
~ #
~ # nsxcli network/show
UUID                                        Name                    Type            Mode
----                                        ----                    ----            ----
NSX-Bridge                                  NSX-Bridge              nsx.network     manual
~ #

Add ESXi as transport node

The final part of the procedure is to add our new ESXi server as transport node to NSX. Log into NSX Manager web UI and initiate the wizard to add a new Hypervisor. First specify the name of the new hypervisor.

Screen Shot 2014-07-14 at 02.13.30

Set the integration bridge.

Screen Shot 2014-07-14 at 02.22.44

Select Security Certificate as credential type and paste the NSX vSwitch SSL certificate. The certificate can be retrieved from /etc/nsxvswitch/nsxvswitch-cert.pem.

Screen Shot 2014-07-14 at 02.29.50

Add an SST transport connector, using the IP address configured for the uplink.

Screen Shot 2014-07-14 at 02.31.57

Click Save & View and verify the new hypervisor configuration in NSX.

Screen Shot 2014-07-14 at 02.36.15

The setup of our new ESXi server within NSX is done. As always comments are welcomed.

Juanma.

Every customer usually asks about how to monitor their vCenter Chargeback installations, hence I finally decided to write a small post listing the services and processes of the different Chargeback components.

Windows Service Path to executable
VMware vCenter Chargeback C:\Program Files (x86)\VMware\VMware vCenter Chargeback\apache-tomcat\bin\tomcat6.exe
VMware vCenter Chargeback – VMware Cloud Director DataCollector C:\Program Files (x86)\VMware\VMware vCenter Chargeback\VMware Cloud Director DataCollector\JavaService.exe
VMware vCenter Chargeback – vShield Manager DataCollector C:\Program Files (x86)\VMware\VMware vCenter Chargeback\vShield Manager DataCollector\JavaService.exe
VMware vCenter Chargeback DataCollector-Embedded C:\Program Files (x86)\VMware\VMware vCenter Chargeback\DataCollector-Embedded\JavaService.exe
VMware vCenter Chargeback Load Balancer C:\Program Files (x86)\VMware\VMware vCenter Chargeback\Apache2.2\bin\httpd.exe

Bear in mind that if vShield and vCloud DataCollectors are installed on the same server as Chargeback Server the path will be slightly different:

VMware vCenter Chargeback – vShield Manager DataCollector-Embedded C:\Program Files (x86)\VMware\VMware vCenter Chargeback\vShield Manager DataCollector-Embedded\JavaService.exe
VMware vCenter Chargeback DataCollector-Embedded C:\Program Files (x86)\VMware\VMware vCenter Chargeback\DataCollector-Embedded\JavaService.exe

Juanma.

I found this error last week during a deployment in a customer. The vCenter Infrastructure Navigator appliance does not maintain its configured hostname after a reboot, it gets reset to the default localhost.localdom value.

image

Setting it again in the administration web interface doesn’t solve problem, it will be lost again after the next reboot.

The problem is in the vami_set_hostname script, it has a HOSTNAME variable set to localhost.localdom and if it fails to make the reverse lookup of the hostname from the IP address using the host command it will be set to the default value.

image

To fix this edit that file, it can be found on /opt/vmware/share/vami, and set the value of the variable to your hostname. After that reboot the appliance to check that everything works as expected.

Juanma.

vCenter Chargeback Manager gives you the possibility during the installation process to generate an SSL certificate. But this certificate is generated with an expiration period of 60 days.

No problem with that, you can always regenerate it again. Actually Chargeback provides the mechanism to do it. The process can be launched from the vCenter Chargeback Manager Tools folder as it can be seen in the screenshot below.

CBM_generate_SSL

However this new certificate will come with the same limitation of 60 days of valid period. To easily avoid that we only need to edit the .bat file that generates the certificate and modify the correspondent value.

The script is called Generate_Ssl_Certificate.bat and can be found C:\Program Files(x86)\VMware\VMware vCenter Chargeback\Apache2.2\bin.

image

Edit the file using your favorite text editor, in my case I’m using Notepad++, and go to line number 72 as in the capture.

image

Change the –days flag from 60 to your desired value, in the example the value is 365 this is the certificate will expire in one year.

After we can launch the generation process. The batch file will open a cmd window, stop the CBM Load Balancer service and asks for the passphrase of default.key. You’ll have to enter it three times and after that the process will ask for information about the State, City, common name (usually the server FQDN), company name, email, etc.

image

After that it will generate the new certificate and will start Load Balancer services.

image

Juanma.