<div dir="ltr">Hi Peter and other Libvirt-Users,<br><br>Thank you, I greatly appreciate your response. The diagram I provided may be a little misleading, so I have attached a new diagram (also available here: <a href="https://i.imgur.com/X3nFMCz.png" title="" style="">https://i.imgur.com/X3nFMCz.png</a> ). I think I also need to provide some more detail about my scenario here:<br><br>These physical nodes are provided to me by "bare-metal cloud" providers like Scaleway / OVH / Packet.net / etc.<br>I have opted to use Ubuntu on each bare-metal server, but I am also well-versed in RHEL/CentOS environments, so if you want to help me out by telling me CentOS-specific details, I'm sure that I can "translate" that to an Ubuntu/Debian setup. Considering my scenario with bare-metal providers, I do <b><u>not</u></b> have the flexibility to add/remove physical NICs as I need them, I am sort of "locked in" to a single-IP/single-NIC configuration for each physical node.<br><br>But, I <b><u>*do*</u></b> have the flexibility of adding more physical nodes as I need them, and I would like to leverage this option when I want to expand my cluster. Its easy for me to buy a bare-metal cloud server (takes a few minutes), and setting up a 1U/2U server by myself on a "lab" network could take me a few hours or so (not to mention, I dont have the resources to host my own network for this). Also, I need to account for the fact that hardware *will* fail somehow eventually, so adding/removing nodes would need to be "easy" in the way that I shouldnt have to configure new DHCP scopes on all the other nodes when I decide to add one more node to the cluster. Also, as a side note, I do not intend to have any central or shared volume pool between the nodes, all storage will be direct on a local LVM volume, and the ability to perform live migrations of guests between hosts is not a high priority for me, I intend for each guest to be <u>"stationary" to each host</u>.<div><br>Each node's <b><font face="monospace">eth0</font></b> is connected via IPSec (unicast and transport mode) to the other. This is to encrypt the communication between all nodes because it travels over the internet. Additionally, each node currently has a <font face="monospace"><b>vxlan0</b></font> interface in the <font face="monospace"><b><a href="http://172.20.0.0/24">172.20.0.0/24</a></b></font> network which allows them to be all on the same "LAN". I have attached a simple diagram illustrating this setup, also available here: <a href="https://i.imgur.com/jc7bc6b.png" title="" style="">https://i.imgur.com/jc7bc6b.png</a> . I would <u>prefer</u> to use the DHCP that comes "built-in" to livbirt, but I am open to running DHCP on each host, or as a guest inside each guest network.<br><br>So, I hope this sheds a little more light on my scenario.<br>If you look at the diagram attached, you can see some <b><font color="#ff0000">red</font></b> lines and some question marks. These red lines are the only part of the environment that needs to be configured, everything else seems to work fine; KVM can provision guests, IPSec tunnel is working, vxlan seems to route/function as I think I would need it, guests can reach the internet, and guests can ping everything else inside the environment, <b><u>except</u></b> guests1 cannot ping guests2.<br><br></div><div>Which makes me question the configuration I have for each guest network.<br>Each guest network is currently configured with NAT Forwarding, but because KVMHost1 cannot ping guests on KVMHost2, I am concluding that a NAT'd guest network is most likely something that I do not want. I have some choices on how to configure each guest network, it could be an "<a href="https://www.redhat.com/archives/libvir-list/2016-August/msg00640.html">open</a>" or "<a href="https://wiki.libvirt.org/page/VirtualNetworking#Routed_mode">routed</a>" network, but I would still need to configure some static routes.<br><br>I will take a stab at doing an open or routed network today, but in the meantime, your thoughts and comments about my setup are still welcome and encouraged.</div><div><br></div><div>Thank you!</div><div>-Cobin</div><div><br></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 30, 2018 at 10:44 PM Peter Crowther <<a href="mailto:peter.crowther@melandra.com" target="_blank">peter.crowther@melandra.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>I have to say that I wouldn't do the networking that way - in fact, in the clusters I manage, we haven't done the networking that way :-). Rather than layer 3 routing between VMs, we've chosen to use layer 2 virtual switching (yes, using openvswitch). We have the luxury of multiple 10G NICs between our hosts, so we've separated out the management network from the guest network, simply to ensure that we retain administrative access to the hosts via ssh. If you want to live a little more dangerously, you could use VLAN or VXLAN on one NIC - or you could spend a few dollars on an extra network card on each host for the peace of mind!<br><br></div>For the project that's been live for two years: we presently run four hosts on the lab's production network (another two on its acceptance-test network, and another one as a "kickaround" host for playing about with configs). Guest VMs on all four
production
hosts share <a href="http://192.168.59.0/24" target="_blank">192.168.59.0/24</a> (why "59" is a story for another day), on an OVS virtual switch on each host named br-guest, with the guest-specific NIC also set as a port on the virtual switch. Guest traffic is therefore sent transparently between the hosts where needed, and we can live-migrate a guest from one host to another with no need to change the guest's IP address. Because we share a common guest network and IP range between all hosts, it's trivial to add (or remove) hosts - no host needs to know anything about routing to another host, and in fact only our management layer cares how many hosts we have.<br><br></div>We happen to have "controller" nodes that run redundant DHCP servers with non-overlapping scopes, but the exact location is not a requirement of this setup. We could equally well set up a DHCP service on the guest network on each host, allowing allocation of e.g. 192.168.59.1 to .100 on one host, .101 to .200 on another host. Guests will typically receive offers from each DHCP server and can choose, which is fine as they're all on the same network. This provides redundancy in case of a full or failed DHCP server, which your routed network approach wouldn't without some careful DHCP forwarding work.<br><br></div>We happen to base our hosts on CentOS 7, but I manage other Debian-derived systems and can probably remember enough about its network setup to help with Ubuntu. Certainly I can help with OVS weirdnesses; it took some time to get my head round exactly how it works. That said, I've never set up a kvm host on Debian.<br><br></div>Good luck; happy to provide further pointers if useful.<br><br></div>Cheers,<br><br></div>- Peter<br></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On 30 May 2018 at 15:32, Cobin Bluth <span dir="ltr"><<a href="mailto:cbluth@gmail.com" target="_blank">cbluth@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Libvirt Users,<br><br>I would like to setup a two node bare-metal cluster. I need to guidance on the network configuration. I have attached a small diagram, the same diagram can be seen here: <a href="https://i.imgur.com/SOk6a6G.png" target="_blank">https://i.imgur.com/SOk6a6G.png</a><br><br>I would like to configure the following details:<br>- Each node has a DHCP enabled guest network where VMs will run. (eg, <font face="monospace"><b><a href="http://192.168.1.0/24" target="_blank">192.168.1.0/24</a></b></font> for Host1, and <font face="monospace"><b><a href="http://192.168.2.0/24" target="_blank">192.168.2.0/24</a></b></font> for Host2)<br>- Any guest in Host1 should be able to ping guests in Host2, and vice versa.<br>- All guests have routes to reach the open internet (so that '<font face="monospace"><b>yum update</b></font>' will work "out-of-the-box")<br>- Each node will be able to operate fully if the other physical node fails. (no central DHCP server, etc)<br>- I would like to <u>add more physical nodes later</u> when I need the resources.<br><br>This is what I have done so far:<br>- Installed latest Ubuntu 18.04, with latest version of libvirt and supporting software from ubuntu's apt repo.<br>- Each node can reach the other via its own eth0.<br>- Each node has a working vxlan0, which can ping the other via its vxlan0, so it looks like the vxlan config is working. (I used <font face="monospace"><b>ip link add vxlan0 type vxlan...</b></font>)<br>- Configured route on Host1 like so: <b><font face="monospace">ip route add <a href="http://192.168.2.0/24" target="_blank">192.168.2.0/24</a> via 172.20.0.1</font></b><br>- Configured route on Host2 also: <b><font face="monospace">ip route add <a href="http://192.168.1.0/24" target="_blank">192.168.1.0/24</a> via 172.20.0.2</font></b><div>- All guests on Host1 (and Host1) can ping eth0 and vxlan0 on Host2, and vice versa, yay.<br>- Guests on Host1 <u>cannot</u> ping guests on Host2, I suspect because the the default NAT config of the libvirt network.<br><br>So, at this point I started to search for tutorials or more information/documentation, but I am a little overwhelmed by the sheer amount of information, as well as a lot of "stale" information on blogs etc.<br>I have learned that I can <b><font face="monospace">virsh net-edit default</font></b>, and then change it to an "open" network:<font face="monospace"><b> <forward mode='open'/></b></font></div><div>After doing this, the guests cannot reach outside their own network, nor reach the internet, so I assume that I would need to add some routes, or something else to get the network functioning like I want it. There is also <font face="monospace"><b><forward mode="route"/></b></font>, but I dont fully understand the scenarios where one would need an <b><font face="monospace">open</font></b> or a <b><font face="monospace">route</font></b> forward mode. I have also shied away from using openvswitch, and have opted for ifupdown2.<br>(I have taken most of my inspiration from this blog post: <a href="https://joejulian.name/post/how-to-configure-linux-vxlans-with-multiple-unicast-endpoints/" target="_blank">https://joejulian.name/post/how-to-configure-linux-vxlans-with-multiple-unicast-endpoints/</a> )<br><br>Some questions that I have for the mailing list, any help would be greatly appreciated:<br>- Is my target configuration of a KVM cluster uncommon? Do you see drawbacks of this setup, or does it go against "typical convention"?<br>- Would my scenario be better suited for an "<b><font face="monospace">open</font></b>" network or a "<b><font face="monospace">route</font></b>" network?<br>- What would be the approach to complete this setup?<br><br><br><br></div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
libvirt-users mailing list<br>
<a href="mailto:libvirt-users@redhat.com" target="_blank">libvirt-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libvirt-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/libvirt-users</a><br></blockquote></div><br></div>
</blockquote></div></div></div>