version 6.1 User Guide

Transcription

1 version 6.1

2 Contents Preface 1 Intended Audience 1 Documentation History 1 Introduction to the 2 Confirm hardware 3 Download and Install Fuel 4 Create the Installation Media 4 Create a USB drive to store the Fuel ISO image on a UNIX system 4 Install Fuel Master Node 5 Changing PXE Network Parameters During Installation 6 Fuel Setup 6 Network Setup 7 PXE Setup 9 DNS & Hostname 10 Time sync with NTP 11 Root password 12 Shell login 12 Fuel login 12 Quit Setup 12 Boot the Fuel Master Node 14 Boot the node servers 15 Install Fuel plugins 16 Overview 16 Validation 16 Installation steps 16 Create a new OpenStack environment 17 Launch Wizard to Create New Environment 17 Change Fuel Password 18 Approve Statistics Gathering 19 Name Environment and Choose Distribution 20 High-availability (HA) mode , Mirantis Inc. Page i

3 Hypervisor 23 Network service 24 Storage backend for Cinder and Glance 25 Related projects 26 Complete the creation of your environment 27 Configure your Environment 28 Add nodes to the environment 29 Assign a role or roles to each node server 29 Disk partitioning 31 Network settings 34 Neutron network settings 34 Nova-network settings 36 Setting NIC bonding (NIC aggregation) 38 Mapping logical networks to physical interfaces on servers 39 Verify Networks 41 Settings tab 43 Access permissions for Horizon 43 Provision Method 43 Repositories 44 Services included in the environment 45 Common settings 46 Setting debug level for the environment 46 Choose the Compute Node Scheduler 46 Choose image format 46 Public Key 47 Setting initial kernel parameters for target nodes 47 Configuring syslog 47 Mellanox Neutron components 48 Storage 49 Resetting the Zabbix password 49 Deploy Changes 50 Stopping Deployment from Web UI , Mirantis Inc. Page ii

4 Resetting environment after deployment 51 Next Steps 53 Post-Deployment Check 54 Benefits 54 Running Post-Deployment Checks 54 What To Do When a Test Fails 55 High Availability checks 56 Platform Tests Description 56 Installing Sahara 57 Upgrading and Updating from Earlier Releases 58 Upgrade Fuel from Earlier Versions 58 Role operations 61 Role object 61 Using Fuel CLI 63 Introduction 63 Basic usage 63 CLI commands reference 63 What stands for acronyms in CLI commands 64 Release 65 Networks configuration 66 Environment 66 Node 67 Node group 68 Roles operations 68 Configuring 69 Deployment 70 Change and Set Fuel password 71 Fuel Plugins CLI 71 VMware integration notes 73 Deploying vcenter 74 Create Environment and Choose Distribution for vcenter 74 Select vcenter Hypervisor for vcenter , Mirantis Inc. Page iii

5 Select Network Service for vcenter 75 Choose Backend for Cinder and Glance with vcenter 75 Related projects for vcenter 76 Complete the creation of your vcenter environment 76 Configuring your environment for vcenter 77 Assign a role or roles to each node server 77 Network settings 77 Settings 79 VMware tab 79 vcenter 79 Nova-Computes 79 Network 80 Glance 80 Installing Fuel Master Node on vsphere 80 Download the Mirantis OpenStack ISO 81 Upload the ISO to the vcenter Datastore 81 Create a vcenter Port Group network 83 Create Virtual Machine and Mount ISO 84 Mount the Mirantis OpenStack ISO 87 Install and Boot the Fuel Master Node on vsphere 89 Verify that Fuel booted on ESXi 93 Patching 94 Index , Mirantis Inc. Page iv

6

7 Preface Preface This documentation provides information on how to use Fuel to deploy OpenStack environments. The information is for reference purposes and is subject to change. Intended Audience This documentation is intended for OpenStack administrators and developers; it assumes that you have experience with network and cloud concepts. Documentation History The following table lists the released revisions of this documentation: May, 2015 Revision Date 6.1 GA Description 2015, Mirantis Inc. Page 1

8 Introduction to the Introduction to the This guide gives instructions for using the Fuel Master Node and the graphical Fuel screens to deploy a Mirantis OpenStack environment. If you already have a deployed Fuel Master Node based on version 5.x or 6.0, go to Upgrading and Updating from Earlier Releases for instructions on upgrading to Fuel 6.1 and updating your existing OpenStack distribution to use the latest maintenance release of Mirantis OpenStack. If you are deploying Mirantis OpenStack 6.1 for the first time, continue reading this document for instructions. Before you do the procedures in this document, you should work through the information and procedures in the Planning Guide. That document discusses the planning decisions required before you install and deploy Mirantis OpenStack. Further reading is available in the following documents: Terminology Reference is an alphabetical listing of technologies and concepts that serves as both a glossary and a master index of information in the Mirantis docs and other sources of information. Operations Guide gives information about advanced tasks required to maintain the OpenStack environment after it is deployed. Most of these tasks are done in the shell using text editors and command line tools. Reference Architecture provides background information about how OpenStack works. For community members and partners looking to take Fuel even further, see the developer documentation for information about the internal architecture of Fuel, instructions for building the project, information about interacting with the REST API and other topics of interest to more advanced developers. You can also visit the Fuel project for more detailed information and become a contributor. 2015, Mirantis Inc. Page 2

9 Confirm hardware Confirm hardware Before you download and boot the Fuel Master, use the following checklist to ensure that your hardware is configured correctly: Item to confirm The Fuel server has an IPMI or out of band management system and you have access to it. The Fuel server hardware is able to boot the Fuel ISO from DVD, USB flash drive, or IPMI remote media. The Fuel server has connectivity to all node servers through the L2 management network. A DHCP server is NOT installed on the management network. Fuel acts as a DHCP server for the node servers configured to network boot using PXE. Spanning tree is disabled on switch ports connected to the node servers ports or ports are set to edge/portfast mode. Edge/portfast mode is the preferred configuration; it allows the ports to forward immediately when they are linked up but listens for network loops for 15 seconds. There is NO configured tagged VLAN on a switch for the administrative network (to the boot server from PXE) The node servers are set to network boot using PXE. The node servers have hardware virtualization enabled in the BIOS. You have a method to reboot node servers (remotely or on-site). The network equipment supports VLANs. It is possible to configure a tagged port on your switch/switches. You need tagged ports in order to use the Nova-network VLAN Manager or Neutron with VLAN segmentation. You have permit rules on TCP ports 22 and 8000 on the firewall for the Fuel server s IP address (to access the Fuel server from your PC). Status [tick if done] If you checked all the boxes in the above table, you are ready to deploy Mirantis OpenStack with Fuel. 2015, Mirantis Inc. Page 3

10 Download and Install Fuel Download and Install Fuel Mirantis provides the images you will use to install Fuel and Mirantis OpenStack. Download the Fuel image from the Mirantis web-site. Depending on the speed of your Internet connection, this could take a half hour or more. Create the Installation Media You can download an ISO file and, for many modern servers, use a remote control utility such as ipmitool, HP ilo, or Dell idrac to mount the ISO image directly to the server's virtual DVD drive. For a bare-metal installation, you can instead burn the ISO image to a DVD or USB drive, then use that media to install the software. Note You can use the same ISO image to install Fuel and Mirantis OpenStack in VirtualBox. In that case, copy the ISO file to the appropriate directory and boot directly from that disk file. See Introduction. Use any standard software to burn the ISO to a writable DVD. Some popular options: Linux -- Brasero and Xfburn are commonly pre-installed applications Mac OS X -- Open Disk Utility from Applications > Utilities, drag the ISO into the disk list on the left side of the window and select it, insert a blank DVD, and click Burn. If you prefer a different utility, check out the open source Burn. Windows -- Use ImgBurn or the open source InfraRecorder. Create a USB drive to store the Fuel ISO image on a UNIX system You can use a USB flash drive to install Fuel on your machine. Write the ISO image to the USB flash drive, but not to the partitions of the USB flash drive. For example, if you have a USB flash drive /dev/sdc with the /dev/sdc1 and /dev/sdc2 partititions, write the USO to /dev/sdc. To create a USB flash drive with the Mirantis OpenStack ISO image: dd if=/path-to-iso of=/path-to-usb Example:: dd if=/home/user/fuel-isos/fuel _ iso of=/dev/sdc 2015, Mirantis Inc. Page 4

11 Install Fuel Master Node Warning All data on the USB flash drive will be lost. Install Fuel Master Node Insert (or mount through IPMI) the media you created in Download and Install Fuel on the server that will be your Fuel Master Node and power the machine on, just as you would for any operating system installation. Set the boot order for the system with the installation media as the first device. Or you can set the hard drive as the first device, then select the location of the media that contains the installation file to install the software. The following screen appears. If necessary, you can modify the boot settings from this screen; press the "Tab" key to display the grub command line and edit that line. This allows you to configure the IP address, default gateway, and DNS server for the Fuel Master Node. Note It is possible to install Fuel Master node on vsphere. For more details, see Installing Fuel Master Node on vsphere. 2015, Mirantis Inc. Page 5

12 Changing PXE Network Parameters During Installation Changing PXE Network Parameters During Installation You may also need to customize the network settings for the Admin (PXE) logical network. Note The VirtualBox automated scripts depend on the network configuration in the config.sh file so the virtual Fuel Master Node can connect to the virtual nodes correctly. Do not use Fuel Setup to configure the Admin network interface when using VirtualBox; however, you can view this Fuel Setup screen by modifying the vm_master_ip parameter in the config.sh file. By default, eth0 on the Fuel Master node listens to PXE requests from the Fuel Admin (PXE booting) network, which has a default network of /24 and the gateway PXE network settings may be changed with two ways - via kernel options (for eth0 interface only) and via the console-based Fuel Setup. Warning Settings made with console-based Fuel Setup take precedence over the kernel options! Note that, Changing the IP address in the kernel options also changes the CIDR for the Admin network. Changing the IP address on the Admin network interface requires changes to the DHCP range values in the PXE Settings screen. New default DHCP values that fit into this range are auto-populated, but be sure that the range does not conflict with other devices on the network. Kernel options allow you to customize eth0 network settings, which will be used for Admin (PXE) network if you will not change these later with Fuel Setup. Customizing eth0 interface via kernel options also gives the ability to connect to the master node early, which is useful if the master node installation fails. Fuel Setup The console-based Fuel Setup allows you to customize the Admin (PXE) logical network if you want to use a different network interface. See Logical Networks for more information about the Admin (PXE) logical network. This tool provides a simple way to configure Fuel for your particular networking environment, while helping to detect errors early so you do not need to troubleshoot individual configuration files. Within Fuel Setup, you can configure the following parameters: DHCP/Static configuration for each network interface 2015, Mirantis Inc. Page 6

