Nowadays Packstack based OpenStack installations are used for proof-of-concept and demonstration purposes only. The official RDO community points TripleO (OpenStack On OpenStack) as a recommended OpenStack deployment method for production cloud. TripleO is an automated installation tool, based on Ironic OpenStack node provisioning software, intended for deployments on bare metal servers, that is, on physical hardware. TripleO generally requires using servers equipped with BMC (Baseboard Management Controller) or IPMI (Intelligent Platform Management Interface) modules, like HPE iLO (integrated Lights Out) in order to be able to manage and controll servers during OpenStack deployment, maintenance and node introspection procedures.
Continue reading “OpenStack Pike TripleO Undercloud and Overcloud Deployment on 3 Bare Metal Servers”
UEFI (Unified Extensible Firmware Interface) has become a successfull successor of an outworn and obsolete BIOS firmware. Emulating UEFI based hardware on KVM/QEMU Virtual Machine is possible thanks to so called OVMF (Open Virtual Machine Firmware), which comes from EDK2 (EFI Development Kit), UEFI reference implementation. OVMF is available as an RPM package for RPM based distros (CentOS, Fedora, Red Hat). In case of Fedora release all we need is edk2-ovmf RPM package.
Continue reading “Enable UEFI for QEMU KVM on Fedora”
How to enable Proxy for Docker engine with or without authentication on CentOS 7, Red Hat Enterprise Linux 7?
CentOS 7 may offer us a possibility of automatic RAID configuration in Anaconda installer, that is during OS installation, once it detects more than one physical device attached to the computer. Mentioned RAID is generally the LVM-RAID setup, based on well known mdadm – Linux Software RAID. It’s a pretty convenient solution, since we don’t need to setup RAID manually after installation, on already running system.
The below procedure presents CentOS 7 testing installation with LVM RAID 1 (Mirroring) on KVM based Virtual Machine with two attached 20GB virtual disks.
Continue reading “CentOS 7 Installation with LVM RAID 1 – Mirroring”
Testing OpenStack Pike after Packstack based deployment I realised MySQL daemon was utilizing 100% CPU resources without any specific reason, but I had never faced such problem before in previous OpenStack releases. The problem also has never appeared during my TripleO based OpenStack Pike deployments, so looks like it’s strictly Packstack related issue.
The situation heppened on few bare metal installations on pretty powerful servers. Restarting mariadb service was helpful just for the first few minutes after service restart, then the problem would happen again and again, what resulted in frequent Horizon Dashboard and Keystone inaccessibility and partial Controller unavailability.
Continue reading “MariaDB high CPU usage in OpenStack Pike”
In previous articles regarding OpenStack RDO installations we presented OpenStack deployments using Packstack automated installer script, which still required some post-installation networking configuration to be performed in order to accomplish whole deployment. This time we will try to prepare Packstack configuration file (answers.txt) in such way, that it does all the magic and no post-installation configuration is required. We will make full bridge:interface mapping so, that no further bridge setup is needed and the environment should be ready to use immediately after Packstack deployment.
Continue reading “OpenStack Pike VLAN and Flat network based installation using Packstack”
OpenStack networking topology is pretty complicated structure, even with it’s, let’s say, default configuration based on OVS (OpenVSwitch), not even mentioning about additional overlays, like OpenDaylight or Nuage.
If you are troubleshooting network issues in regard to a particular Instance (VM), it’s good to locate network overlay interfaces (qbr, qvo) assigned to that Instance to have a starting point to begin your network analysis from. You can then analyze inbound/outbound traffic on those interfaces using network protocol analyzers, like tcpdump/wireshark.
Below you can find few steps, how to locate qbr,qvo interfaces belonging to a particular Instance:
Continue reading “How to find qbr,qvo interfaces of the particular Instance in OpenStack”
HPE Smart Storage Administrator is a tool that allows to quickly configure and manage storage controllers on HPE Proliant servers. HPE SSA offers simple, intuitive and easy to use GUI interface to quickly create, modify and erase storage arrays based on physical drives installed in the server. HPE SSA replaces the HPE Array Configuration Utility (ACU), and has an updated design for HPE ProLiant servers that enhances the storage experience.
In this short tutorial we will create one of the simplest storage arrays, which is RAID 1 based on two physical drives. RAID 1 (mirroring) provides a replication on all physical drives by writing data to all of them at the same time, it gives us fault-tolerance of N-1 drives where N is a number of used physical drives.
Continue reading “RAID 1 configuration on HP Proliant Gen 9 server using HP SSA”
Heat is an OpenStack Orchestration service, which implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. Heat service is able to read YAML (.yaml, .yml) files and perform different tasks inside OpenStack environment included in YAML components. Using Heat Orchestration we can create instances, networks or even whole tenants with just single mouse click in OpenStack dashboard (Horizon), if we have previously prepared YAML file with Heat instructions to be performed in OpenStack cloud.
In this tutorial we will create example .yaml file for Heat orchestration containing instructions and components needed to deploy project tenant in OpenStack and launch instances inside the tenant. Next, we will create our stack on single OpenStack all-in-one node based on CentOS 7.3 operating system.
Continue reading “Deploy project tenant in OpenStack using Heat orchestration stack”
DNF is a next generation package manager for RPM-based Linux distributions, commonly used in newest Fedora releases. DNF is a Yum succesor, which provides Yum backward compatibility, but one of aspects, which make DNF a powerful package manager is the ability to manage transaction history.
Using DNF, we can easily undo or redo RPM package upgrade, installation and removal. This gives us the opportunity to rollback the system, if we feel, that our recent RPM package operations disordered the system.
Below we presents, how to work with DNF transaction history on Fedora 24.
Continue reading “Fedora DNF rollback RPM package update, removal, installation”