mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-11-26 10:53:39 +01:00
c685956956
How network VF works with hn(4) on Hyper-V in non-transparent mode:
- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.
All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.
To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
80 lines
1.3 KiB
Bash
80 lines
1.3 KiB
Bash
#!/bin/sh
|
|
|
|
#
|
|
# If transparent VF is enabled, don't do anything.
|
|
#
|
|
|
|
sysctl -n hw.hn.vf_transparent > /dev/null 2>&1
|
|
if [ $? -ne 0 ]
|
|
then
|
|
# Old kernel; no transparent VF.
|
|
vf_transparent=0
|
|
else
|
|
vf_transparent=`sysctl -n hw.hn.vf_transparent`
|
|
fi
|
|
|
|
if [ $vf_transparent -ne 0 ]
|
|
then
|
|
# Transparent VF; done!
|
|
exit 0
|
|
fi
|
|
|
|
iface=$1
|
|
delay=$2
|
|
|
|
if [ $delay -gt 0 ]
|
|
then
|
|
#
|
|
# Delayed VF up.
|
|
#
|
|
sleep $delay
|
|
ifconfig $iface up
|
|
# Done!
|
|
exit $?
|
|
fi
|
|
|
|
#
|
|
# Check to see whether $iface is a VF or not.
|
|
# If $iface is a VF, bring it up now.
|
|
#
|
|
|
|
# for hyperv_vf_delay
|
|
. /etc/rc.conf
|
|
|
|
sysctl -n hw.hn.vflist > /dev/null 2>&1
|
|
if [ $? -ne 0 ]
|
|
then
|
|
# Old kernel; nothing could be done properly.
|
|
exit 0
|
|
fi
|
|
vf_list=`sysctl -n hw.hn.vflist`
|
|
|
|
for vf in $vf_list
|
|
do
|
|
if [ $vf = $iface ]
|
|
then
|
|
#
|
|
# Linger a little bit (at least 2 seconds) mainly to
|
|
# make sure that $iface is fully attached.
|
|
#
|
|
# NOTE:
|
|
# In Azure hyperv_vf_delay should be configured to a
|
|
# large value, e.g. 120 seconds, to avoid racing cloud
|
|
# agent goofs.
|
|
#
|
|
test $hyperv_vf_delay -ge 2 > /dev/null 2>&1
|
|
if [ $? -ne 0 ]
|
|
then
|
|
hyperv_vf_delay=2
|
|
fi
|
|
#
|
|
# NOTE:
|
|
# "(sleep ..; ifconfig .. up) > /dev/null 2>&1 &"
|
|
# does _not_ work.
|
|
#
|
|
daemon -f /usr/libexec/hyperv/hyperv_vfattach \
|
|
$iface $hyperv_vf_delay
|
|
break
|
|
fi
|
|
done
|