[Libvirt-cim] [TEST] Issue with VirtualSystemManagementService/06_addresource.py

Deepti B Kalakeri deeptik at linux.vnet.ibm.com
Tue May 27 11:08:51 UTC 2008



Kaitlin Rupert wrote:
>>>
>>> Well, the providers should be creating <source network='something'>,
>>> so I need to check and make sure we're doing that.
>>>   
>> I checked whether the provider adds the <source network='something'> 
>> and it does for KVM.
>> I tried creating the KVM guest with two interface types:
>>
>> 1) Network Type :
>>
>>    It needs the following fields in the xml file:
>>    <interface type='network'>
>>      <mac address='11:22:33:aa:bb:cc'/>
>>      <source network='default-net'/>
>>    </interface>
>>
>>
>>    We are handling this in the provider code.
>>
>> 2) Bridge Type :
>>    It needs the following fields in the xml file:
>>
>>    <interface type='bridge'>
>>      <mac address='11:22:33:aa:bb:cc'/>
>>      <source bridge='testbridge'/>
>>    </interface>
>>    The provider code in the xmlgen.c file does not support the KVM
>>    guest to be created with the "bridge" type.
>
> Excellent find Deepti.  Thanks for looking into this - I think this is 
> an issue with the provider.
>
> You're correct - this is an issue in xmlgen.c  What is happening here 
> is the following:
>
>  1) Guest is created using virsh using network type bridge.
>  2) xen_net_to_xml() in xmlgen.c gets called instead of kvm_net_to_xml().
>  3) Since xend is fine with using a bridge interface without the 
> <source bridge=''/> tag defined, we don't specify one in the xmlgen 
> code.  QEMU borks when it attempts to create the guest with the new XML.
>
>>
>> 1) Also, I noticed that for creating the Xen guest we do not require 
>> the <source > field in the <interface > section for both Network and 
>> Bridge interface Types.
>>   But for the KVM guest its compulsory to have the <source > field in 
>> the <interface > section for both Network and Bridge interface Types.
>> 2) Any specific reason for not supporting the KVM guest to be created 
>> for the bridge type interface, and supporting Xen guest with only 
>> bridge type ?
>
> If you use the network interface type, the libvirt gets all the 
> necessary network information from the virtual network.  We don't have 
> to worry about whether the bridge exists, etc.
>
>> 3) Also, I did not understand the need for the script field in the 
>> interface section. We can create the Xen, KVM guests without this.
>
> This is a good point.  Actually, I thought there was some talk of 
> having both Xen and KVM guests use the network interface, but I might 
> be mistaken.
>
>>
>>
>>> KR> Dan - should the provider return an error if the guest doesn't use
>>> KR> a network type interface?
>>>
>>> Meaning an existing guest created outside the providers with a network
>>> type we don't support?  I dunno, I'll have to think on that one.
>>>
>
> Right - that's the issue here.  We have a KVM guest with a bridge 
> network type.  The AddResource() call fails because it generates the 
> new XML incorrectly.

Also, Should not the following piece of code in Virt_Device.c be setting 
appropriate value in the cim_type for the "network" type as well ?

static int net_set_type(CMPIInstance *instance,
                        struct net_device *dev)
{
        uint16_t cim_type;

        if (STREQC(dev->type, "ethernet") ||
            STREQC(dev->type, "bridge"))
                cim_type = CIM_NET_ETHERNET;
        else
                cim_type = CIM_NET_UNKNOWN;

        CMSetProperty(instance, "LinkTechnology",
                      (CMPIValue *)&cim_type, CMPI_uint16);

        return 1;
}


Thanks and Regards,
Deepti.




More information about the Libvirt-cim mailing list