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 are provided as a .ova 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 1 VCPU, 4 GB of RAM, and at least 14 GB of root disk storage. In order to have an operational instance of CPNR, you must allocate more than the absolute minimum of 14 GB of root disk storage. See the System Requirements section 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 (i.e., 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 |
In keeping with the general approach for OpenStack cloud image deployment, root password based login is DISABLED in the .qcow2
kits. The only way to gain access to the Linux operating system on the instance once it is launched is to login via ssh using
the ssh key pair associated with the instance at the time of launch. For example: 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, and root password login is disabled.
|
Once you have gained access to the instance using the ssh key pair, if you would like to be able to login with a password, you could 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 become the root user using sudo su.
To create a user to allow password login, use the following command:
useradd safeuser -g wheel
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 (i.e., they are only accessible
to other instances in OpenStack), then you will 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. In order to configure DHCP for this situation,
you will 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 need be taken. 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 necessary. 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 8 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 additional disk space, but 2 to 4 VCPUs and 6 to 8 GB of RAM will suffice for many installations.