[ClusterLabs] [Linux-HA] Cluster for HA VM's serving our local network

J. Echter j.echter at echter-kuechen-elektro.de
Wed Sep 23 12:33:01 EDT 2015

Am 23.09.2015 um 16:48 schrieb Digimer:
> On 23/09/15 10:23 AM, J. Echter wrote:
>> Hi Digimer,
>> Am 23.09.2015 um 15:38 schrieb Digimer:
>>> Hi Juergen,
>>>    First; This list is deprecated and you should use the Cluster Labs -
>>> Users list (which I've cc'ed here).
>> i already got that reminder as i sent my message, and i subscribed :)
> I'm switching the thread to there then.
>>>    Second; That tutorial is quite old and was replaced a while ago with
>>> this one: https://alteeve.ca/w/AN!Cluster_Tutorial_2. It has a lot of
>>> improvements we made after having many systems out in the field, so it
>>> is well worth re-doing your setup to match it. It's mostly the same, so
>>> it shouldn't be a big job.
>> i'll have a look over the new one.
> The main change, relative to this discussion, is more descriptive
> interface names.

ok, this can wait, for now. :)

>>>    I'll address your comments in-line:
>>> On 23/09/15 08:38 AM, J. Echter wrote:
>>>> Hi,
>>>> i was using this guide
>>>> https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial_-_Archive to
>>>> set up my cluster for some services, all works pretty good.
>>>> I decided to use this cluster as a HA vm provider for my network.
>>>> I have a little, maybe silly, question.
>>>> The guide tells me to disable qemu default network, like this:
>>>>>        Disable the 'qemu' Bridge
>>>>> By default, libvirtd <https://alteeve.ca/w/Libvirtd> creates a bridge
>>>>> called virbr0 designed to connect virtual machines to the first eth0
>>>>> interface. Our system will not need this, so we will remove it now.
>>>>> If libvirtd has started, skip to the next step. If you haven't started
>>>>> libvirtd yet, you can manually disable the bridge by blanking out the
>>>>> config file.
>>>>> cat  /dev/null>/etc/libvirt/qemu/networks/default.xml
>>>> i skipped the step to create the bridge device, as it was not needed for
>>>> my belongings.
>>> OK.
>>>>> vim  /etc/sysconfig/network-scripts/ifcfg-vbr2
>>>>> # Internet-Facing Network - Bridge
>>>>> DEVICE="vbr2"
>>>>> TYPE="Bridge"
>>>>> BOOTPROTO="static"
>>>>> IPADDR=""
>>>>> NETMASK=""
>>>>> GATEWAY=""
>>>>> DNS1=""
>>>>> DNS2=""
>>>>> DEFROUTE="yes"
>>>> Now i want to know how to proceed?
>>>> i have bond0 - connected to my network (both nodes got different ip's
>>>> from my dhcp)
>>>> bond1 & bond2 are used for corosync and drbd.
>>>> what would be the best decision to have some vm's served from this
>>>> 2-node cluster too?
>>>  From a bridging perspective, the quoted example config above is good.
>>> The default libvirtd bridge is a NAT'ed bridge, so your VMs would get
>>> IPs in the subnet, and the libvirtd bridge would route
>>> them to the outside world. Using the bridge type in the tutorial though,
>>> your VMs would appear to be directly on your network and would get (or
>>> you would assign) IPs just the same as the rest of your system.
>> so i can just use this example on my setup?
>> bond0 = LAN =
> This is the BCN, and is usually on

maybe i messed your tut a bit on my system :)

thats how i did it:   cluster (virtual ip)   mule (node1) (bond0)   bacula (node2) (bond0)

# mule       mule.bcn (bond1)       mule.ipmi       mule.sn (bond2)

# bacula       bacula.bcn (bond1)       bacula.ipmi       bacula.sn (bond2)

>> bridge =
> The bridge is on the IFN, which in the tutorial is on, so
> yes. Note that the IP assigned to the bridge has no bearing at all on
> the IPs set in the VMs.
>> can i use my own dns server, working on the lan?
>> like this:
>> DEVICE="vbr2"
>> TYPE="Bridge"
>> BOOTPROTO="static"
>> IPADDR=""
>> DNS1=""
>> DEFROUTE="yes"
> Sure. With this style of bridging, it's like you VMs are plugged
> directly into the physical switch. What you do on the node has no
> bearing. The only thing is that you move the IP assignment for the node
> out of the bond and into the bridge. In fact, you can assign no IP to
> the bridge and traffic from the VMs will route fine.
> So think of this bridge as being like a regular hardware switch that the
> VMs plug into and that the node itself plugs into, and the bond as the
> "cable" linking the vritual switch to the hardware switch. When you
> think of it like that, you can see how the setup of the node has no
> bearing on anything else.

ok, then i could use any free ip i like, as long i don't use it
elsewhere in my lan (openvpn, etc)

so i could use the above example as it is and it should work :)

still have to get some more network stuff into my head ;)

>>>> thanks, and please tell me what infos i may have forgotten to provide
>>>> for you. :)
>>>> cheers
>>>> juergen
>> thanks for your support.
>> cheers
>> _______________________________________________
>> Linux-HA mailing list is closing down.
>> Please subscribe to users at clusterlabs.org instead.
>> http://clusterlabs.org/mailman/listinfo/users
>> _______________________________________________
>> Linux-HA at lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha

again, lots of thanks for your help.


More information about the Users mailing list