Re: [PATCH] nwfilter: Display detected IP address in domain XML

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/11/2012 11:31 AM, Daniel P. Berrange wrote:
On Mon, Jun 11, 2012 at 09:27:15AM -0600, Eric Blake wrote:
On 06/11/2012 07:54 AM, Stefan Berger wrote:
Display detected IP addresses in the domain XML using the
IP_LEASE variable name. This variable name now becomes
a reserved variable name that can be read only but not set
by the user.

The format of the value is:<ip address>,<lease timeout in seconds>

An example of a displayed XML may then be:

     <interface type='bridge'>
       <mac address='52:54:00:68:e3:90'/>
       <source bridge='virbr0'/>
       <target dev='vnet1'/>
       <model type='virtio'/>
       <filterref filter='clean-traffic'>
         <parameter name='CTRL_IP_LEARNING' value='dhcp'/>
         <parameter name='IP_LEASE' value='192.168.122.210,100'/>
I still think we're wrong in doing it with something that the user has
to reparse instead of being able to get at it via XPath queries.  Are we
any better off having:

<parameter name='IP_LEASE_ADDRESS' value='192.168.122.210'/>
<parameter name='IP_LEASE_TIMEOUT' value='100'/>

Or maybe feeding off of Laine's idea for keeping just one<parameter>,
but adding additional attributes (the redundant value= attribute would
remain, with redundant information, for back-compat), so that the XPath
query is still possible by using the new attributes:

<parameter name='IP_LEASE_ADDRESS' value='192.168.122.210,100'
address='192.168.122.210' timeout='100'/>
The<parameter>  element handling is supposed to be agnostic to the
type of data present, so I'd be loathe to add specific address/timeout
attributes to it.

I think I'd prefer the idea of separate IP_LEASE_ADDRESS/TIMEOUT
parameters, or even just not show the timeout data at all.

Displaying the IP address is useful in any way, either in the XML or through another virsh command. So we keep that. I thought displaying the timeout value could also be useful (in the future) if we were to use this during migration on the target system to re-instantiate the filters without having to kick the dhclient inside the VM to do another DHCP request. This would require libvirt's XML parser to know the reason why it is parsing the XML and in case of migration feed the parsed lease (IP address + timeout) into the nwfilter subsystem and that way migration at least could be seamless.

   Stefan

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]