13 Network Setup Select interface for Fuel Admin network Define DHCP pool (bootstrap) and static range (installed nodes) Set NTP servers for Time settings Root password Fuel password DNS options Launch shell for optional pre-deployment tasks Use the arrow keys to navigate through the tool and Space or Enter key to select an item. Network Setup This section is used to set network interface settings. It shows all network interfaces currently available. During the first boot, it shows only available ethx NICs; if you run Fuel Setup on already deployed Fuel Master node it will additionally present you vethxxx interfaces. You may set configuration for each interface, enable or disable particular NICs. Unlike the other tabs, this tab has the ability to immediately apply only changes related to this tab. Warning All the settings on this tab may be performed manually with standard Linux IP tools. Actually, Fuel Setup use these tools as well. So, if complex network setup required before Fuel Setup, there is possibility to use Shell Login from Fuel Setup during the first boot, perform necessary network settings with proper care, return back to the Fuel Setup and continue with master node installation. Configuring Network settings Network settings has 2 parts - editable Network settings and non-editable Network Interface current status. NIC current status area shows the current network interface status, including name, Link Status, current IP address, MAC address, Netmask and Gateway. 2015, Mirantis Inc. Page 7

14 Network Setup Network Settings from the editable Network Setup part become effective only after they are applied with the Apply button. Network Setup includes the following configurable sections: Network Interface Selector - Shows all available network interfaces, physical and virtual. Select the interface you want to configure with arrow keys and click Space or Enter to show its configuration. Interface name - Here you may rename the selected network interface. Enable interface - Here you may turn the selected network interface ON or OFF. Configuration via DHCP - You may set interface to get settings from the existing external DHCP server. Do not set DHCP=Yes for the network interface you are going to use for Admin (PXE) network! IP Address - allows to set static IP address for selected NIC. Netmask - allows to set network mask for selected NIC. Default gateway - allows to set the gateway for selected NIC. Button Check - Validates the unsaved settings on the Network Setup section without applying. Button Apply - Validates the unsaved settings on the Network Setup section and makes the new settings effective. Assume you are going to change PXE NIC from eth0 to eth1. eth0 is already up and its IP address is , set via kernel options. You want eth1 to use the same IP address. Additionally, you want to set eth2, connected to your corporate network as the interface where Fuel web UI will be accessible. eth2 should use DHCP. Your actions: 1. Select eth0 on the Network Setup tab. Change Enable interface option from Yes to No. 2. Apply settings. It will turn off eth0. You need this since we do not want the same IP address configured on both eth0 and eth1 at the same time. 3. Select eth1 on the Network Setup tab. Change Enable interface option to Yes. Set IP address to , set the proper netmask and gateway. 4. Apply settings. Now you have set eth1 ready to be used as PXE interface. 5. Select eth2 on the Network Setup tab. Change Enable interface option to Yes. Set Configuration via DHCP=yes. Leave IP address, Netmask and gateway blank. 6. Apply settings. Now you have eth2 available in your corporate network. 2015, Mirantis Inc. Page 8

15 PXE Setup And do not hesitate to use Check button to verify your future network settings in advance. Warning To set the master node network interfaces properly, one must set and APPLY correct network settings on the Network Setup tab BEFORE proceeding with PXE setup. Once you have finished with the network Setup you may proceed to PXE Setup tab. PXE Setup Warning This section must be configured only in the scope of the Fuel Master node's first boot! Setting new network settings for the already installed master node requires that all Docker containers be rebuilt and possibly further manual reconfiguration! Here you may select the network interface you are going to use for PXE/Admin network and set DHCP pool ranges. 2015, Mirantis Inc. Page 9

16 DNS & Hostname PXE Setup has 2 parts - editable PXE settings and current status information about the selected Network Interface that cannot be edited. NIC current status area shows the current network interface status, including name, Link Status, current IP address, MAC address, Netmask and Gateway. It also shows warnings, related to the currently selected NIC misconfiguration. PXE setup includes the following options: Network Interface Selector - Shows all available network interfaces, physical and virtual. Select the interface you want to configure with arrow keys and click Space or Enter to show its configuration. DHCP Pool for node discovering - Here you may define DHCP Pool Start and End IP addresses. These addresses should be located inside the CIDR that is configured for the currently selected NIC. Check button - verifies the current unsaved settings against the currently selected NIC without applying. Let us continue the example we started in the Network Settings section: 1. Use the Space or Enter key to mark and select the network interface you have configured for PXE on the Network Setup tab. The default PXE interface is eth0. If you follow the example from Network Setup part of this guide, you have to select eth1. 2. Set the proper DHCP Pool range values. 3. As usual, use Check button to verify the current unsaved settings. Warning Modifying the PXE NIC with Fuel Setup when the Fuel Master node is already deployed will break Fuel's ability to PXE boot and manage OpenStack environments. If you wish to modify PXE NIC configuration, you should only do so by destroying all OpenStack environments, and then run the following commands: dockerctl shell nailgun, manage.py dropdb, dockerctl destroy all, dockerctl start all. DNS & Hostname Use this section to configure the remained master node network settings. These settings may be reconfigured after the master node has been deployed. 2015, Mirantis Inc. Page 10

17 Time sync with NTP Details on settings: Hostname - master node host name (without domain) Domain - master node domain name. If the master node has several network interfaces, you may connect non-pxe one to the existing corporate network and set the real domain name. Otherwise, use default or any valid stub name. Search domain - in most cases, should match the Domain field, unless you know what you are doing. External DNS - Point it to the corporate or Internet-based DNS server if your master node is connected to the corporate network by Non-PXE network interface. Otherwise - leave blank, since it may block Fuel Setup from network settings save due to failed DNS test. Hostname to test DNS - any existing host name, which Fuel Setup may ping in order to check DNS settings. Please do not hesitate to use Check button to verify your future network settings in advance. Time sync with NTP Use this section to set NTP server names in order to get proper time synchronization. Synchronized time is mandatory for OpenStack services. If you have access from master node to the external or corporate network - it is strongly recommended to set proper NTP server names or IP addresses. If your master node currently has no access to the external or corporate network - leave all 3 fields blank. You may set these later. 2015, Mirantis Inc. Page 11

18 Root password If you set NTP server names blank and enable NTP - master node will serve your OpenStack installations as NTP server, but will not synchronize time with NTP. It may lead to a time shift between your OpenStack installations and the rest of the world. If you disable NTP completely - your deployed OpenStack will not use NTP and most probably will end with the timing errors, unless you have an external solution to synchronize clocks between the nodes. Please do not hesitate to use Check button to verify your future network settings in advance. Root password Here you may set new root password for your master node. This password serves as the default root password for all future OpenStack nodes. Already existing OpenStack nodes will keep the existing password. Leave these fields blank in order to keep the default root credentials. Button Check verifies if both password fields match and has correct data. Shell login This section gives you the ability to log in to the master node console as root. You will be redirected back to the Fuel Setup after exit from shell. Fuel login This section enables you to modify the password used to log into the Fuel Dashboard: Changing this password here changes the password value in the astute.yaml file. You can also modify the password from the Fuel UI screens and the Fuel CLI. See Fuel Access Control for more information about Fuel passwords. Quit Setup Options: Save and Continue - runs built-in tests. If tests passed successfully - saves the current settings from all sections, except the first one, Network Setup, which has its own Apply button. Gives you the ability to check settings and save intermediate changes. 2015, Mirantis Inc. Page 12

19 Root password Save and Quit - runs built-in tests first. If test passed successfully - saves the current settings from all sections, except the first one, Network Setup, which has its own Apply button. After the settings saved, it quits Fuel Setup and, if it is first boot, continues with Fuel master node installation. Quit without Save - discards all the current settings from all sections, except the first one, Network Setup, which has its own Apply button and quits the Fuel Setup. Once you have made your changes, go to Save & Quit. You can run fuelmenu from a root shell on the Fuel Master node after deployment to make minor changes to network interfaces, DNS, Time Sync and the gateway. The PXE settings, however, must not be changed after deployment as it will lead to master node failure. Option to change PXE settings remains active for those who are familiar with master node manual settings Warning Once IP settings are set at boot time for Fuel Master node, they should not be changed during the entire lifecycle of Fuel. 2015, Mirantis Inc. Page 13

20 Boot the Fuel Master Node Boot the Fuel Master Node When installation is complete, be sure to remove the installation media from your system. This is especially important if you set the boot order so that the USB/DVD drive is before the hard disk; you may accidentally boot the installation media again and damage or delete your environment. The boot messages display on your screen as Fuel boots up: When the system has booted, you can log in: Use the administrator login and password that are displayed on the boot screen to log into a shell on the Fuel Master node. After you log in, use the passwd command to change this password. Use the URL displayed on this screen to launch the Fuel UI; the default URL is This is your URL unless you modified the IP address on the Fuel Setup screens. Use the admin user name and the Fuel password you set in in the Fuel Setup screens (see Fuel login) to log in. If you did not set a Fuel password during installation, log in using admin/admin as the username/password. You can change the password from the Fuel UI; see Change Fuel Password. Alternately, if the server on which the Fuel Master is installed has more than one NIC, you can use the second NIC to access the Fuel UI: Connect the NIC to the appropriate switch Set the IP address for this NIC Use the IP address you set to access the Fuel UI. Note that doing this does not change the Admin network settings; the URL displayed on the Fuel boot screen is unchanged and can still be used. 2015, Mirantis Inc. Page 14

