diff options
Diffstat (limited to 'etc')
| -rw-r--r-- | etc/devd/hyperv.conf | 73 |
1 files changed, 73 insertions, 0 deletions
diff --git a/etc/devd/hyperv.conf b/etc/devd/hyperv.conf index 0abf284..10a4e2b 100644 --- a/etc/devd/hyperv.conf +++ b/etc/devd/hyperv.conf @@ -33,3 +33,76 @@ notify 11 { match "cdev" "hv_fsvss_dev"; action "pkill -x hv_vss_daemon"; }; + +# +# Rules for non-transparent network VF. +# +# 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. +# +# NOTE: +# If live migration is not needed at all, the following rules could be +# commented out, and the network VF interface could be used exclusively. +# Most often the cooresponding hn(4) could be completely ignored. +# +# +# Default workflow for the network VF bringup: +# 1) ETHERNET/IFATTACH -> VF interface up (delayed by rc.conf hyperv_vf_delay +# seconds). This operation will trigger HYPERV_NIC_VF/VF_UP. +# 2) HYPERV_NIC_VF/VF_UP: +# a) Create laggX coresponding to hnX. +# b) Add hnX and VF to laggX. +# c) Whack all previous network configuration on hnX, including stopping +# dhclient. +# d) Apply rc.conf ifconfig_hnX to laggX; i.e. including starting dhclient. +# +# NOTE: +# HYPERV_NIC_VF/VF_UP action script could be customized per-interface by +# adding /usr/libexec/hyperv/hyperv_vfup.hnX script. +# /usr/libexec/hyperv/hyperv_vfup could be used as the template for the +# customized per-interface script. +# +# NOTE: +# For transparent network VF, hyperv_vfattach does nothing and +# HYPERV_NIC_VF/VF_UP will not be triggered at all. +# + +notify 10 { + match "system" "HYPERV_NIC_VF"; + match "type" "VF_UP"; + action "/usr/libexec/hyperv/hyperv_vfup $subsystem"; +}; + +notify 10 { + match "system" "ETHERNET"; + match "type" "IFATTACH"; + action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0"; +}; |
