delNetwork issue
by Sandro Bonazzola
After having created the engine bridge, trying to remove it leads to:
# /usr/share/vdsm/delNetwork engine '' '' em1
INFO:root:Removing network engine with vlan=None, bonding=None,
nics=['em1'],options={}
Traceback (most recent call last):
File "/usr/share/vdsm/configNetwork.py", line 666, in <module>
main()
File "/usr/share/vdsm/configNetwork.py", line 641, in main
delNetwork(bridge, **kwargs)
File "/usr/share/vdsm/configNetwork.py", line 355, in delNetwork
_removeUnusedNics(network, vlan, bonding, nics, configWriter)
File "/usr/share/vdsm/configNetwork.py", line 259, in _removeUnusedNics
ifup(nic)
File "/usr/share/vdsm/netconf/ifcfg.py", line 739, in ifup
rc, out, err = _ifup(iface)
File "/usr/share/vdsm/netconf/ifcfg.py", line 728, in _ifup
out[-1] if out else '')
ConfigNetworkError: (29, '')
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 11 months
vdsm sync meeting Monday June 3rd 2013
by asegurap＠redhat.com
vdsm sync meeting June 3rd 2013
================================
There was a big problem with 3.2 branch that could potentially affect data
integrity. The major issue has been fixed. A patch form Eduardo is the one that
is directed to solving the issue. Reviews requested (Vinzenz and Federico) for
master and the 3.2 branch.
libvirtvm.py was merged into vm.py. Further refactoring is needed:
1.- Move the configuration related code to a separated class. VMConf.
2.- XML generation split out as well.
3.- Device classes should be moved out. Probably all of them in a separate
module.
4.- To be done after the current guest-agent work.
Vinzenz requests comments for:
http://www.mail-archive.com/vdsm-devel@lists.fedorahosted.org/msg02234.html
5 new verbs to minimize the traffic.
Yaniv's supervdsm as a separate service has been merged. vdsmd assumes
supervdsm to be running. It may introduce some regressions. Testing of this is
encouraged to help with stabilization.
Reviews requested for Zhou Zheng Ubuntu compatibility patches.
Unified persistance design discussed by Mark, Dan and Toni. Mark Wu did an
iproute2 configurator and delNetwork refactoring patches that need more review
from Toni and Dan.
Multiple gateways need some reviewing and discussion on arch list. Toni
proposes some irc discussion on #vdsm at freenode about the integration with
the current networking code.
Saggi working on SSL support for AMQP. Some patches waiting verification in
order for Dan to merge them.
oVirt 3.3 feature freeze was delayed one month to July 1st.
10 years, 11 months
About vdsmd init script
by zhshzhou＠linux.vnet.ibm.com
Hi,
I'm working on making VDSM run on Ubuntu. The current work item is to
start vdsmd service on Ubuntu. After discussion with Alon Bar-Lev on one
of my patches [1], I come up with an idea. I would like to listen to
other developers' suggestions before submit a new patch set.
Firstly the vdsmd.init.in should be split into pieces. I move the
initialization operations out of vdsmd.init.in, and put them in
respective scripts, for example,
init_00_shutdown_conflicting_srv.sh
init_04_gencerts.sh
init_08_libvirtd_sysv2upstart.sh
init_12_libvirtd_reconfigure.sh
init_16_start_needed_srv.sh
...
init_48_tune_system.sh
Then I can write a master script named init_common.sh. The
init_common.sh provides some environment variables and common functions,
it sources init_*_*.sh and execute all of them in alphabetic order. Then
in vdsmd.init.in, it calls init_common.sh before actually starts vdsm
daemon.
After move these things out of vdsmd.init.in, it slims to about 100
lines of code, and most of them are boilerplate. Then in Debian, we
should write vdsmd_debian.init.in using Debian's boilerplate, which fits
to Debian's SysV environment. Debians SysV environment is a bit
different from Red Hat family's. Red Hat provides /etc/init.d/functions
and Debian provides /lib/lsb/init-functions, the error logging function
and daemon function are different.
The VDSM SystemD unit calls vdmsd.init.in to start daemon, after we move
initialization to init_common.sh and its slaves, we can call
init_common.sh in vdsmd.service then start "/usr/bin/python
/usr/share/vdsm/vdsm" directly. SystemD knows how to daemonize and
respawn a process, so we can make use its native ability.
As regard to Upstart on Ubuntu, we can write an Upstart job that calls
init_common.sh, then use Upstart's native ability to daemonize and
respawn vdsm service process -- just a few lines of declaration.
In this way we relieve the headache of supporting a monolithic
vdsmd.init.in in different systems. After I split initialization
operations into init_*_*.sh scripts, I find they can be modularized.
There are almost no dependency in these init_*_*.sh scripts. Supporting
them in different systems is not hard, and we can add/remove
initialization scripts when porting VDSM to a new system.
We may has concerns on libvirt configuration. The libvirt configuration
code is complicated in vdsmd.init.in. After the refactoring, it would be
more complicated to improve it. I think the code is modular enough, I
did not change the code when I moved it. I also have an idea on how to
simplify it. If you take a look at configure_libvirt function in
vdsmd.init.in, you will find the code is mixed with the data. The
mechanism of configuration is mixed with what we'd like to configure.
For example,
set_if_default $lconf listen_addr \"0.0.0.0\"
set_if_default $lconf unix_sock_group \"kvm\"
set_if_default $lconf unix_sock_rw_perms \"0770\"
...
set_if_default $lconf keepalive_interval -1
I think we can split the configuration settings into a template file,
for example,
listen_addr="0.0.0.0"
unix_sock_group="kvm"
unix_sock_rw_perms="0770"
...
keepalive_interval=-1
Then write a function that reads this template and "merge" the settings
into libvirtd.conf. Then for different systems we can ship VDSM with
different template with various settings, and the code implementing
configuring remains the same. The template can also support dynamic
values, for example,
host_uuid<="$(uuidgen)"
Means it should eval the value before write it to libvirtd configure file.
[1] Split vdsm init script into pieces http://gerrit.ovirt.org/#/c/14826/
--
Thanks and best regards!
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou(a)linux.vnet.ibm.com
Telephone: 86-10-82454397
10 years, 11 months
