Honestly, this one is not hard to figure out, as it’s documented in multiple places. However, I have found that the documentation varies greatly depending if you are using RHEV or Ovirt, and the version of each that you are using seems to matter as well. At least, that has been my experience trying to figure out how to get this working.
So I figured I would document it here so that I would not have to try to remember which google result worked for me.
Note that this example is on RHEV 3.6.1.
First, you need to connect to the RHEV-h machine that is hosting the HostedEngine. Then you need to set a console password. See example below.
Note: This is a one-time password, and must be set each time you want to connect to the console.
In this post, I am going to walk you through the process of installing and configuring two- factor SSH authentication via Google Authenticator. My base system is running a fresh install of RHEL 7.2
Installation Steps
The first step on my system was to install autoreconf, automake, and libtool. These packages are required by the bootstrap.sh script that we will need to in a couple more steps.
# yum -y install autoconf automake libtool
Now, we are going to install Git.
#yum -y install git
One more dependency to knock out. Install pam-devel as shown below.
# yum -y install pam-devel
Next, we clone the google-authenticator Git repo. In this example, I am cloning to /root
Using a few simple commands you can easily map a PCI slot back to its directly connected NUMA node. This information comes in very handy when implementing NFV leveraged technologies such as CPU Pinning and SRIOV.
First, you will need to install hwloc and hwloc-gui, if it is not already installed on your system. hwloc-gui provides the lstopo command, so you will need to install the gui package even if you are going to run the command on a headless system.
# yum -y install hwloc.x86_64 hwloc-gui.x86_64
Now you can run lstopo. Below is the output from one of my dual socket, quad core Xeon systems.
The first 27 lines of output tell you which cores are in each socket.
Lines starting with “HostBridge L#0” list the PCI devices attached to socket 0. On more modern dual socket systems (think Sandybridge) you would have a “HostBridge L#8” section as well.
“The PCI host bridge provides an interconnect between the processor and peripheral components. Through the PCI host bridge, the processor can directly access main memory independent of other PCI bus masters. For example, while the CPU is fetching data from the cache controller in the host bridge, other PCI devices can also access the system memory through the host bridge. The advantage of this architecture lies in its separation of the I/O bus from the processor’s host bus.”
Unfortunately, my lab systems are Nehalem based machines which implement what is called QPI to share a host bridge between CPU sockets. See image below.
Nehalem QPI Architecture
Nonetheless, we are able to determine which CPU socket is associated with a specific PCI device. For this example, we will focus on the devices below since they are both directly attached to the PCI Host Bridge and not the PCI Bus.
HostBridge L#0 PCIBridge PCI 8086:10c9 Net L#0 "enp8s0f0" PCI 8086:10c9 Net L#1 "enp8s0f1"
Now using the lspci command I can find the exact devices per NUMA node.
Within OpenStack, each virtual machine instance running on a Compute nodes also a virtual machine running on a libvirt node.
If you ssh to a Compute node and run the command below you can get the names of each VM running or registered on this Compute node.
# virsh list –all
Id Name State
—————————————————-
2 instance-000000f0 running
– instance-00000024 shut off
– instance-00000039 shut off
– instance-000000ea shut off
So there is only one VM currently running on this Compute node, but which VM is it?
Well, we can figure that out pretty easily. See below.
# virsh dumpxml instance-000000f0 | grep uuid | grep name
According to this page, a Technology Preview is a feature that is currently unsupported, may not have complete functionality, and are not suitable for deployment in production. However, Red Hat provides these features and makes them available to the customer as a courtesy with the primary goal of exposing the feature to a wider audience.
I am quite often asked by my clients, which features are in tech preview for each release. Instead of spending time looking these things up each time I figured I would document them here.
Overview OpenShift Enterprise is a PaaS platform that enables digital transformation. It lets you build and run traditional (mode 1) as well as cloud-native (mode 2) applications. OpenShift is buil…
Trying to determine that version of Red Hat OpenStack director that is installed on an Undercloud Controller is not as straight forward as one would hope.
I have created the simple table below that you can use to determine your installed director version via the installed version of the openstack-tripleo-heat-templates rpm.
Hopefully, in the near future, we will see an rpm similar to redhat-release-server (the rpm that create /etc/redhat-release) included in future OSP director updates. Until then, this table should be of some assistance.