21 Boot the node servers Boot the node servers After the Fuel Master Node is installed and booted, power on all target nodes that you are going to use for the OpenStack environment. First, ensure that servers are physically connected to the same network as the Master node or, if you are using virtual servers, are bridged to it so they are in the same L2 network segment. Then you can boot each node (other than the Fuel master) via PXE by either modifying the BIOS boot order or pressing the appropriate key to initiate a PXE boot. If your nodes have several network interfaces, be sure to enable PXE-boot on the interface that is on the same network you configured for PXE booting on the Fuel Master Node. 1. Each node sends out DHCP discovery requests and gets the response from the Fuel Master node that runs the DHCP server. 2. When a node receives the response from the Fuel Master node, it fetches the pxelinux bootloader and then the bootstrap image (CentOS based Linux in memory) from the Fuel Master node's TFTP server and boots into it. 3. When this image is loaded, it reports the node's readiness and configuration to the Fuel Master. This can take a few minutes. Follow the instructions in Boot the Fuel Master Node to log into the Fuel UI if you have not already done so. You will see notifications in the user interface about the discovered nodes. Find the count of "Discovered nodes" in the upper right area of the Fuel Web UI; this value is incremented as each new node is ready. When the count of "Discovered nodes" becomes equal to the amount of the servers you have booted in the network, you can create an OpenStack environment, add nodes into it, and start configuration. Networking configuration is the most complicated part, so please read Choose Network Topology and the other documents it references before you begin. When you have configured all the nodes and their roles, and pressed the Deploy button: 1. Each server should reboot and start the provisioning of the selected operating system using the same PXE boot scheme, so ensure that all the servers have successfully rebooted, booted over the network and started the installers. 2. When all servers have been successfully provisioned and rebooted again from their local drives into the newly installed systems, the Fuel Master node starts the deployment of OpenStack on them. Note Beginning with 6.1 release, nodes discovery is enabled over the prepared Infiniband network via Fuel over Mellanox NICs with Infiniband support, after Mellanox Fuel plugin installation. This means, the Fuel Master node will discover and use EIPOIB daemon (Ethernet IP Over Infiniband) interfaces for the network roles. Note, that interface driver and bus information are now available for all discovered NIC interfaces. For detailed instructions, see Verify Infiniband links for nodes section in the official Mellanox documentation. 2015, Mirantis Inc. Page 15

22 Install Fuel plugins Install Fuel plugins Overview Beginning with Mirantis OpenStack 6.0, Fuel features the ability to install plugins before you deploy your environment. Plugins are downloadable software components that extend the functionality of your environments in a flexible, repeatable and reliable manner. For example, Neutron VPNaaS provides flexible IPSec VPN feature-set supported by Neutron CLI and, more simply, in Horizon, by adding a new set of tabs to Network. Validation The Fuel Plugins Validation is a set of technical and business processes that Mirantis uses to verify Fuel plugins built by vendors, allowing a customer's choice of plugins to lead to a predictable outcome. That means, Mirantis Validation ensures the quality of developed solution. In terms of Validation, Fuel plugins fall into two categories: Validated - thoroughly reviewed, tested and supported by Mirantis. Non-Validated - reviewed, tested in terms of code and installation procedure, but not supported by Mirantis. See the validation requirements at Mirantis website. For information on development requirements and FAQ, see Fuel Plugins wiki page. Installation steps Installation procedure is common for all plugins, but their requirements differ. 1. Download a plugin from Fuel Plugins Catalog. 2. Get acquainted with the plugin documentation to learn about prerequisites and limitations. 3. Copy the plugin on already installed Fuel Master node. If you do not have the Fuel Master node yet, see Mirantis Quick Start Guide. scp <fuel_plugin-file> root@:<the_fuel_master_node_ip>:/tmp 4. Log into the Fuel Master node and install the plugin: cd /tmp fuel plugins --install <fuel-plugin-file> 5. After your environment is created, open Settings tab on the Fuel web UI, scroll down the page and select the plugin checkbox. Finish environment configuration and click Deploy button. For Fuel plugins CLI reference, see the corresponding section. 2015, Mirantis Inc. Page 16

23 Create a new OpenStack environment Create a new OpenStack environment After you complete the steps in Download and Install Fuel, the Fuel UI screen shows all your Slave nodes as "Unallocated nodes"). You can now create, configure, and deploy your first OpenStack environment. One Fuel Master can deploy and manage multiple OpenStack environments but you must create each environment separately. Step Description Click on the "New" OpenStack environment" icon to create a new environment. Modify the Fuel password (optional) Approve collection of anonymous statistics Choose the name for your environment and choose the Operating System (distro) Choose your Hypervisor Select your network service (Nova-network, Neutron with GRE segmentation or Neutron with VLAN segmentation. Select your storage backends for Cinder and Glance. Choose additional related projects. Select Create and click on the icon with your named environment. Additional Information See Launch Wizard to Create New Environment See Change Fuel Password See Approve Statistics Gathering See Name Environment and Choose Distribution See Hypervisor See Network service. If you choose Nova-network, you can choose FlatDHCP or VLAN Manager later in the Network settings tab. See Storage backend for Cinder and Glance See Related projects See Complete the creation of your environment Launch Wizard to Create New Environment If you have not already done so, point a browser window to to log into the Fuel UI. See Boot the Fuel Master Node for more information. The Fuel Login screen appears: 2015, Mirantis Inc. Page 17

24 Change Fuel Password Use the admin username and the Fuel password you created above. The Fuel UI screen appears: Click on the "New OpenStack environment" icon to launch the wizard that creates a new OpenStack environment. If you are deploying a Mirantis OpenStack environment that is integrated with VMware vsphere, follow the instructions in Deploying vcenter. Change Fuel Password You can change the Fuel password from the Fuel UI screen; click on "Change password" at the upper right of the screen. The following screen is displayed: 2015, Mirantis Inc. Page 18

25 Approve Statistics Gathering Type in the old password and then the new password, confirm the new password; click on the eye icon on the right of each line to display the string you typed. Click "Apply" to register the new password and return to the previous page. See Fuel Access Control for more information about Fuel passwords. Approve Statistics Gathering Use this screen to define the statistics that are sent to Mirantis about your environment: You have the following options: Send usage statistics collects and sends anonymous usage statistics such as settings, actions, hardware configuration, and version information. The usage statistics are completely anonymous and do not include information such as passwords, IP addresses, or node names. Uncheck this box to disable the collection of usage statistics. Identify my error reports authorizes Mirantis to associate error reports generated for your environment so that Mirantis Support staff can assist you. Note The Community version of Mirantis OpenStack has a different version of this screen that does not include the "Identify my error reports" section. 2015, Mirantis Inc. Page 19

26 Name Environment and Choose Distribution If you do not have a Mirantis account yet, click Create Account and enter the contact information that Mirantis Support can use. If you do not remember your password, click Retrieve Password. Name Environment and Choose Distribution When you click on the "New OpenStack Environment" icon on the Fuel UI, the following screen is displayed: 2015, Mirantis Inc. Page 20

27 Name Environment and Choose Distribution Give the environment a name and select the Linux distribution from the drop-down list: Juno on Ubuntu ( )(default) Juno on CentOS 6.5 ( ) This is the operating system that will be installed on the target nodes in the environment. See Linux Distribution for Nodes for guidelines about choosing the distribution to use. The number in parentheses is the version number for each environment version; it is formed by concatenating the Juno Release number and the Mirantis OpenStack Release number. In this case, the "2014.2" string corresponds to the Juno release version; the "6.1" string is the Mirantis OpenStack release number. Note that the list displayed under the "Releases" tab at the top of the Fuel home page lists all the releases that Fuel 6.1 can manage in your environment. If you upgraded Fuel from an earlier Mirantis OpenStack release, Fuel 6.1 can manage environments that were previously deployed using those releases. It cannot, however, deploy a new environment using those releases. 2015, Mirantis Inc. Page 21

28 High-availability (HA) mode High-availability (HA) mode Prior to Fuel 6.1, it was possible to choose between multi-node and multi-node with HA modes. Starting from Fuel 6.1, the only supported deployment mode is HA. 2015, Mirantis Inc. Page 22

29 Hypervisor Hypervisor Choose one of the following: KVM -- Choose this option for bare-metal installations. QEMU -- Choose this option for VirtualBox installations. vcenter -- Choose this option if you have a vcenter environment with ESXi servers to be used as hypervisors. Note Beginning with Fuel 6.1 release, you can select two hypervisors (vcenter+qemu or vcenter+kvm) to enable dual hypervisor support in one environment. To do that, you should choose between KVM and QEMU and click the corresponding radiobutton. After that, you only have to select the vcenter checkbox. If you would like to have vcenter hypervisor only, then you should select vcenter checkbox, enter the settings and avoid adding compute nodes. For instructions, see VMware tab section. 2015, Mirantis Inc. Page 23

30 Network service Network service Five network topologies are supported; see Choose Network Topology. You can choose any of the Neutron topologies on this screen. If you choose Legacy Networking (nova-network) here, you can choose between the FlatDHCP and VLAN topologies on the Network Settings page. 2015, Mirantis Inc. Page 24

31 Storage backend for Cinder and Glance Storage backend for Cinder and Glance The default providers are LVM for Cinder, local device for Swift, and Swift for Glance. Before the deployment starts, you can change these settings on the Storage screen, where you can also set the Ceph replication factor. See Choosing the Storage Model for more information about Cinder, Glance, and Ceph. 2015, Mirantis Inc. Page 25

32 Related projects Related projects Choose additional related projects that should be included in your environment: For information about planning your Ceilometer (OpenStack Telemetry) deployment, see Ceilometer and MongoDB. For additional information about deploying Sahara (formerly known as "Savanna"), see Installing Sahara. For additional information about deploying Murano, see Murano Deployment Notes. Note that you can modify these choices later on the Services included in the environment screen. 2015, Mirantis Inc. Page 26

33 Complete the creation of your environment Complete the creation of your environment Select "Create" and click on the icon for your named environment. When Fuel reports that your environment has been created, you can click on "New OpenStack Environment" to create another environment, or you can click on the icon for your environment to display the Fuel console from which you can configure and manage your environment. 2015, Mirantis Inc. Page 27

34 Configure your Environment Configure your Environment After you create your OpenStack environment, click on the icon for that environment. Fuel displays a set of configuration tabs that you use to finish configuring your environment. Step Description Add nodes to your environment Assign a role or roles to each node server. Customize disk partitions In Network tab, configure the network settings from the address plan prepared earlier. Set up NIC bonding (optional) Map logical networks to NICs Click Verify Networks to check and confirm the network configuration. (Optional) In the Settings tab, you can configure or modify the options for Horizon access, scheduler type, logging, and other OpenStack options. Click the Deploy Changes button. (Optional) Set up and test Sahara Additional Information See Add nodes to the environment See Assign a role or roles to each node server See Disk partitioning See Network settings See Setting NIC bonding (NIC aggregation) See Mapping logical networks to physical interfaces on servers See Verify Networks See Settings tab See Deploy Changes See Installing Sahara Each of these steps is discussed below in more detail. If necessary, you can stop deployment or reset the environment. 2015, Mirantis Inc. Page 28

