[Users] simple networking?
bob at doolittle.us.com
Mon Dec 2 17:57:11 UTC 2013
On 12/02/2013 11:39 AM, Ted Miller wrote:
> On 11/28/2013 3:54 AM, noc wrote:
>> On 27-11-2013 18:18, Ted Miller wrote:
>>> I am trying to set up a testing network using o-virt, but the
>>> networking is refusing to cooperate. I am testing for possible use
>>> in two different production setups.
>>> My previous experience has been with VMWare. I have always set up a
>>> single bridged network on each host. All my hosts, VMs, and non-VM
>>> computers were peers on the LAN. They could all talk to each other,
>>> and things worked very well. There was a firewall/gateway that
>>> provided access to the Internet, and hosts, VMs, and could all
>>> communicate with the Internet as needed.
>>> o-virt seems to be compartmentalizing things beyond all reason.
>> That is a way to use oVirt, but the following simple setup should
>> work and give you a way to check against your setup.
>> I have two setups, one at home and one at work. The one at home is a
>> setup of 2 hosts and one of those is a hacked up host/engine.
>> engine/host1: standard fedora19 kde install, static ip (192.168.1.11)
>> configured with my NAS (192.168.1.16) as dhcp/dns server and my
>> internet router (192.168.1.254) as gateway
>> Just make sure that NetworkManager is off and that your interfaces
>> are not NM managed, network on.
>> This was a allinone setup but I got a NAS with NFS so I turned my aio
>> setup into a engine/host system. It has problems with that but
>> nothing network related.
>> Host2: same as above but without the engine install, ip:192.168.1.22,
>> gw 192.168.1.254 DNS:192.168.1.16.
>> How does it all come together?
>> Well in your case, and mine if I were to start over, start with a
>> static network which is NOT managed by NetworkManager. Use either
>> Fedora or Centos which ever you more comfortable with and it also
>> depends on whether you want to test/use all the features in oVirt.
>> Currently, there are a few features not available in Centos because
>> the versions of libvirt/kvm/qemu/gluster are too old in Centos.
>> Install ovirt-engine on your first 'server', probably choose NFS as
>> your storage domain, either on your engine server or from somewhere
>> else on your network. Make sure its nfs-v3 and not v4!, local default
>> is v4!
>> Make sure that ip addresses on you network are resolvable, either
>> through /etc/hosts or through DNS! Engine-setup will complain if this
>> doesn't work, using localhost will not work either!
>> On the engine server there will be no bridge and nothing will change
>> the network config.
>> Next the first host.
>> Prepare the host in a similar way you did the engine server. You can
>> choose a minimal install of either Centos or Fedora or install a full
>> desktop but make sure that ips are static and NOT managed by
>> NetworkManager, hostname resolvable, ovirt repo available.
>> From the webui add your prepared host and if everything went OK
>> you'll see that on that host you will now have a bridge, ovirtmgmt,
>> which acts as the primary interface.
>> Create a VMs and choose ovirtmgmt as a network for its nics, can't
>> choose anything else. Either give the VMs a static address or use a
>> dhcp server but the VMs should be able to talk to each other, to the
>> host(s), the engine and to the internet.
>> Every host that you add after the first will also has its network
>> turned into a bridge, ovirtmgmt, and
>> communication/migration/display/etc will take place over this
>> network. One caveat, storage domain mapping is from the host to the
>> storage, the engine, if it is NOT the NFS server, doesn't have to
>> have access to the storage.
>> If you have servers with more that 1 nic then you can create
>> additional networks using the webui of oVirt and assign these to
>> clusters and to VMs.
>> If you need vlans to coexist with ovirtmgmt on the same physical nic,
>> I think that is possible but haven't tried it myself. In theory you
>> need to setup the network first outside of oVirt, including you vlan
>> structure and then install ovirt.
>> Some concepts:
>> oVirt engine: is just the manager, does 'nothing' related to running
>> VMs itself. You can turn it off and all hosts with their VMs will
>> keep running. You just can't start new ones, in short manage them.
>> oVirt host: is the real workhorse and is managed using oVirt-engine.
>> Runs VDSM which communicates with engine and starts/manages the VMs
>> on the host on behalf of engine.
>> oVirt node: is a special slimmed down Fedora distro that includes
>> VDSM and a small setup so that it can be used as a oVirt host
>> People tend to mix and match ovirt-host and ovirt-node which makes
>> for nice communication problems :-)
>> If you haven't done so, there is an irc channel, ovirt, on
>> irc.oftc.net with helpful people, if they are awake.
>> #irc jvandewege
> When I get another project out of the way (hopefully this week), I
> will be able to get back to my test setup and try again. Between your
> info, something I stumbled onto on a blog, and the info from Mike, I
> hope to have enough to make some progress when I take another stab at it.
I'd just like to reiterate what has been said before: What you describe
should work out-of-the-box.
All my VMs have always been able to talk to each other, my LAN, the
Internet, and both the engine and node, without issues.
What oVirt will wind up doing is to create a bridge ("ovirtmgmt") and
attach your node's NIC to it. The bridge will just pass through traffic
unaltered. Then as new VMs come up oVirt will create virtual NICs and
attach them to the bridge as well. Everybody should talk to everybody
just fine, on the same LAN.
If that's not happening for you, you may be trying to make this more
complex than necessary. Don't try to configure any extra networks,
bridges, etc. Just let oVirt do its thing. IMHO this is one of the most
significant benefits of oVirt over basic libvirt - it takes care of all
this complex, error-prone configuration for you .
 While getting libvirt to work, I wound up misconfiguring my
networking in such a way that it periodically flooded my switches with
Spanning Tree Protocol, which brought down the entire network. Ouch.
More information about the Users