Re: [Libvirt-cim] Re: KVM on Pegasus Test Run Summary for Sep 10 2008 [ Current Source]
Kaitlin Rupert wrote:
> Yes, I agree with you that we should make use of the Providers
> supplied functions, like DefineSystem() as much possible.
> I had tried supplying the networkpoolname/bridgename in the VirtXML,
> and it works fine till then to get an XML which contains invalid
> networkpool/bridgename.
> But when we call cim_define() we dont make use of the XML generated
> till then.
> In cim_define() we make use of VSSD, various RASD and I did not find
> a relevant field in NetRASD which could be used for supplying the
> invalid name info.
> I tried using ElementName, but was not much help.
> Can you suggest how or which of the VSSD, RASD fields could be used
> to supply the networkpool/birdge name.
>
The get_nasd_class() function takes a network name. So, the __init__
for the VirtCIM class should take a network name and pass this to the
get_nasd_class() function.
When I replied yesterday, I thought __init__ was already taking the
network name as an argument. Sorry for the confusion there.
Ya right, the get_nasd_class() takes the net_name.
1) The only place where the networkname/bridgename can be passed is
through the PoolID, is this correct ?
2) Like the way we supply networkpool info as part of PoolID, how do we
supply the same for Bridge type ?
According to me PoolID='Bridge/virbr0' should work, right ?
Also, I believe the PoolID='Bridge/virbr0' information translates to
the following in the XML ?
<interface type='bridge'>
<mac address='00:11:22:33:44:aa'/>
<source bridge='virbr0'/>
</interface>
I tried using the PoolID='Bridge/bridgewrong' to test the
05_RAPF_err.py tc and it worked for me on KVM.
Using PoolID='Bridge/bridgewrong' the XML from the debug statement
contained the interface type as network as below:
xmlgen.c(640): New UUID
Virt_VirtualSystemManagementService.c(990): System XML:
<domain type='kvm'>
<uuid>5ed4620c-3d04-43b4-995e-36e6da93cf63</uuid>
<name>RAPF_domain</name>
<on_poweroff>destroy</on_poweroff>
<on_crash>destroy</on_crash>
<os>
<type>hvm</type>
<boot dev='hd'/>
</os>
<currentMemory>131072</currentMemory>
<memory>131072</memory>
<vcpu>1</vcpu>
<devices>
*<interface type='network'>
<mac address='00:11:22:33:44:aa'/>
<source network='bridgewrong'/>
</interface>
*<disk type='file' device='disk'>
<source file='/tmp/default-kvm-dimage'/>
<target dev='hda'/>
</disk>
<graphics type='vnc' port='-1'/>
</devices>
</domain>
But for Xen/XenFV , using PoolID='Bridge/bridgewrong' and with the
above mapping of bridgeinfo supplied as part of the PoolID to network in
the XML fails with the following error:
*misc_util.c(72): Connecting to libvirt with uri `xen'
libvir: QEMU error : no network with matching name
Virt_VirtualSystemManagementService.c(771): Failed to define domain
from XML*
The above error thrown by the provider is valid for Xen/XenFV, since
even virsh fails to define a VS when an non-existing networkpool info is
used.
[Note: it allowed the VS to be defined with non-existing bridge]
How and why is it important to map from Bridge to network from the
providers perspective ?
Can't we just retain the information that is supplied through NetRASD
as it is ?
Am, I missing something ? Can you help me proceed with the
implementation of non-existing networkpoolname/bridgename scenario in
05_RAPF_err.py .
Thanks and Regards,
Deepti.