35 Add nodes to the environment Add nodes to the environment The initial screen shows the total number of nodes that have been discovered in your environment and the number of nodes that are unallocated. Click on the "Add nodes" button to add nodes to your environment: Assign a role or roles to each node server The first screen that is displayed has a list of roles at the top and a list of unallocated nodes at the bottom. A node is a physical or virtual server that is provisioned to run a specific set of OpenStack services. A role is a functional set of services that Fuel installs as a whole on a node, usually in its own disk partition. To assign roles to the nodes: Select the role or roles you want to assign; roles that cannot be assigned are indicated. Click on the appropriate node(s) in the "Unallocated Nodes" list. Click on the "Apply Changes" button. 2015, Mirantis Inc. Page 29

36 Add nodes to the environment Proceed to do this until roles have been assigned to all nodes. As you make your selections, Fuel displays an icon (a gold triangle with an exclamation point) next to roles that are not allowed. It also tells you about other environment settings that are required. If you want to modify the roles assigned to a node: If you assigned the wrong role to a node (for example, you defined a node as a Compute node but want it to be a Ceph OSD node), select that node and click the "Delete" button. This moves that node back to the pool of "Unallocated nodes" so you can click on "Add Node" to assign a new role. If you want to add a role to a node (for example, you defined a node as a Compute node but want it to also have a Ceph OSD role), select that node and click the additional roles you want to assign (in this case, click the "Ceph OSD" node and leave the "Compute" role selected); click the "Apply Changes" button. When you click the "Apply Changes" button, Fuel displays the configuration you have chosen: 2015, Mirantis Inc. Page 30

37 Disk partitioning To rename the nodes, click on the "Untitled" string for each node and then type in the name you want to use. The suffix is the last digits of the MAC address for this node; you can keep these digits or delete them. Beginning with Fuel 6.1, you can remove a node from inventory if it is dead or there is need to delete it from the cluster. To do that, you should click Forget button next to the required node. This works for any offline node both deployed and not. To remove any node from inventory using the Fuel CLI, see Remove a node from Fuel DB. For more information, see: OpenStack Environment Architecture describes the Controller, Compute, and Storage nodes. Choosing the Storage Model for more details about the ramifications of the different Storage roles. Nodes and Roles includes guidelines about setting up nodes. MongoDB for information about MongoDB. Operating System Role defines the Operating System role and points to other documents with additional information. Disk partitioning Fuel allocates some reasonable amount of disk space for each role that is assigned to a node. To modify this allocation, select the node(s) you want to modify and click on the "Configure Disks" button. You can also access this screen by clicking the gear wheel to the right of the node listing; in the detailed information window that is displayed, click the "Configure Disks" button. 2015, Mirantis Inc. Page 31

38 Disk partitioning This displays a screen with a bar for each disk; color-coded sections represent the disk partitions that have been assigned. The following partition types may be configured: Base System: comprehensive of swap space, includes operating system and basic software Virtual Storage: used by Nova running instances Image Storage: used by Glance to store images Cinder: used by Cinder Ceph and Ceph Journal: used by Ceph MongoDB: used for Ceilometer information stored in MongoDB Mysql database: stores Zabbix statistics on Zabbix nodes To modify the disk allocation, click on the bar for a disk. This example is for a node that runs both a Compute node and a Storage - Cinder role; clicking on the center bar gives a display similar to the following: To change the disk allocation for a specific role, just type in the amount of space (in MB) you want to allocate. You can use round numbers; Fuel adjusts this number to satisfy block size boundary requirements and such. The display adjusts to show the new allocation; click on the "Apply" button in the lower right of the screen to save the modifications and return to the Node List. Click on the "Back to Node List" button in the lower left of the screen if you do not want to change the disk allocation. 2015, Mirantis Inc. Page 32

39 Disk partitioning Note the following: Disk partitions can be customized only after a role is assigned to the node. If you have multiple nodes that have identical hardware and identical roles, you can partition all their disks at the same time by selecting them all and then clicking the "Configure Disks" button. If the node's roles are modified, the disk configuration is reset to default values. 2015, Mirantis Inc. Page 33

40 Network settings Network settings Use the "Network Settings" tab to notify Fuel about the network hardware that is configured. Different pages are used, depending on the network topology you chose on the Network service screen. For more information, see Public and Floating IP address requirements. Neutron network settings These example screens are for a Neutron deployment, which includes sections for setting the L2 and L3 configuration that are not provided for Nova-network deployments. 2015, Mirantis Inc. Page 34

41 Network settings 2015, Mirantis Inc. Page 35

42 Network settings Nova-network settings These example screens illustrate the Network Settings page when using Nova-network: 2015, Mirantis Inc. Page 36

43 Network settings 2015, Mirantis Inc. Page 37

44 Setting NIC bonding (NIC aggregation) Setting NIC bonding (NIC aggregation) NIC bonding is an optional step that allows you to aggregate multiple physical links into a single link; this increases the speed and provides fault tolerance for the network connection. NIC bonding should be done before or in the scope of mapping logical networks to NICs. Use "Configure Interfaces" tab to configure interface bonding. 1. Select node(s) and click "Configure Interfaces". Select interfaces to be aggregated. All interfaces except Admin-PXE can be aggregated. 3. Click "Bond interfaces". Now you can select the appropriate bonding mode from the "Mode" drop-down list. 4. Reassign networks, create additional bonds, etc. You can make all required changes and click "Apply" after that. 2015, Mirantis Inc. Page 38

45 Mapping logical networks to physical interfaces on servers You can add one or more interfaces to the bond. Select a bond and the interface(s) to add, then click "Bond Interfaces". Interface(s) can be removed from the bond when the bond has 3 or more slave interfaces. To remove an interface from a bond, click "Remove" at the left-bottom from interface icon. To unbond interfaces, select bond and click "Unbond Interfaces". Mapping logical networks to physical interfaces on servers Fuel allows you to use different physical interfaces to handle different types of traffic; see Logical Networks for more information. A logical network can be mapped to either a NIC or to a bond of NICs. To access this screen, select a node or nodes and click the "Configure Interfaces" button. You can also access this screen by clicking the gear wheel to the right of the node listing; in the detailed information window that is displayed, click the "Configure Interfaces" button. 2015, Mirantis Inc. Page 39

46 Mirantis OpenStack v6.1 Mapping logical networks to physical interfaces on servers On this screen, you can drag-and-drop logical networks to physical interfaces according to your network setup. All logical networks other than the Admin ("Fuel") network are presented on the screen. It runs on the physical interface from which the node was initially PXE booted, In the current version, it cannot be mapped onto any other physical interface. Note that, once the network is configured and OpenStack is deployed, you may not modify network settings, even to move a logical network to another physical interface or VLAN number. 2015, Mirantis Inc. Page 40

47 Verify Networks Verify Networks When you have applied all your information to the "Network Settings" screen, click the "Verify Networks" button at the bottom of the screen. This checks and confirms the network configuration The network check includes tests for connectivity between nodes via configured VLANs on configured host interfaces. Additionally, checks for an unexpected DHCP server are done to ensure that outside DHCP servers will not interfere with deployment. The image below shows a sample result of the check. If there are errors, it is either in your configuration of interfaces or possibly the VLAN tagging feature is disabled on your switch port. Resolve any errors before attempting to deploy your environment. After doing that, run the check once more. The Verification succeeded message should appear. Note Currently, network verification does not check interfaces in bonds taking them for simple interfaces. In case of LACP L2 bonding, verification fails on the hardware. Due to this problem, interfaces in LACP bonds are excluded from the checklist. Beginning with Fuel 6.1, if you press Deploy button the Fuel web UI will display network verification warnings in the following three cases: you have not verified networks at all: 2015, Mirantis Inc. Page 41

48 Verify Networks your network verification is in progress: your network verification failed: 2015, Mirantis Inc. Page 42

49 Settings tab Settings tab The "Settings" tab allows you to set or modify various values for the system. Many other values can be set by editing configuration files and running command-line tools on the nodes. The "Settings" tab provides configuration access to: Security: reset login credentials for Horizon, set/reset login credentials for vcenter, set the SSH Public Key that will be authorized to access target nodes. Logging: set configuration parameters for Syslog, turn debug logging on/off Modify the characteristics defined when you first created the Fuel environment, including which additional components (Sahara, Murano, and Ceilometer) are included, the hypervisor type, and the storage backend that are configured. Instance management: whether to automatically assign a floating IP to a new instance, whether to restart guests when the host reboots, and which scheduler to use to determine how to dispatch compute and volume requests. After you modify values on the "Settings" screen, click the "Load Settings" button at the bottom of the screen. If you want to go back to the Fuel default values, you can click on the "Load Defaults" button at the bottom of the screen. Access permissions for Horizon This section of the Settings screen allows you to modify the user name, password, and tenant used to access the Horizon dashboard. Provision Method This section appears on the Settings tab of Fuel Web UI where you can choose between Classic Fuel Provisioning (which uses the native CentOS or Ubuntu installation mechanisms) or the Image based provisioning (which copies pre-built OS images on nodes): 2015, Mirantis Inc. Page 43

50 Settings tab Repositories Define repositories to download the operating system and various updates. For detailed information see Configuring repositories. 2015, Mirantis Inc. Page 44

51 Settings tab Services included in the environment Use this screen to modify the services you chose on the Related projects screen when you first created your environment. 2015, Mirantis Inc. Page 45

52 Settings tab Common settings This section of the screen enables you to: Turn debug logging on/off Define Nova quotas Modify the Hypervisor choice you made when first creating your environment Choose whether to auto-assign floating IPs Choose the scheduler driver to use in the environment Select whether to use qcow format for images Select whether to start/restart guests when the host boots Set Public key for deployed nodes Setting debug level for the environment Use this field to set DEBUG level logging for all services in the environment: Debug logging consumes massive amounts of disk space as well as memory and CPU resources on the Fuel Master node and all OpenStack nodes in the environment. It should not normally be run unless you are attempting to diagnose a problem, and you may want to offload or delete the logs generated when you are finished with them. Choose the Compute Node Scheduler The Filter Scheduler, Nova uses a set of filters plus a weighting algorithm to determine the best Compute Node on which to deploy a new VM instance. The Filter Scheduler is generally superior to the older scheduler and should be used for most environments; use this screen to choose the older scheduler if necessary. Choose image format Select image format for ephemeral storage. When this option is selected, ephemeral volumes will be created as a copy-on-write layer of the base image. Without this option selected, ephemeral volumes will be full copies of the base image. The default setting is to use copy-on-write for ephemeral volumes. This option has no effect when using Ceph for ephemeral storage. 2015, Mirantis Inc. Page 46

