[Kimchi-devel] [PATCH 0/3] Issue #302

Aline Manera alinefm at linux.vnet.ibm.com
Tue Mar 11 12:01:01 UTC 2014


On 03/11/2014 06:41 AM, Sheldon wrote:
> 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:
>>>>
>>>> It will not work in most of cases.
>>> This patch is to fix #302.
>>>
>>
>> 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?

It is Ok for me

>
> 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 at linux.vnet.ibm.com wrote:
>>>>> From: ShaoHe Feng <shaohef at 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 at linux.vnet.ibm.com>
> IBM Linux Technology Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140311/275c5e29/attachment.html>


More information about the Kimchi-devel mailing list