On 05/18/2016 07:37 AM, Vasiliy Tolstov wrote:
2016-05-17 17:39 GMT+03:00 Laine Stump <laine@xxxxxxxxx>:
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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list