53 Settings tab Public Key The Public Key field defines the SSH key that will be used by each target node. Fuel pushes this key to each target node that is created in the initial deployment and to each node that is added to this environment after the initial deployment. Note that the Public Key defined here is used only for the target nodes in this environment; if you create other environments, you must configure the public key for each of them. See Uploading Public Keys for information about uploading a public key to the Fuel Master node. Setting initial kernel parameters for target nodes Use the "Initial parameters" box to set kernel parameters for all target nodes that Fuel will deploy: Note that this does not set kernel parameters for the Fuel Master node or for nodes that have already been deployed; see ref:kernel-parameters-ops. For more information, see How To: Modify Kernel Parameters Configuring syslog Fuel deploys the OpenStack environment to use the standard Linux syslog facility to log the activity of all services. By default, rsyslog is configured to use the Fuel Master node as the remote syslog server that contains all logs generated on all nodes in the environment. If you prefer to use an external server for rsyslog, specify the IP address and port number in this field: See Logs and messages for more details. 2015, Mirantis Inc. Page 47

54 Settings tab Mellanox Neutron components This section explains how to configure Mellanox ConnectX-3 adapters in your environement. See Mellanox ConnectX-3 network adapters for planning information. Kernel parameters configuration: When enabling SR-IOV or iser block storage, the intel_iommu=on kernel parameter will be automatically added on all nodes. Mellanox Neutron plugin configuration: In order to work with other plugins without SR-IOV, such as OVS, please select "Install only Mellanox drivers". In order to work with SR-IOV mode, select "Install Mellanox drivers and SR-IOV plugins". After choosing the Mellanox SR-IOV plugin, an editable text box for changing the number of virtual functions is enabled. Note: The maximum number of supported vnics is 16. See HowTo Install Mirantis Fuel 5.1 OpenStack with Mellanox Adapters Support to get instructions for changing the maximum number of vnics. iser configuration: In order to use high performance block storage, select "ISER protocol for volumes (Cinder)" checkbox in the storage section. The requirements for enabling iser are: "Cinder LVM over iscsi for volumes" should remain selected. Either "Install only Mellanox drivers" or "Install Mellanox drivers and SR-IOV plugins" should be checked in the Mellanox Components section. Note: HowTo Install Mirantis Fuel 5.1 OpenStack with Mellanox Adapters Support includes advanced information regarding Mirantis Openstack installation over Mellanox hardware. 2015, Mirantis Inc. Page 48

55 Resetting the Zabbix password Storage You can use this screen to modify the choices made for persistent storage on the Storage backend for Cinder and Glance screen. You can also select Ceph RBD storage for ephemeral volumes on this screen. Be sure that you have assigned the appropriate roles on the Assign a role or roles to each node server screen to support the storage backends you select here. For example, if you configure any Ceph storage options here, you must configure an appropriate number of Ceph OSD nodes; if you configure a Cinder LVM over iscsi role here, you must configure a Cinder LVM node. The "Ceph replication factor" value determines the minimum number of Ceph OSD nodes that must be deployed. At least three Ceph OSD nodes are recommended for production environments but it is possible to set this value to 1 and then run OpenStack with a single Ceph OSD node. Resetting the Zabbix password You can reset the Zabbix password on this screen: 2015, Mirantis Inc. Page 49

56 Deploy Changes Deploy Changes When you have made all the configuration changes you want to make, click the "Deploy Changes" button to deploy the environment you have defined. When you are satisfied with your configuration, click on the "Deploy Changes" button. The following screen is displayed to summarize the configuration modifications you have made: This is your last chance to change the configuration; check it carefully and, if this is not the configuration you want to deploy, click "Cancel". If this is the configuration you want, click "Deploy"; after this, you cannot modify the configuration without starting over. It can take fifteen minutes to an hour to deploy Mirantis OpenStack, depending on the options chosen; deployment times out at two hours. You can monitor the progress by opening the Nodes tab or by checking individual node logs in the Logs tab. Stopping Deployment from Web UI Click on the small red button that appears to the right of the progress bar after you click "Deploy changes" and deployment itself starts: Clicking this button interrupts the deployment process; this is useful if, for example, you realize you made an error in the configuration. This may lead to one of two possible results: 2015, Mirantis Inc. Page 50

57 Resetting environment after deployment 1. If no nodes have finished deployment (reached "ready" status), all nodes are rebooted back to bootstrap. The environment is reset to the state it had right before "Deploy Changes" was pressed; the environment may then be redeployed from scratch. Two things will happen in UI: All nodes are marked as offline and are eventually return back online after reboot. You can not deploy an environment that includes offline nodes, so the next deployment should not be started until all nodes have been successfully discovered and reported as online in the UI. All settings will be unlocked on all tabs and for all nodes, so that you can change any setting before starting a new deployment. This is quite similar to resetting the environment (Resetting environment after deployment). 2. Some nodes are already deployed (usually controllers) and have reached "ready" status in the UI. In this case, the behavior is different: Only nodes which did not reach "ready" status are rebooted back to bootstrap; deployed ones remain intact. Settings remain locked because they have been already applied to some nodes. You may reset the environment (Resetting environment after deployment) to reboot all nodes, unlock all parameters, and redeploy an environment from scratch to apply them again. Resetting environment after deployment The deployment process may be completed in one of three ways (not including deleting the environment itself): 1. Environment is deployed successfully 2. Deployment failed and environment received an "error" status 3. Deployment was interrupted by clicking "Stop Deployment" button (see Stopping Deployment from Web UI) Any of these three possibilities causes the "Reset" button in the "Actions" tab to become unlocked: 2015, Mirantis Inc. Page 51

58 Resetting environment after deployment Click this button to reset the whole environment back to the state it was in right before the "Deploy changes" button was first clicked. All nodes will be offline; they will come back online after reboot. You can not deploy an environment that includes offline nodes, so you should start the next deployment after all nodes have been successfully discovered and reported as online in UI. All settings will be unlocked on all tabs and for all nodes, so you can modify any setting before starting a new deployment. Note, that beginning with Fuel 6.1, the Fuel web UI displays warnings if you try to press Deploy button with network verification in progress, failed or skipped. See Verify networks for more details and screenshots. 2015, Mirantis Inc. Page 52

59 Next Steps Next Steps After you successfully deploy your OpenStack environment, you should do the following: Set up shell access to the Fuel Master and target nodes. You will need to use some shell commands to manage your environment. Run some tests to ensure that the deployed environment is sound: Run Verify Networks. Even though you ran this before you deployed the environment, it is wise to run it again on the deployed network. Network Troubleshooting may be useful. Run the Post-Deployment Check tests, including the "Additional Checks" listed. Run the Post-Deployment checks for other services if you included them in your environment: Sahara Murano Check other components: If you implemented Ceph as your storage back-end, follow the Verifying the deployment instructions to check the deployment. If you find problems, Troubleshooting Ceph may help you resolve them. Run a backup and store the backup in an appropriate location. To rename, reset, or delete an environment, click on the Actions tab on the Fuel dashboard and follow the instructions on the screen. Manage your environment using the Horizon dashboard (click on the link on your Fuel Dashboard) and command-line tools: For more information about using the Horizon dashboard, see the OpenStack. Create projects/tenants and users; see Managing Projects and Users. If you deployed an OpenStack environment that is integrated with the vcenter server, see Running vcenter for information about managing the environment. 2015, Mirantis Inc. Page 53

60 Post-Deployment Check Post-Deployment Check Even a successful deployment may result in some OpenStack components not working correctly. If this happens, Fuel offers the ability to perform post-deployment checks to verify operations. Here we discuss how to run these tests; see Details of Health Checks for details about the steps these tests take. Part of Fuel's goal is to provide easily accessible status information about the most commonly used components and the most recently performed actions. To perform these checks you will use Sanity and Functional checks, as described below: Sanity Checks Reveal whether the overall system is functional. If these tests fail, you probably need to restart some services to operate OpenStack. Functional Checks Dive in a little deeper and reveal networking, system-requirements, functionality issues. Sanity Checks will likely be the point on which the success of your deployment pivots, but it is critical to pay close attention to all information collected from theses tests. Another way to look at these tests is by their names. Benefits Using post-deployment checks helps you identify potential issues which may impact the health of a deployed system. All post-deployment checks provide detailed descriptions about failed operations and tell you which component or components are not working properly. Performing these checks manually would consumed a great deal of time, but it only take a few minutes to run the full suite of tests from the Fuel console. Aside from verifying that everything is working correctly, the process also determines how quickly your system works. Post-deployment checks continue to be useful after you initially deploy your environment. For example, after sizable changes are made in the environment, you can use the checks to determine if any new failure points have been introduced. Running Post-Deployment Checks Now, let`s take a closer look on what should be done to execute the tests and to understand if something is wrong with your OpenStack environment. As you can see on the image above, the Fuel UI now contains a Health Check tab, indicated by the Heart icon. All of the post-deployment checks are displayed on this tab. If your deployment was successful, you will see a list of tests this show a green Thumbs Up in the last column. The Thumb indicates the status of the component. If you see a detailed message and a Thumbs Down, that component has failed in some manner, and the details will 2015, Mirantis Inc. Page 54

61 What To Do When a Test Fails indicate where the failure was detected. All tests can be run on different environments, which you select on main page of Fuel UI. You can run checks in parallel on different environments. Each test contains information on its estimated and actual duration. There is information included about test processing time from in-house testing and indicate this in each test. Note that average times are listed from the slowest to the fastest systems tested, so your results may vary. Once a test is complete, the results will appear in the Status column. If there was an error during the test, the you will see the error message below the test name. To assist in troubleshooting, the test scenario is displayed under the failure message and the failed step is highlighted. You will find more detailed information on these tests later in this section. An actual test run looks like this: What To Do When a Test Fails If a test fails, there are several ways to investigate the problem. You may prefer to start in Fuel UI, since its feedback is directly related to the health of the deployment. To do so, start by checking the following: Under the Health Check tab In the OpenStack Dashboard In the test execution logs (in Environment Logs) In the individual OpenStack components' logs Certainly there are many different conditions that can lead to system breakdowns, but there are some simple items that can be examined before you start digging deeply. The most common issues include: 2015, Mirantis Inc. Page 55

