[libvirt] [PATCH] lxc: support <interface type='ethernet'>

[Laine Stump]

On 05/18/2016 07:37 AM, Vasiliy Tolstov wrote:
> 2016-05-17 17:39 GMT+03:00 Laine Stump <laine at laine.org>:
>> Rather than me spending time adding something to my patches that will just
>> be superceded by another patch immediately, I would rather just do it the
>> way everyone wants to begin with.

Since this has been sitting in my queue for a week and I'm no closer to 
making a decision on exactly what to do, I think I *will* just put in an 
UNSUPPORTED error and punt on it for now.

When somebody does add support for the script, I think we really should 
consider if we want to just mimic the qemu script (which only gets the 
tap device name as input, and is only called once just after creating 
the tap and setting its MAC address), or if we should do something more 
like the network hook script - it is called multiple times during a 
network's lifetime. Each time the script gets commandline arguments 
telling the name of the network, operation, and "subop", as well as the 
script's stdin getting XML with (hopefully) as much information as you 
could ever need:

      <hookData>
           <interface>
               [the XML of the interface being operated on]
           </interface>
           <network>
               [the XML of the network being operated on]
</network>
           <domain>
               [the XML of the domain being operated on]
</domain>
     </hookData>

We could do something similar (and it could be made to work for *all* 
types of interfaces (or at least type='ethernet') on both LXC and qemu). 
Something like this:

   1) in the interface xml, look for "<script 
hook='/Bob/Lob/Law/Law/Blog'/>" (note this doesn't use "path" as the 
existing simple qemu script does).

   2) when found pepper calls to it in strategic places during the 
interface setup, sending "$domainname $mac start $subopname" on the 
commandline, as well as:

      <hookData>
           <interface>
               [the XML of the interface being operated on]
           </interface>
           <domain>
               [the XML of the domain being operated on]
</domain>
     </hookData>

    to stdin, just in case there's something else in the config that is 
needed.

This one script could contain bits to create a tap device in lieu of 
libvirt creating it, starting up a VPN attaching the tap to some strange 
unknown network technology, adding rules to a firewall, or whatever - 
putting in calls at multiple points in the device setup would make it 
possible to intervene at just the right time.

Similarly, the same script would be called several times as the 
interface was being shutdown.

I'm just throwing that out for discussion. For right now, I'm going to 
flag script as UNSUPPORTED and move on.

>>
>> What type of things are usually done in the upscript? (and is a "down
>> script" needed?)
>>
>> (Speaking of that - I had asked in my discussion of re-doing the
>> peer-address patches if you could supply some example address/route configs
>> (for both host and guest side) of what you're doing with the peer address,
>> to see just how generalized those need to be. Any chance you can send me
>> that?)
>
> I think script needed to manually ping some sort of agent on node for
> example to add network info about newly created domain.
> May be this is expensive (because agent can listen libvirt events...)
> So may be i'm wrong. Please forget about script...
> I think that I was mistaken..
>
> For qemu i'm use this lines:
>
>        <ip address='HOST_IP' family='ipv4' peer='VM_IP' prefix='32'/>
> --  this address used bi bird routing daemon and via ospf propagated
> to other nodes.
>        <ip address='VM_GW' family='ipv4' prefix='32'/> -- this address
> used for gateway
>        <ip address='169.254.169.254' family='ipv4' prefix='32'/> --
> this address used by cloud-init (inside vm cloud-init talk to
> 169.254.169.254, so on host node i have some web server).

So ignoring the IPv6 addresses for now. You now have a tap device on the 
*host* that has the following IP addresses:

         $HOST_IP peer $VM_IP/32
         $VM_GW
         169.254.169.254

I'm guessing that in the guest you configure its ethernet to have

            $VM_IP peer $HOST_IP/24   (or some other prefix < 32)
           route add default $VM_GW   ($VM_GW on same subnet as $HOST_IP/24)

(I'm not sure what the guest does with 169.254.169.254)

What if you instead set the host to:

         $HOST_IP peer $VM_IP/32

and set the guest to:

         $VM_IP peer $HOST_IP/32
         route add default $HOST_IP

??

Anyway, it's important to know if you set the IP config on host and 
guest to exact mirrors of each other. It seems like the answer is "no", 
though, so i'm going to make a patch that allows what I was talking 
about last week:


        <interface type='ethernet'>
           <source>
             <ip address='HOST_IP' family='ipv4' peer='VM_IP' prefix='32'/>
             <ip address='VM_GW' family='ipv4' prefix='32'/>
           </source>
           <ip address='VM_IP' family='ipv4' peer='HOST_IP' prefix='24'/>
           <route family='ipv4' address='0.0.0.0' gateway='HOST_IP'/>
           ...
       </interface>

On qemu only the address info inside <source> would be used, since we 
don't have control over the guest's network config. On LXC, we can set both.

Does that sound usable?

>        <ip family="ipv6" address="HOST_IP6" peer='VP_IP6' prefix="64"/>
> -- this is ipv6 address
>        <ip family="ipv6" address="VM_GW6" prefix="64"/> -- this is ipv6 gateway
>
> Now i don't used route elements because i'm use bird routing daemon and ospf.
>
>
>