9:52 p.m.
Thanks for the response, see responses inline.
You're welcome, responses inline.
On Wed, Jun 20, 2012 at 2:54 AM, Mike Kolesnik <mkolesni(a)redhat.com>
wrote:
> Hi,
>
> Please see reply in-line.
>
>> In ovirt-engine-3.1 I'm attempting to setup the base logical
>> networks
>> and have run into 2 major issues.
>
> Are you using cluster version 3.0 or 3.1?
>
I have been using 3.1 as it's the default. Is the different just the
API updates? All I could really find related to 3.0 vs 3.1
pertaining
to networking was this document
http://www.ovirt.org/wiki/Features/Design/Network/SetupNetworks
As Itamar replied, there are a few more network features in 3.1 other than
this one.
For a Host which is in a 3.1 cluster there should be a "Setup Networks"
button which indeed enables the functionality described in that wiki.
This is a new feature for 3.1 & up which allows to do several network
changes in an atomic manner, with an improved UI experience.
However, from the logs it looks like you're using the old commands to edit
the networks on the Host, so if you have this button (you should) then you
can try using it.
<SNIP>
>
> Unfortunately, oVirt supports setting only the default gateway of
> the Host
> (This is the field you saw in the management network).
>
> We could theoretically use initscripts' static routing files, but
> that is left for
> future development.
>
So for now, is it then easier to just run all public interfaces
through the same subnet/gateway? The main reason to run management
via 100Mbps and everything else 1Gbps was that our campus is out of
IPs so we're attempting to conserve on the usage of gigabit IPs.
Yes, currently the only gateway you can specify is the default one which
is set on the management network.
<SNIP>
I'll try to clarify the steps I took a little better, sorry if it was
unclear before.
1. Create logical network in Cluster that was NOT a "VM Network" (my
assumption of how to setup a storage network)
2. Edit NIC on host, set boot protocol to static and provide
IP/Netmask, and select the logical network created in #1, check "Save
network configuration"
3. After clicking OK the corresponding ifcfg file on the node was
modified, but the values for IP/Netmask were missing. Also the
values
did not appear in the network interface list, and were not shown when
going to that same interface and selecting "Add/Edit" again
That process did not involve a reboot of the host.
So in the host interface eth5 I set the following via web interface
Network: private1
Boot Protocol: Static
IP: 10.20.1.241
Subnet Mask: 255.0.0.0
Check: Save network configuration
After the save the node's ifcfg-eth5 is touched (based on modified
date in ls -la) but this is all it contains
DEVICE=eth5
ONBOOT=yes
BOOTPROTO=none
HWADDR=00:1b:21:1d:33:f1
NM_CONTROLLED=no
MTU=9000
As far as I can tell the only setting from ovirt-engine that made it
to that file was the MTU setting defined when creating the logical
network for the cluster.
Is my process somehow wrong or am I missing a step? I've done this
with the node being in both "Up" status and "Maintenance", same
results.
No, it looks like a bug that should be taken care of.
You can see from this log line that these options are not passed:
MainProcess|Thread-41320::INFO::2012-06-20
10:26:32,457::configNetwork::596::root::(addNetwork) Adding network private1 with
vlan=None, bonding=None, nics=['eth5'], bondingOptions=None, mtu=9000,
bridged=False, options={'STP': 'no'}
I tried this today but didn't reproduce for me, but as I can't look
at it in more detail ATM, but I'll try see whats going on tomorrow.
In the meanwhile, you might want to try a newer VDSM RPM from:
http://koji.fedoraproject.org/koji/packageinfo?packageID=12944
As a test I manually updated the IP/Netmask of ifcfg-eth4 and it
shows
up in the web interface with the correct information however any
changes via the web interface will remove the IPADDR and NETMASK
lines.
Yes, if you do changes manually then they will be discovered and
visible through the admin/REST clients. If you edit the network then
these changes get lost, but if not they will stay there.
However, for these basic options it's not necessary to do it like
this and they should work through the admin interface.
<SNIP>
Attached logs from the host and engine. Host - node_vdsm.txt and
Engine - engine.txt.
The only issues I see are two deprecation notices from vdsm.
Thanks
- Trey
Regards,
Mike