[libvirt] [PATCH libvirt master v2] interface type: add udp socket support

Jonathan Toppins jtoppins at cumulusnetworks.com
Tue Sep 1 18:31:41 UTC 2015

On 09/01/2015 02:11 PM, Laine Stump wrote:
> On 08/31/2015 04:06 PM, Jonathan Toppins wrote:
>> On 08/31/2015 03:25 PM, Guido Günther wrote:
>>> Hi,
>>> On Sat, Aug 29, 2015 at 04:19:10PM -0400, Jonathan Toppins wrote:
>>>> Adds a new interface type using UDP sockets, this seems only applicable
>>>> to QEMU but have edited tree-wide to support the new interface type.
>>>> The interface type required the addition of a "localaddr" (local
>>>> address), this then maps into the following xml and qemu call.
>>>> <interface type='udp'>
>>> Sine we do have
>>>       <interface type='mcast'>
>>> already wouldn't it be better to have something like
>>>        <interface type='ucast' protocol='udp'>
>> This possibly could be better, my concern would be now tcp is
>> configured differently than udp, no? Or are you saying something like:
>>     <interface type='ucast' protocol='udp|tcp'>
> I think the case of a tcp connection is already handled by <interface
> type='client'> and <interface type='server'> together, so that doesn't
> seem likely to happen. I suppose it's possible someone would come up
> with an sctp-based transport in the future though. I'm undecided about
> this.

I am willing to work with Guido if you have some time to put into it. 
Otherwise the current implementation <interface type="foo"> models are 
pretty much 1:1 representations of what is in the C code and this looks 
pretty extensible to me. Have not seen any (or very few) copy-and-paste 
sections of code so it seems to be holding up currently. I will not try 
and speak for supporting the xml configuration long term, would 
appreciate some other perspectives. Lacking this I leave it up to the 
maintainer(s) to determine if this is worthy to go in. I see v1.2.19-rc2 
has been put out there so a possible compromise (policy even?) is for 
this to go into v1.2.20-devel so people can play around with it. I 
assume implementations can be changed/reverted between releases v1.2.19 
to v1.2.20. Completely understand the concern about supporting an 
interface for ever :)


More information about the libvir-list mailing list