OpenNebula Front End

OpenNebula Front End

The OpenNebula front end is running on a Zotac ID12 plus.   It's a 4 core Atom processor @ 1.8Ghz.  It's equipped with 3 gigs of ram and a 256G disk.  The network connections comprise of an onboard Realtek builtin gig NIC and a USB attach ASIX gig NIC.  The built-in NIC is connected to the SAN/service network and the USB is connected to the access network.  I'm not going to go into the whole frontend install since I used the documentation here.  This frontend is running Ubuntu 18.04 server.  One quick hint,  the Centos/RH and the Ubuntu/Debian instructions are all interleaved.  To cut down on confusion, I would open a separate editor and carefully walk through the instructions and create a document solely for the distribution you are using.   

The OpenNebula packages that are currently installed on my front end are:

• opennebula
• opennebula-common
• opennebula-flow
• opennebula-gate
• opennebula-sunstone
• opennebula-tools
• ruby-opennebula

I made sure that opennebula-flow and opennebula-gate were included because those would be used later with the Kubernetes service deployment. 

LOCAL CHANGES

/etc/netplan/50-cloud-init.yaml

The netplan config on the master looks like:

network:

    ethernets:

        enx000ec6bb3f88:

            addresses:

            - 192.168.200.100/24

            gateway4: 192.168.200.1

            nameservers:

                addresses:

                - 192.168.200.1

        ens32:

            match:

                macaddress: 00:01:2e:bc:b3:5b

            addresses:

            - 192.168.199.100/24

            mtu: 9000

            nameservers: {}

    version: 2

I discovered an oddity about netplan that resulted in not all characteristics being matched to the correct interface.  I was able to work around it by matching the interface with the mac-address as seen in the ens32 stanza.

/etc/fstab

 # /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

# / was on /dev/sda2 during curtin installation

/dev/disk/by-uuid/a30b0ed6-b2a1-401d-954d-31961d04a59a / ext4 defaults 0 0

/swap.img none swap sw 0 0

192.168.199.254:/exports/data/opennebula/0 /var/lib/one/datastores/0 nfs soft,intr,rsize=8192,wsize=8192 0 0

192.168.199.254:/exports/data/opennebula/1 /var/lib/one/datastores/1 nfs soft,intr,rsize=8192,wsize=8192 0 0

192.168.199.254:/exports/data/opennebula/2 /var/lib/one/datastores/2 nfs soft,intr,rsize=8192,wsize=8192 0 0

I mapped each of the datasource directories independently to the NFS server for future flexibility with adding different storage servers.

OpenNebula datastore configuration

 I then went in and changed the DRIVER attribute on each datastore to "qcow2" and checked to make sure that the "Base path" pointed to the appropriate location on the filesystem.