On 03/10/2014 10:48 PM, Aline Manera wrote:
On 03/10/2014 10:06 AM, Sheldon wrote:
On 03/08/2014 02:13 AM, Aline Manera wrote:
This patch is to fix #302.
It will not work in most of cases.
Yeap! And I agree with it.
I am suggesting you to also edit the current network default to an unused address - for the nested virtualization case.
For example:
# check default network exists
try:
net = networkLookupByName(default)
except:
# network default does not exist
<create network default using _get_available_address as you did in this patch set>
# now we need to make sure the network is active
if net.isActive() == 0:
try:
net.create()
except libvirt.libvirtError, e:
# default network exists but it is using an used address
# libvir: Network Driver error : internal error Network is already in use by interface eth0
try:
<update network address>
So how about delete this network and recreate it?
Try network update method for IP modify, it can not work.
This function is not supported by the connection driver
static int
virNetworkDefUpdateIP(virNetworkDefPtr def,
unsigned int command ATTRIBUTE_UNUSED,
int parentIndex ATTRIBUTE_UNUSED,
xmlXPathContextPtr ctxt ATTRIBUTE_UNUSED,
/* virNetworkUpdateFlags */
unsigned int fflags ATTRIBUTE_UNUSED)
{
virNetworkDefUpdateNoSupport(def, "ip");
return -1;
}
In [89]: net1.update(libvirt.VIR_NETWORK_UPDATE_COMMAND_MODIFY,
libvirt.VIR_NETWORK_SECTION_IP,
-1, "<ip address='192.168.44.1' />", flags=0)
libvirt: Network Driver error : this function is not supported by the connection driver: can't update 'ip' section of network 'test_abc'
---------------------------------------------------------------------------
libvirtError Traceback (most recent call last)
<ipython-input-89-3ba60f76cce4> in <module>()
1 net1.update(libvirt.VIR_NETWORK_UPDATE_COMMAND_MODIFY,
2 libvirt.VIR_NETWORK_SECTION_IP,
----> 3 -1, "<ip address='192.168.44.1' />", flags=0)
/usr/lib64/python2.7/site-packages/libvirt.pyc in update(self, command, section, parentIndex, xml, flags)
2363 running state, its persistent configuration, or both. """
2364 ret = libvirtmod.virNetworkUpdate(self._o, command, section, parentIndex, xml, flags)
-> 2365 if ret == -1: raise libvirtError ('virNetworkUpdate() failed', net=self)
2366 return ret
2367
libvirtError: this function is not supported by the connection driver: can't update 'ip' section of network 'test_abc'
<activate network>
except:
cherrypy.log.error("Fatal: Cannot activate default network "
"because of %s, exit kimchid" % e.message,
severity=logging.ERROR)
sys.exit(1)
What do you think about it?
I just touch the the related code to create default network.
I can works in default network missing case.
As the code says, if nested kvm does not has default network, then kimchi can choose a network address
and create a default network.
If it has, then it will do not create it.
I agree, we should not to send patch just for fix issue, we can consider more.
actually the Issue #302 is caused by the patch fixing the Issue #22 and Issue #56
we can list all cases, and let me fixed this time.
1. The default network and storage pool is usually created by libvirt with the default values.
So an kimchi user will face the same issue while running kimchi on nested virtualization.
I.e, there is not way to fix it. Just warning the user about the problem.
2. This issue is in some way related to https://github.com/kimchi-project/kimchi/issues/265
And why should not the user delete default network/storage pool?
This limitation should be impose to user when a network/storage pool is used by a template or vm.
Otherwise, the user can remove it.
Usually the default network/storage pool is created by libvirt.
But some time ago, we identified it did not happen in some distros.
And as the Kimchi default configuration for templates is pointing to those resources we decided to
create them manually on kimchi code to avoid problems while using the templates.
So my proposal is: let's revisit all the supported distros and check if libvirt creates default
network/storage pool by default, and if so remove this code from kimchi.
Then default network/storage pool will have the same behavior from other networks/storage pools.
On 03/07/2014 06:52 AM, shaohef@linux.vnet.ibm.com wrote:
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com>
let 'create' attr of networks model to create the default network
ShaoHe Feng (3):
move _default_network_check from top model to networks model
add a new function to get an available network address
Issue #302: let 'create' attr of networks model to create default
network
src/kimchi/model/model.py | 35 ---------------------------------
src/kimchi/model/networks.py | 46 +++++++++++++++++++++++++++++++++++++-------
src/kimchi/network.py | 7 +++++--
3 files changed, 44 insertions(+), 44 deletions(-)
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center