62 High Availability checks Not all OpenStack services are running Some defined quota has been exceeded Something has broken in the network configuration A general lack of resources (memory/disk space) The first thing to be done is to ensure all OpenStack services are up and running. To do this, you can run the sanity test set or execute the following command on your Controller node: nova-manage service list If any service is off (has XXX status), you can restart it using this command: service openstack-<service name> restart If all services are on, but you`re still experiencing some issues, you can gather information from OpenStack Dashboard (exceeded number of instances, fixed IPs, etc). You may also read the logs generated by tests which are stored in Logs -> Fuel Master -> Health Check and check if any operation is in ERROR status. If it looks like the last item, you may have underprovisioned our environment and should check your math and your project requirements. High Availability checks The following tests are available to check High Availability (HA): Check data replication over MySQL Check amount of tables in OS databases is the same on each node Check Galera environment state RabbitMQ availability RabbitMQ replication Platform Tests Description Platform tests verify basic functionality of Heat, Sahara and Murano services. Typically, preparation for Sahara testing is a lengthy process that involves several manual configuration steps. See the following: Preparing Sahara for Testing Sahara Test Details Preparing Murano for Testing Murano Platform Test Details Details of Heat Platform Tests 2015, Mirantis Inc. Page 56

63 Installing Sahara Installing Sahara To install Sahara and run Hadoop in your OpenStack environment: 1. Select the "Install Sahara" check box on the Fuel UI screen or in the environment settings. 2. Download the appropriate pre-built image for Hadoop and upload it into Glance: See the Sahara Images page to find a download link. 3. Register the image in the Sahara Image Registry. This can be done in Project -> Data processing -> Image Registry. Here click on 'Register Image' button. Specify the username appropriate to the image you use. Usernames can be found in Sahara Images. Specify plugin and version corresponding to the image from the dropdowns and add the required tags with 'Add plugin tags' button. 4. Ensure that you have an adequate pool of floating IPs available: If you are running Neutron networking or Nova-Network with auto_assign_floating_ip parameter set to false, you will need to provide a floating IP pool in each Node Group Template you define. If you are running Nova-Network with auto_assign_floating_ip parameter set to true, you do not have to specify floating IP pool in Node Group Templates; the floating IPs are automatically assigned to each Hadoop cluster member. For information about planning your Sahara deployment, see Planning a Sahara Deployment. For a list of prebuilt images, see Sahara Images. For advanced information about running and testing Sahara, see Sahara Deployment. 2015, Mirantis Inc. Page 57

64 Upgrading and Updating from Earlier Releases Upgrading and Updating from Earlier Releases If you have a functional Mirantis OpenStack 6.0 environment, you can upgrade the Fuel Master node to version 6.1 but leave your current environments in place. Upgrade Fuel from Earlier Versions If you are running Fuel 4.x or earlier, you cannot upgrade to 6.1. If you are running Fuel 5.x, you cannot upgrade directly to 6.1. You will need to upgrade from 5.x to 6.0 first, and then you can upgrade to 6.1. If you are running Fuel 6.0, you can upgrade to Fuel 6.1 Fuel 6.1 console can manage your existing 6.x OpenStack environment(s) and create and manage new 6.1 OpenStack environments. The following table summarizes the available progressions for upgrades of the Fuel Master Node: Initial Fuel version Fuel is upgraded to Upgraded Fuel can manage , then to 5.1.1, then to , then to 5.1, then to then to , then to then to , then to Note the following: Fuel 6.1 can only deploy 6.1 environments. Fuel can manage environments that were deployed with 6.0 releases, assuming that you created the environment with the earlier release and upgraded the Fuel Master node rather than doing a fresh install. 2015, Mirantis Inc. Page 58

65 Upgrading and Updating from Earlier Releases For a list of OpenStack releases and versions that your Fuel Master node can manage, click on the "Releases" tab at the top of your Fuel home page. If you do a fresh install of Fuel 6.1, you cannot manage environments deployed with earlier Fuel versions. If you are running Fuel 4.x or earlier, you cannot upgrade Fuel but must install Mirantis OpenStack 6.1 and redeploy your environment to use the new release. The following procedure upgrades the Fuel software that runs on the Fuel Master node. See How Fuel upgrade works for information about how the upgrade process is implemented. To upgrade the Fuel Master Node: 1. Be sure that no installations are in progress in the environment. 2. Download the upgrade tarball by going to Click Download Now and on your right select Mirantis OpenStack Upgrade. Put the downloaded file to a location on the Fuel Master Node that has at least 2 GB of free space for the archive, and additional 6 GB on the partition where it will be unpacked. If your Fuel Master Node does not have an Internet connection, you may need to download this file to a local system and then transfer the file to the Fuel Master using scp or an SSH client. 3. Extract the tarball contents: cd /var/tmp # Use the directory where the tarball is located lrzuntar filename.tar.lrz Warning The Fuel Master node must have at least 2 GB of RAM in order for lrzip to decompress the upgrade archive. See Fuel Master Node Hardware Recommendations for a full list of hardware requirements for the Master node. If your Fuel Master node does not have enough RAM to decompress the archive, you can unpack it with lrzuntar or its equivalent on another system, then transfer the extracted files to the Master node. 4. Run the upgrade script from that same directory and supply the Fuel administrator (admin user) password:./upgrade.sh --password <password> If you do not specify the password here, you will be prompted for the password. See Fuel Access Control for background information. The upgrade process can take minutes. Some operations (such as uploading images) take several minutes; the listing of updated files may slow down, but this does not mean that the upgrade process has hung. 2015, Mirantis Inc. Page 59

66 Upgrading and Updating from Earlier Releases When the upgrade is complete, the following messages will appear under the Releases tab in the Fuel web UI: New release available: Juno on Ubuntu ( ) New release available: Juno on CentOS 6.5 ( ) 2015, Mirantis Inc. Page 60

67 Role operations Role operations Role object Beginning with Fuel 6.1, you can create, update or delete roles using Nailgun REST API and Fuel Client. For Fuel CLI command reference, see Role operations section. This section provides the Controller role example: id: 9 meta: conflicts: - compute description: The controller initiates orchestration activities and provides an external API. Other components like Glance (image storage), Keystone (identity management), Horizon (OpenStack dashboard) and Nova-Scheduler are installed on the controller as well. has_primary: true limits: min: 1 overrides: - condition: cluster:mode == 'multinode' max: 1 message: Multi-node environment can not have more than one controller node. - condition: cluster:mode == 'ha_compact' message: At least 3 controller nodes are recommended for HA deployment. recommended: 3 name: Controller update_required: - compute - cinder name: controller volumes_roles_mapping: - allocate_size: min id: os - allocate_size: all id: image The following fields are mandatory: name: controller meta: name: Controller description: Description goes here # at least one volume is required volumes_roles_mapping: 2015, Mirantis Inc. Page 61

68 Role operations - allocate_size: min id: os Primary behaviour for node can be enabled with has_primary: true option. If this option is set to during orchestration, you will be able to assign separate tasks for primary-controller and controller. 2015, Mirantis Inc. Page 62

69 Using Fuel CLI Using Fuel CLI Introduction Fuel CLI tool is a powerful tool that allows you to: Operate with environments using the text console only. Modify directly the internal data that you can't modify via the web UI. Avoid data verifications done by the web UI logic. Fuel CLI may break your environment if not used carefully. It is necessary to understand that any modifications done using Fuel CLI take precedence over the settings made from the browser. Fuel shows a special message to inform you: Basic usage Fuel CLI has the following usage pattern: fuel [global optional args] <namespace> [action] <optional args> Example: fuel --env-id=1 node set --node-id=1,4,5 --role=controller,compute where --env-id=1 is a global optional argument pointing to the specific environment, node - is a namespace for all node control functions, set is an action that assigns specific nodes to some environments in certain roles. for getting list of all global optional args and namespaces you can run: fuel --help and for getting actions and optional args for some namespace run: fuel <namespace> --help CLI commands reference 2015, Mirantis Inc. Page 63

70 Using Fuel CLI What stands for acronyms in CLI commands CLI commands contain a number of acronyms. For better understanding of those, see the example command output below. Note Nailgun populates the database with hardware configuration information about all the managed nodes it discovers as well as the configuration and status of each node. The fuel node list command is used on the Fuel Master node to list out the current information about the nodes for the environment: [root@fuel ~]# fuel nodes id status name cluster ip mac ready Untitled (b0:77) :40:fa:cc:cf: ready Untitled (ca:9a) ca:03:e6:b1:13: ready Untitled (0e:64) :1f:eb:91:d8: ready Untitled (c1:ef) :2a:45:36:5d: discover Untitled (e1:c4) None :00:27:1a:e1:c4... id status name... roles pending_roles online group_id ready Untitled (b0:77)... compute True 1 1 ready Untitled (ca:9a)... controller True 1 3 ready Untitled (0e:64)... compute True 2 2 ready Untitled (c1:ef)... controller True 2 5 discover Untitled (e1:c4)... True None The meaning of these fields is: id: The node identifier, assigned incrementally when the node is first discovered (when the Fuel agent sends its first request to the Fuel Master node). This ID is the Primary Key for this record in the database; it is unique and is never reassigned; when you delete a node from the environment, that node's ID is deleted; the next node added to the environment is assigned a new ID that is higher than the highest-numbered ID in the database. 2015, Mirantis Inc. Page 64

71 Using Fuel CLI status: Current state of the node: ready: discover: provisioning: provisioned: deploying: error: Node is deployed and provisioned, ready to use Node is not deployed and not provisioned Node is in the process of being provisioned (operating system is being installed) Node is provisioned but not deployed Node is being deployed (OpenStack is being installed and configured) Deployment/provisiong of the node has failed name: cluster: ip: mac: roles: Name of the node as displayed on the screen when you assign roles to nodes. By default, this is "Untitled" with the final digits of the MAC address used by the Admin interface for that node. You can double-click on that title to change the name. ID of the environment to which the node is assigned. IP address of the admin interface, which is the IP address for the default route. MAC address of the admin interface, determined the same way as the IP address. Role(s) that the node has; populated only after deployment. The following two columns appear at the right end of this display; they are not shown here: pending_roles: online: Before deployment, lists the roles that have been assigned to this node. When deployment is complete, the contents of this field are moved to the roles column For Release 6.x and later, this field can also contain the primary value to indicate that this node is the Primary Controller node. The primary value is persisted in the database through the use of the has_primary field in the openstack.yaml file. Status of the node: False: True: Node is offline. Node is available via the Fuel admin network. group_id: The group node identifier. When you assign roles to your target nodes, Fuel tries to automatically determine the node's group based on the DHCP address. Release For acronyms meaning, see What stands for acronyms in CLI commands. Get list of all available releases: fuel release or short version fuel rel for specific release 2015, Mirantis Inc. Page 65

72 Using Fuel CLI fuel rel --rel <release_number> Networks configuration For acronyms meaning, see What stands for acronyms in CLI commands. Download network configuration. This command reads networks from API and saves them in.yaml format on the file system: fuel rel --rel <release_number> --network --download To see interaction with Nailgun API, run the following command with --debug option: fuel rel --rel <release_number> --network --download --debug GET Modify network configuration. You may want to modify the networks and upload the configuration back: fuel rel --rel <release_number> --network --upload To see interaction with Nailgun API, run the following command with --debug option: fuel rel --rel <release_number> --network --upload --debug PUT data={...} Environment For acronyms meaning, see What stands for acronyms in CLI commands. To list environments: fuel env To create an environment, run the following command using --name and --rel (release) options: fuel env create --name <env_name> --rel <release_number> By default it creates environment in multinode mode, and nova network mode. To specify other modes, you can add optional arguments; for example: fuel env create --name <env_name> --rel <release_number> \ --mode ha --network-mode neutron --net-segment-type vlan Use the set action to change the name, mode, or network mode for the environment; for example: 2015, Mirantis Inc. Page 66

73 Using Fuel CLI fuel --env <env_id> env set --name <NewEmvName> --mode ha_compact To delete the environment: fuel --env <env_id> env delete To update the Mirantis OpenStack environment to a newer version (available since Fuel 5.1): fuel env --update --env <env_id> --rel <release_number> To roll back a failed update, use this same command but modify the release ID. Node For acronyms meaning, see What stands for acronyms in CLI commands. To list all available nodes run: fuel node list and filter them by environment: fuel --env-id <env_id> node list Assign some nodes to environment with with specific roles fuel node set --node <node_id> --role controller --env <env_id> fuel node set --node <node1_id>,<node2_id>,<node3_id> \ --role compute,cinder --env <env_id> Remove some nodes from environment fuel node remove --node <node1_id>,<node2_id> --env <env_id> Also you can do it without --env or --node to remove some nodes without knowing their environment and remove all nodes of some environment respectively. fuel node remove --node <node1_id>,<node2_id> fuel node remove --env <env_id> Delete nodes from Fuel DB. Remove offline nodes: fuel node --node-id <id> --delete-from-db fuel node --node-id <id1> <id2> --delete-from-db 2015, Mirantis Inc. Page 67

74 Using Fuel CLI Remove nodes with any status (--force option provides deletion for any nodes): Node group fuel node --node-id <id> --delete-from-db --force For acronyms meaning, see What stands for acronyms in CLI commands. Node groups are part of the Multiple Cluster Networks feature that is available for Fuel 6.0 and later. To list all available node groups: fuel nodegroup and filter them by environment: fuel --env <env_id> nodegroup Create a new node group fuel --env <env_id> nodegroup --create --name "group 1" Delete the specified node groups fuel --env <env_id> nodegroup --delete --group <group_id> fuel --env <env_id> nodegroup --delete --group <group1_id>,<group2_id>,<group3_id> Assign nodes to the specified node group: fuel --env <env_id> nodegroup --assign --node <node_id> --group <group_id> fuel --env <env_id> nodegroup --assign --node <node1_id>,<node2_id>,<node3_id> --group <gro Roles operations CLI basically implements standard CRUD for operating on a role. List a role: fuel role --rel 2 name id controller 9 compute 10 cinder 11 cinder-vmware , Mirantis Inc. Page 68

75 Using Fuel CLI ceph-osd 13 mongo 14 zabbix-server 15 base-os 16 Create a new role. In this example, we first create a swift role in swift.yaml: meta: description: Installs swift server. has_primary: true # we need primary-swift and swift during orchestration name: Swift name: swift volumes_roles_mapping: - allocate_size: min id: os Then use --create flag to proceed. When created, you can start using a new role for your own tasks: fuel role --rel <2> --create --file <swift.yaml> fuel role --rel <2> name id swift 17 Update role data: fuel role --rel <2> --update --file <swift.yaml> Delete the role: fuel role --rel <2> --delete --role <swift> Configuring Configuration of the environment or some node is universal and done in three stages 1. Download current or default configuration. works for (network, settings, node --disk, node --network). Operations with deployment and provisioning can be node specific. (e.g. fuel --env 1 deployment --node-id=1,2) Example: 2015, Mirantis Inc. Page 69

76 Using Fuel CLI fuel --env 1 network download fuel --env 1 settings download fuel --env 1 deployment default fuel --env 1 provisioning download fuel node --node-id 2 --disk --download 2. Modify the downloaded YAML files with your favorite text editor. 3. Upload files to nailgun server After redeploying your environment with the new configuration, you should create a new backup of the Fuel Master node. You may also want to delete the YAML files since you can easily regenerate them at any time. Some of the generated YAML files contain unencrypted passwords whose presence on disk may constitute a security threat. Example: fuel --env 1 provisioning upload fuel node --node-id 2 --disk --upload Note To protect yourself when using the Fuel CLI to modify configurations, note the following: Back up all of your configurations before you begin any modifications. If you remove something from a configuration file, be sure you do not need it; Fuel CLI overwrites the old data with the new rather than merging new data with existing data. If you upload any changes for provisioning or deployment operations, you freeze the configuration for the entire environment; any changes you later make to the networks, cluster settings, or disk configurations using the Fuel Web UI are not implemented. To modify such parameters, you must edit the appropriate section of each node's configuration and apply the changes with Fuel CLI. Deployment For acronyms meaning, see What stands for acronyms in CLI commands. You can deploy environment changes with: fuel --env <env_id> deploy-changes Also, you can deploy and provision only some nodes like this 2015, Mirantis Inc. Page 70

77 Using Fuel CLI fuel --env <env_id> node --provision --node <node1_id>,<node2_id> fuel --env <env_id> node --deploy --node <node1_id>,<node2_id> Change and Set Fuel password You can change the Fuel Master Node password with either of the following: fuel user --change-password --new-pass=<new_password> Note that change-password option can also be used without preceding hyphens. You can use flags to provide username and password to other fuel CLI commands: --user=admin --password=test See Fuel Access Control for more information about Fuel authentication. Fuel Plugins CLI For summary information on Fuel plugins, see Install Fuel plugins section. Once a plugin is downloaded and copied to the Fuel Master node, you can install it with: fuel plugins --install <fuel-plugin-file> It is recommended that you install rpm plugins using the command above. Nevertheless, if you would like to do that manually, follow these steps: Run the following command: yum install <fuel-plugin-file> Register the plugin in Nailgun with fuel plugins --register <fuel-plugin-name>==<fuel-plugin-version> command. You can run fuel plugins --sync instead, but in this case Fuel Client will update all plugins on the file system in Nailgun. You can see the list of all installed plugins using: fuel plugins --list You should get the following output: fuel plugins --list id name version package_version 2015, Mirantis Inc. Page 71

78 Using Fuel CLI <fuel-plugin-name> To remove a plugin, run: fuel plugins --remove <fuel-plugin-name>==<fuel-plugin-version> To update an rpm plugin, run: fuel plugins --update <fuel-plugin-file> Note Updates are not supported for fp plugins. To see the list of all available options, use fuel plugins --help command. 2015, Mirantis Inc. Page 72

79 VMware integration notes VMware integration notes 2015, Mirantis Inc. Page 73

80 Deploying vcenter Deploying vcenter Preparing for vsphere Integration discusses actions and decisions that should be made before attempting to deploy Mirantis OpenStack with vsphere integration. Note, that before following the instructions below you should make sure that: vcenter is accesible. the login and the password are correct. To deploy an OpenStack cloud that is integrated with the vsphere environment, click on the "New OpenStack environment" icon to launch the wizard that creates a new OpenStack environment. Create Environment and Choose Distribution for vcenter Either the CentOS or Ubuntu distro can be used as the host operating system on the Slave nodes for environments that support integration with vsphere: Select vcenter Hypervisor for vcenter Beginning with Fuel 6.1, you can create a dual hypervisor environment. That means, you now have three options: 1. enable vcenter only - select vcenter checkbox and leave the radio button as is; you will then finish this configuration using VMware tab of the Fuel web UI. See the VMware tab for more details. 2. enable both vcenter and KVM/QEMU - select vcenter checkbox and choose between KVM and QEMU radio buttons. 2015, Mirantis Inc. Page 74

81 Deploying vcenter 3. enable KVM/QEMU only - click the corresponding radio button and leave vcenter checkbox empty. Select Network Service for vcenter Currently, the only support network option for vcenter is nova-network. Choose Backend for Cinder and Glance with vcenter At this step you should select storage backend for Cinder that is going to be used with KVM/QEMU if you deploy compute nodes. You can choose Ceph as the backend for Cinder and Glance with vcenter. If you would like to use Glance with VMware datastore, enable it on the Settings tab of the Fuel web UI and finish backend configuration at the VMware tab. 2015, Mirantis Inc. Page 75

82 Deploying vcenter Related projects for vcenter Nova-network does not support Murano, so you cannot run Murano in the OpenStack environment with vsphere integration. Previously, when you selected vcenter, Compute and Controller roles were assigned to the same node, while Ceilometer compute agent was not present on this node. In Fuel 6.1 release, this logic was changed to provide metrics collection for the instances. For previous Fuel releases, support for collecting polling meters from instances on vcenter was not implemented: only central agent polled services like Glance and Swift on Controller node. No metrics was collected from compute nodes. In 6.1, Ceilometer support for vcenter is implemented according to 1-1 mapping principle (the one done between nova-compute and vsphere cluster). Now Ceilometer compute service is available for each vsphere cluster. That means,every agent polls resources about instances from those that only relate to their vsphere cluster. Every agent uses its own configuration file with authentication parameters for its specific vsphere cluster. What is more, monitoring under Pacemaker is introduced for every Ceilometer compute service to avoid failures (for example, failover of primary controller node) and missing polling data as the result. Complete the creation of your vcenter environment 2015, Mirantis Inc. Page 76

83 Configuring your environment for vcenter Select Create and click on the icon for your named environment. Configuring your environment for vcenter After you exit from the "Create a New OpenStack Environment" wizard, Fuel displays a set of configuration tabs that you use to finish configuring your environment. Let's focus on the steps specific for OpenStack environments integrated with vsphere. Assign a role or roles to each node server For VMware vcenter integration, the nova-compute service (with VCDriver configured) runs on the Controller node. Beginning with Fuel 6.1, the Storage - Cinder Proxy to VMware Datastore role is introduced. It will deploy Cinder with VMDK backend: that means, the new role provides block storage for VMs that are running on VMware vcenter. The already known Storage - Cinder role can be enabled for Cinder with LVM or Ceph. Network settings You should choose either the Nova-network FlatDHCP or the VLAN manager: VLAN manager provides better virtual machine isolation, i.e. enables segregating virtual machine tenants into separate broadcast domains. FlatDHCP manager uses a single IP subnet. Select it if you do not want to configure VLANs on your network equipment. 2015, Mirantis Inc. Page 77

84 Configuring your environment for vcenter Please, note that nova-network will be working in a single-host mode (that means, the process runs on one of the Controllers) if you are using vcenter. When nova-network crashes it will be restarted by pacemaker on the same Controller or on another live Controller, during this period of time, all virtual machines will lose connectivity with external networks. Without vcenter, each compute node holds its own nova-network process (multi-host mode). For information on FlatDHCP and VLAN manager architecture, see Nova Network Topologies. To enable FlatDHCP manager, follow these steps: 1. Click the FlatDHCP manager radio button in the Networks tab: 2. In the Nova-network configuration, enable the 'Use VLAN tagging for fixed networks' checkbox and enter the VLAN tag you selected for the VLAN ID in the ESXi host network configuration: To enable VLAN manager, follow these steps: 1. Click the VLAN manager radio button in the Networks tab: 2. In the Nova-network configuration, select Fixed network size using drop-down menu. Specify Number of fixed networks and enter Fixed VLAN ID range: Click Verify Networks button to check if networks are configured correctly. Press Save settings button to continue. 2015, Mirantis Inc. Page 78

85 VMware tab Settings To enable VMware vcenter for volumes, you should add a node and assign Storage - Cinder Proxy to VMware Datastore role to it, see Assign a role or roles to each node server for details. To enable VMware vcenter managed datastore as a backend for Glance, select VMWare vcenter/esxi datastore for images (Glance) checkbox. VMware tab Beginning with Fuel 6.1 release, all vcenter-related settings are consolidated on the VMware tab of the Fuel web UI. vcenter In this section, you should enter not only vcenter credentials (previously found on the Fuel UI wizard and Settings of the Fuel web UI tab), but also specify Availability zone: For KVM/QEMU nova-compute services, availability zone is nova. You cannot edit its name, because it is the default availability zone used by OpenStack. For vcenter nova-compute services, the availability zone name is set to vcenter by default, but it can be changed. Nova-Computes Beginning with Fuel 6.1, each nova-compute service controls a single vsphere cluster. For each vsphere cluster, you need to configure separate nova-compute service that will be running on the Controller node. The following options are available: 1. for vcenter only environment, do not add any compute nodes. 2015, Mirantis Inc. Page 79

86 Installing Fuel Master Node on vsphere 2. for dual hypervisors support (KVM or QEMU with vcenter), you should do the following: after selecting vcenter checkbox in the Fuel UI wizard, specify vcenter settings (host or IP), username, password and which clusters you want to use. The cluster name is used to specify the cluster you would like to use for OpenStack. Service name is the name that will be used to reference to your cluster in OpenStack. Usually, you can copy cluster name from the field above, but if the cluster name contains non-ascii characters, you must provide valid service name for it (string that contains numbers, letters (a-z) and underscore). Datastore regexp is used to indicate data stores to use with Compute. For example, if you add nas., all data stores that have a name starting with "nas" will be chosen. If you plan to use all available datastores, leave the field blank. In this case, nova-compute service will pick the first data store returned by the vsphere API. To learn more about this setting, see VMware vsphere guide. Press +, add nova-compute services and fill in the information for one more Instance. Network If you decided to use VLAN Manager, enter the interface of ESXi hosts on which VLANs will be provisioned. Glance To enable Glance, you should first select the checkbox on the Settings tab (see VMware vcenter/esxi datastore for images (Glance)). Then, you should enter the information for Glance. For more information about how vcenter support is implemented, see VMware vsphere Integration. Installing Fuel Master Node on vsphere 2015, Mirantis Inc. Page 80

87 Installing Fuel Master Node on vsphere Before you follow this procedure to install the Fuel Master Node on vsphere, you should follow the planning information as described in Preparing to run Fuel on vsphere. To set up your vsphere environment to run Fuel: Step Description Download the Mirantis OpenStack ISO file Upload the ISO file to the vcenter Datastore Create a vcenter Port Group network Create a Virtual Machine connected to that Port Group and mount the ISO the DVD drive Install Fuel Master node Verify that Fuel booted on ESXI Additional Information See Download the Mirantis OpenStack ISO See Upload the ISO to the vcenter Datastore See Create a vcenter Port Group network See Mount the Mirantis OpenStack ISO See Install and Boot the Fuel Master Node on vsphere See Verify that Fuel booted on ESXi Download the Mirantis OpenStack ISO Go to the Mirantis OpenStack download page and download the Mirantis OpenStack ISO image. Upload the ISO to the vcenter Datastore Log into the vsphere web client and click on the vcenter item in the left menu: Now go to the Datastores and choose your datastore (datastore1 in our example): 2015, Mirantis Inc. Page 81

88 Installing Fuel Master Node on vsphere Go to the Actions menu and choose the Browse Files item: Click on the Upload Files icon then browse your filesystem and select the Mirantis OpenStack image: Now you must create a network for Fuel PXE traffic and enable Promiscuous mode on it. Go back to the vcenter screen and choose the Hosts item in the left menu: Click on the host where you want to run the Fuel Master node: 2015, Mirantis Inc. Page 82

89 Installing Fuel Master Node on vsphere Click on the Networking button. Click on the Add Host Networking icon: Create a vcenter Port Group network Choose a Port Group connection type: Choose a switch: Name your network and set the VLAN number. This is optional and depends on your underlying network infrastructure: 2015, Mirantis Inc. Page 83

90 Installing Fuel Master Node on vsphere After the network is created, select the network on the network map by clicking on its name, then click on the Edit Settings icon: In the opened window, click the Security item in the left menu and ensure that Promiscuous mode is set to Accept. Then click the OK button: Create Virtual Machine and Mount ISO Go back to the vcenter screen and choose the Virtual Machines item in the left menu: 2015, Mirantis Inc. Page 84

91 Installing Fuel Master Node on vsphere Click to the Create a Virtual Machine icon: We will create a Virtual Machine from scratch without using any templates: 2015, Mirantis Inc. Page 85

92 Installing Fuel Master Node on vsphere Name your new VM and choose the Datacenter where the MOS ISO is located: Select a compute resource (ESXi host), storage, and compatibility for the VM: 2015, Mirantis Inc. Page 86

93 Installing Fuel Master Node on vsphere Select a guest operating system such as RHEL 6 64-bit: Set the memory size to at least 2GB and HDD size at least 50 GB. The Fuel Master node hardware recomendations are described here: Fuel Master Node Hardware Recommendations. A network adapter must be connected to the Fuel PXE network created above. Mount the Mirantis OpenStack ISO For the CD/DVD drive, choose the "Datastore ISO File" item from the dropdown menu on the right: 2015, Mirantis Inc. Page 87

94 Installing Fuel Master Node on vsphere Navigate through the Datastore and choose the MOS ISO image you uploaded earlier: Then enable the CD/DVD drive by clicking to the "Connect..." checkbox opposite to the drive. The Virtual Machine hardware settings should look like this: 2015, Mirantis Inc. Page 88

95 Installing Fuel Master Node on vsphere Go to the "VM Options" tab and expand the "Boot Options" submenu. Then enable the Force BIOS setup item: Click the "Next" button, verify the new Virtual Machine settings and proceed: You are now ready to install Fuel on vsphere, following the instructions in Installing Fuel Master Node on vsphere. Install and Boot the Fuel Master Node on vsphere At the Virtual Machines screen, select the Fuel VM and run it by clicking the Power on icon: 2015, Mirantis Inc. Page 89

96 Installing Fuel Master Node on vsphere Click to the "Open a virtual machine console" icon: Click somewhere inside of the opened window, wait until the BIOS appears, and use the arrow keys on your keyboard to navigate to the "Boot" tab. Then move the highlighted selection to the CD-ROM drive : Using the + button on the keyboard, move the "CD-ROM Drive" item to the top level: 2015, Mirantis Inc. Page 90

97 Installing Fuel Master Node on vsphere Navigate to the Exit tab, choose the "Exit Saving Changes" item and confirm your decision: When the Mirantis OpenStack ISO boot menu appears, press the "Tab" key on the keyboard and modify the last kernel parameter "showmenu" to "yes". Then press the "Enter" key: 2015, Mirantis Inc. Page 91

98 Installing Fuel Master Node on vsphere Wait until the operating system installation procedure is finished and the Fuel Setup menu occurs: You can change some network parameters of the Fuel Master Node here. For more information, see Changing PXE Network Parameters During Installation. If you want to use the default parameters, just select the "Quit Setup" item on the left and choose the "Quit without saving" button. 2015, Mirantis Inc. Page 92

99 Installing Fuel Master Node on vsphere Wait for the Fuel Master node installation to complete: To reach the Fuel Web UI, you must have IP connectivity to the Fuel Master Node IP through the IP gateway that is connected to the Port Group network we use. In this example, it is the Fuel-PXE network that is connected to the only physical interface on the ESXi Host: with VLAN tag 200. The default network settings for the Fuel Master node are: node IP: /24 gateway and DNS: Verify that Fuel booted on ESXi To test the operability of the Fuel Master Node, you can create another VM on the same ESXi Host and boot it using PXE; it is a default boot option for VMWare. If the boot is successful, the "Total Nodes" counter in the upper right corner of the Fuel Web UI will increase its value after two to five minutes. 2015, Mirantis Inc. Page 93

100 Patching To verify that the Fuel bootstrap node runs on ESXi, open the Node Info window in the Fuel Web UI and verify that the Manufacturer field says "VMWARE": Patching For your user experience and how-to see Applying patches. 2015, Mirantis Inc. Page 94