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="10.255.0.1" >>>>> NETMASK="255.255.0.0" >>>>> GATEWAY="10.255.255.254" >>>>> DNS1="8.8.8.8" >>>>> DNS2="8.8.4.4" >>>>> 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 192.168.122.0/24 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 = 192.168.0.0/24 > This is the BCN, and is usually on 10.20.0.0/16 maybe i messed your tut a bit on my system :) thats how i did it: 192.168.0.200 cluster (virtual ip) 192.168.0.205 mule (node1) (bond0) 192.168.0.211 bacula (node2) (bond0) # mule 10.20.0.1 mule.bcn (bond1) 10.20.1.1 mule.ipmi 10.10.0.1 mule.sn (bond2) # bacula 10.20.0.2 bacula.bcn (bond1) 10.20.1.2 bacula.ipmi 10.10.0.2 bacula.sn (bond2) >> bridge = 10.255.0.1 > The bridge is on the IFN, which in the tutorial is on 10.255.0.0/16, 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="10.255.0.1" >> NETMASK="255.255.0.0" >> GATEWAY="10.255.255.254" >> DNS1="192.168.0.1" >> 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 [email protected] instead. >> http://clusterlabs.org/mailman/listinfo/users >> _______________________________________________ >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha again, lots of thanks for your help. cheers. _______________________________________________ Users mailing list: [email protected] http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
