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

On 05/18/2016 07:37 AM, Vasiliy Tolstov wrote: 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. 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?