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

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



On 05/18/2016 07:37 AM, Vasiliy Tolstov wrote:
2016-05-17 17:39 GMT+03:00 Laine Stump <laine 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.





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