[Users] cannot add new logical network to host

Mike Kolesnik mkolesni at redhat.com
Sun Nov 18 11:30:49 UTC 2012


On Thu, Nov 15, 2012 at 9:46 AM, Alan Johnson < alan at datdec.com > wrote: 

> > On Thu, Nov 15, 2012 at 5:34 AM, Roy Golan < rgolan at redhat.com >
> > wrote:
> 

> > > logic/flow aside, still the error is on engine side - validating
> > > the
> > > VdsNetworkInterface entity which seems to be missing an
> > > "interfaces"
> > > field or method thus throwing this runtime error.
> > 
> 
> > > I wonder if GWT serialized something unexpected here.
> > 
> 
> > > Alan - can you try invoking setup networks and see if any other
> > > action is terminated the same way?
> > 
> 
> > Yes, no matter what I do on Setup Host Networks, I get the same
> > error
> > when I click OK. Even if I make not changes at all, I get the same
> > when I click OK. I have to Cancel to get out of that screen.
> 
> I have just run though the same process on a different engine
> controlling a single node. Not changing anything on the Setup Host
> Networks screen, it closes successfully when I click OK. Trying to
> add the sandbox network to em1 gives the error "Error while
> executing action Setup Networks: Internal oVirt Engine Error". This
> shows up in engine.log: <<SNIP>>

> [A side note: is it wise to keep DEBUG on VDSM logs? If not, is there
> an easy way to shut it off? That is an awful lot of traffic and
> might explain why my nodes ran so slow when I was booting off of USB
> sticks.]
Since you're running off of a USB stick, which is probably limited in write bandwidth (USB interface + flash performance). 
It would probably be wise to turn it to a higher level, and only turn to DEBUG when you encounter a problem and can reproduce it (the downside is that you of course will not log error that you can't reproduce). 

The upside is that you'll save your stick's life (since flash chips have a limited number of writes per cell) and it will work faster (less blocking on log IO until the log is written). 

You can change the log levels in /etc/vdsm/logger.conf 

I would also suggest to turn down libvirt's log level for the same reasons. 
It seems to me (not sure about this one) that you can do that by adding this line to vdsm.conf: 
libvirt_log_filters = 2 :libvirt 2:remote 

> So, all that seems to be consistent with Igor's comments and I'll
> have to do some fancy dancing to get this setup once I get past the
> other bug. It would be nice if the GUI relayed the error " Setup
> attached more than one network to nic em1, some of which aren't
> vlans " from VDSM to the user, or some clearer translation, but it
> sounds like that is on the way based on Moti's comments about the
> nightly's, so I'll let it drop.
This bug was fixed, please see https://bugzilla.redhat.com/show_bug.cgi?id=851134 

In oVirt 3.2 (your DC has to be 3.2 as well) you can change the management network to be VLANd or non-VM network, and use the "Sync Network" feature (part of the setup networks process) to apply the change on the host. Then you'll be able to add a VLAN'd VM network on the same NIC. 

(Remember that if the management network is VLAN'd on the host then it has to be handled somehow so that the engine can communicate with it otherwise you'll lose connectivity to the host) 

> This engine and node were built last week and the process went much
> more smoothly than this first engine having problems. For the
> problematic engine, which I setup a couple of months ago, the
> CentOS6 packages had bunch of broken symlinks to jars that were on
> the system, but not where the symlinks expected them to be. That
> appears to have been fixed as of least week when I setup this second
> engine. To fix it on the first, I manually created symlinks where
> the broken ones were pointed rather than messing with any symlinks
> created by the packages.

> I wonder now if the packages on the bad engine (which are up to date)
> would have created different symlinks where I did and mine are
> blocking them from being created. I can rebuild the engine server if
> needed, but I would appreciate if some one can confirm that this
> error is consistent with a wrong version of a jar or some similar
> potential issue. Of course, I would also appreciate if there is a
> simpler solution. =)
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20121118/f25cb9f6/attachment-0001.html>


More information about the Users mailing list