To install the Cisco Prime Network Registrar virtual appliance, you must first download the correct installation file. There are two files available: a regional virtual
appliance and a local cluster virtual appliance. Each of these virtual appliances is provided as a .qcow2 file.
The names are as follows:
Download the virtual appliance of your choice. Every Cisco Prime Network Registrar local cluster installation must connect to a Cisco Prime Network Registrar regional cluster in order to receive the necessary license information required to operate. Thus, before you install a Cisco Prime Network Registrar local virtual appliance, you must identify the IP address of the regional cluster to which it will connect to receive the
license information.
To run the local cluster or regional cluster on OpenStack, you must first create a local or regional image out using the
.qcow2 distribution kit.
After this image exists, you may launch an instance of the local or regional cluster. The Flavor you associate with the instance
needs at least 4 VCPU, 8 GB of RAM, and at least 48 GB of root disk storage. In order to have an operational instance of Cisco
Prime Network Registrar, you must allocate more than the absolute minimum of 48 GB of root disk storage. See System Requirements for the amount of disk space needed for a local or regional cluster.
An instance of Cisco Prime Network Registrar will be created with a fixed IP address. Cisco Prime Network Registrar will automatically use any IP addresses associated with interfaces that it can detect when it is started. If the interface
available to Cisco Prime Network Registrar has an IP address allocated to it from a provider network (that is, it is accessible to the clients that need the DHCP or
DNS capabilities provided by Cisco Prime Network Registrar), then you can configure Cisco Prime Network Registrar normally.
Note
|
When you install Cisco Prime Network Registrar qcow2 image on the recent versions of OpenStack (such as Victoria), the Cisco Prime Network Registrar processes (DNS, DHCP, and CCM) run fine, but the Java process and web UI may take hours or days to run. This issue is specific
to Java and the QEMU hypervisor. Therefore, we recommend to use the KVM virtualization to have the proper CPU setting.
You can verify the support for KVM virtualization using the following commands:
# lscpu | grep -i "Model Name"
Model name: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
# grep -i -o vmx /proc/cpuinfo | uniq
vmx
The presence of "vmx" in the above output shows that necessary CPU extensions are in place on the Intel processor.
|
When you install a Cisco Prime Network Registrar virtual appliance on VMware, you configure the root password for the underlying Linux system on the system console when the
virtual machine is first booted. However, usually OpenStack instances are created and deployed in such a way as to only allow
logins with SSH using an SSH key-pair that is configured as part of the OpenStack instance. Many OpenStack instances do not
allow root password login at all, and only allow login using SSH with an SSH key-pair.
A Cisco Prime Network Registrar OpenStack instance can be configured to operate in either of these two regimes:
Option 1: Require root password configuration and allow root login using a password.
Option 2: Disable the root password configuration and login. An SSH key-pair is required to login.
Option 1:
This is the default approach for all Cisco Prime Network Registrar virtual appliance kits, and requires no additional actions. You will launch an instance from the Cisco Prime Network Registrar virtual appliance image, and on first boot you will have to bring up a console window for the Cisco Prime Network Registrar instance, enter a root password for the Linux system, and accept the End User License Agreement. After the first boot, you
will not need to access the console. You can also access this instance with an SSH key-pair.
Option 2:
If you wish to deploy the Cisco Prime Network Registrar virtual appliance instance in a way that is more in accordance with the usual practice for OpenStack instance deployment,
you can configure the Cisco Prime Network Registrar OpenStack instance to not allow root logins with a password, and require an SSH key-pair to login. If you also wish to allow
a password based login for a user other than root with root permissions, instructions on how to configure are listed below.
When you launch an OpenStack instance from web UI, to prevent root password login, you will have to perform specific configuration
in the Configuration section of the Launch instance dialog. You will need to provide a customization script - which is analogous to User Data
in other systems. You will need to configure a script (provided below) which will make the OpenStack instance disable the
root password based login. After you deploy an instance configured with this customization script, the only way to gain access
to the Linux operating system on the instance is to login via SSH using the ssh key pair associated with the instance at the time of launch.
For example, you might login with ssh -i keypairname.pem root@a.b.c.d. If you did not associate a key pair with the instance, or have lost access to the key pair, you will not be able to login
to the instance. There is no default root password when the instance is created in this way, and the root password login is
disabled.
To configure option 2, enter the following in the Customization Script text box:
# cloud-boothook
# !/bin/bash
if [ ! -f /etc/cloud/cloud.cfg.orig ]; then
cp /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.orig
cp /etc/cloud/cloud.cfg.norootpasswd /etc/cloud/cloud.cfg
fi
Note
|
If you choose option 2 and once you gained access to the instance using the ssh key pair, if you would like to login with a password as well, you can create a new Linux user using the useradd command and make that user a member of the group wheel. You must also give that user a secure password using the passwd command. Then you can always login with ssh or to the console as that user, and have root privileges.
To create a user to allow password login, use the following command:
useradd safeuser -g wheel
passwd safeuser
Then, if you need root access, login as safeuser and use the following command:
Enter the password for safeuser, and you will become a root user.
|
If the IP addresses that are associated with the available interfaces are fixed addresses (that is, they are only accessible
to other instances in OpenStack), then you need to associate a floating address with Cisco Prime Network Registrar instance. This floating address must then be accessible to the clients of the DHCP or DNS service to be provided by the Cisco Prime Network Registrar instance. You will have to configure the DHCP server provided by Cisco Prime Network Registrar to return the IP address of the floating address as its server-id, instead of the fixed IP address that Cisco Prime Network Registrar can detect that is associated with the interface built into the instance. To configure DHCP for this situation, you need
to be in Expert mode, and configure the DHCP Policy attribute dhcp-server-identifier-address with the floating address allocated to this instance. Then the DHCP server will return the configured IP address (which will
be the externally visible IP address of this instance) instead of the IP address that the DHCP server can detect from examining
the interface that it is using for communications with clients (which is the fixed IP address).
A local cluster needs to be registered with a regional cluster. After this registration, the regional cluster needs to be
able to connect to the local cluster. When the local cluster initially registers with the regional cluster, it sends its IP
address to the regional cluster. If the regional cluster can contact the local cluster by using the IP address that the local
cluster sees is configured to its network interface, then no action is required. This would be the case if the local cluster
has a fixed IP address that is only visible within the OpenStack cloud, but the regional cluster was also in the same cloud.
If the regional cluster can ping the IP address that the local cluster sees as the IP address on its network interface, then
no additional steps are required. However, in the event that the regional cluster is not local to the OpenStack cloud on which
the local cluster is running, and the local cluster has a floating address in addition to a fixed address, then the regional
cluster's configuration for the local cluster needs to have its IP address updated to be that of the floating address (and
not the fixed address, which is what it will have from the initial registration).
When allocating a local cluster, you should consider allocating 4 or even 8 VCPUs and at least 12 GB of RAM, with more for
large systems. Local clusters will absolutely need more than the 7+ GB free space available in the minimal installation. Regional
clusters will probably need an additional disk space, but 2 to 4 VCPUs and 8 to 12 GB of RAM will suffice for many installations.
). Once you start the VM, you cannot change the
memory or CPU settings until you shut down.
Feedback