always remember

Nothing is foolproof to a sufficiently talented fool... Make something
idiot proof, and the world will simply make a bigger idiot.

How To: Configure multiple VLAN interfaces in SolusVM

There may be times when you wish to give VM’s on one of your SolusVM nodes access to IP resrouces that are segmented into discrete VLAN’s at network level. If this is the case, you need to create network bridge interfaces on the node, and suply them with your VLAN interfaces. This is explained below.

  1. Configure the base interface, in this example, we ahve trunked eno2 with vlan’s 220 and 221, as we have group of VM’s that require to bind IP’s within this VLAN.
  2. [root@solus-node01]# cat ifcfg-eno2
  3. Configure your VLAN sub interfaces, note that we designate each interface to its own new bridge interface, this is required.
  4. [root@solus-node01]# cat ifcfg-en02.220
    [root@solus-node01]# cat ifcfg-eno2.221
  5. Configure your bridge interfaces.
  6. [root@solus-node01]# cat ifcfg-br2
    [root@solus-node01]# cat ifcfg-br1

    At this point, if you want the host node to have an IP in this VLAN, you would bind it to the bridge interface directly, you can use the usual IPADDR, PREFIX, GATEWAY etc..

  7. ‘UP’ your interfaces.
  8. [root@solus-node01]# ifup eno2.220
    [root@solus-node01]# ifup eno2.221
    [root@solus-node01]# ifup br2
    [root@solus-node01]# ifup br1
  9. Check the state of your bridges.
  10. [root@solus-node01]# brctl show
    <some info redacted>
    br1             8000.0cc47xxxxxxx       no              eno2.221
    br2             8000.0cc47xxxxxxx       no              eno2.220

    Note you should see your 2 new bridges with the relevant vlan interface attached to it, I’ve removed some data here as I use some odd custom work on br0 that would confuse this article.

    Now that you have bridges available, you can begin assigning these to VM’s that need access to it. In my case, I ahd to use KVM Custom Config in SolusVM to be able to A) specifiy the right bridge and B) create a second interface inside the VM.

  11. Custom config for a sample VM.
  12. <domain type='kvm'>
       <type machine='pc'>hvm</type>
       <boot dev='hd'/>
       <boot dev='cdrom'/>
     <clock sync='localtime'/>
        <graphics type='vnc' port='xxxx' passwd='xxxxxxxx' listen=''/>
        <disk type='file' device='disk'>
         <source file='/dev/vg_xxxxxxxx/kvmXXX_img'/>
         <target dev='hda' bus='virtio'/>
        <disk type='file' device='cdrom'>
         <target dev='hdc'/>
        <interface type='bridge'>
         <source bridge='br1'/>
         <target dev='kvmXXX.0'/>
         <mac address='00:16:3c:xx:xx:xx'/>
        <interface type='bridge'>
         <source bridge='br2'/>
         <target dev='kvmXXX.1'/>
        <input type='tablet'/>
        <input type='mouse'/>

    Note that this is heavily edited, the main focus is the duplicate “interface” section, and that the duplicate has no MAC address specified. You can also see that br1 and br2 have been specified. Make a mental note of which one is which so that in your VM, you can assign IP’s in the relevant VLAN.

    Save the custom config and reboot the VM. Assign IP’s once booted into the VM.

  13. Checking your bridge status now should show the VM interface active within it.
  14. [root@solus-node01]# brctl show
    <some info redacted>
    br1             8000.0cc47axxxxxx       no              eno2.221
    br2             8000.0cc47xxxxxxx       no              eno2.220

dave / October 24, 2018 / Code, Guide

How To Upgrade PostgreSQL From 9.3 to 9.4 (In-Place)

To make use of the JSONB features implemented in 9.4, it is required that you upgrade your existing PgSQL 9.3 cluster to 9.4+. I cover the basics on how to perform an in-place upgrade.

1. Add the PostgreSQL repo to apt:

echo "deb utopic-pgdg main" > /etc/apt/sources.list.d/pgdg.list


2. Install the repo’s key:

wget -q -O - | sudo apt-key add

Read On… ->

dave / April 7, 2016 / Guide, PostgreSQL

How To Setup Binary Replication Between 2 PostgreSQL 9.4 Hosts (Hot-Standby)

Utilising a master/slave (hot-standby) setup to provide a resilience layer at database level can be easy. The following assumes you have 2 PgSQL hosts at and, both running Ubuntu 14.04 LTS and PostgreSQL 9.4 (9.4.5).

1. On the master, edit the following in postgresql.conf:

listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 3

listen_addresses can also be scoped down to single or multiple server bound IP addresses, for added security/best practice

Read On… ->

dave / April 7, 2016 / Guide, PostgreSQL