[libvirt] [PATCHv2 0/4] support the listenNetwork attribute in <graphics>

[Laine Stump]

On 07/22/2011 06:37 AM, Daniel P. Berrange wrote:
> On Wed, Jul 20, 2011 at 04:11:11AM -0400, Laine Stump wrote:
>> This patch series resolves the following bug:
>>
>>    https://bugzilla.redhat.com/show_bug.cgi?id=703851
>>
>> In short, it implements support for a new "listenNetwork" attribute in
>> the domain's<graphics>  element. When listenNetwork is specified,
>> libvirt will look for a network of that name (from the networks that
>> can be created within libvirt), and derive a listen address from the
>> physical interface used to connect that network to the outside
>> world. (More details are given in each commit message).
> I think my main thought on this is whether we are being forward
> thinking enough. The problems with the current 'listen' attribute
>
>    - You can only list one address
>    - The address is tied to a specific machine
>
> The 'listenNetwork' attribute would solve the second, but do
> nothing to solve the first.
>
> I think we ought to thus use a subelement
>
>     <graphics>
>       <listen type='network' network='foo'/>
>     </graphics>
>
>     <graphics>
>       <listen type='address' address='192.168.122.122'/>
>       <listen type='address' address='10.0.0.1'/>
>       <listen type='address' address='fec0:1:2::232'/>
>     </graphics>

Yes! I knew there had to be a better way to describe it, and this is it!

I just posted new patches that implement this (I also moved port, 
tlsPort, and autoport into the <listen> element, since they are also 
associated with listening, and we may want to use a different port for 
each address in the future).

The parser and formatter both fully support multiple <listen> elements, 
so when qemu is ready for that, we can easily plug them in.

Also, backward compatibility is setup similar to how I did it for the 
old single <forward dev='xxx'/> vs. the new <forward> <interface 
dev='xxx'> </forward> - When reading, both are accepted, but if both the 
old and the new form are present, they must match. On output, both are 
output to increase the chances of working "reasonably" with older clients.

> Yes, I know QEMU does not support listening on multiple addresses
> yet, but QEMU really needs to be fixed in that respect. This
> shouldn't stop us from structuring the XML nicely now.
>