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

[Sheldon]

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>
>             <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?
ACK
>
>> 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