1# 2# Hyper-V specific events 3 4notify 10 { 5 match "system" "DEVFS"; 6 match "subsystem" "CDEV"; 7 match "type" "CREATE"; 8 match "cdev" "hv_kvp_dev"; 9 action "/usr/sbin/hv_kvp_daemon"; 10}; 11 12notify 10 { 13 match "system" "DEVFS"; 14 match "subsystem" "CDEV"; 15 match "type" "DESTROY"; 16 match "cdev" "hv_kvp_dev"; 17 action "pkill -x hv_kvp_daemon"; 18}; 19 20notify 11 { 21 match "system" "DEVFS"; 22 match "subsystem" "CDEV"; 23 match "type" "CREATE"; 24 match "cdev" "hv_fsvss_dev"; 25 action "/usr/sbin/hv_vss_daemon"; 26}; 27 28notify 11 { 29 match "system" "DEVFS"; 30 match "subsystem" "CDEV"; 31 match "type" "DESTROY"; 32 match "cdev" "hv_fsvss_dev"; 33 action "pkill -x hv_vss_daemon"; 34}; 35 36# 37# Rules for non-transparent network VF. 38# 39# How network VF works with hn(4) on Hyper-V in non-transparent mode: 40# 41# - Each network VF has a corresponding hn(4). 42# - The network VF and the it's corresponding hn(4) have the same hardware 43# address. 44# - Once the network VF is up, e.g. ifconfig VF up: 45# o All of the transmission should go through the network VF. 46# o Most of the reception goes through the network VF. 47# o Small amount of reception may go through the corresponding hn(4). 48# This reception will happen, even if the corresponding hn(4) is 49# down. The corresponding hn(4) will change the reception interface 50# to the network VF, so that network layer and application layer will 51# be tricked into thinking that these packets were received by the 52# network VF. 53# o The corresponding hn(4) pretends the physical link is down. 54# - Once the network VF is down or detached: 55# o All of the transmission should go through the corresponding hn(4). 56# o All of the reception goes through the corresponding hn(4). 57# o The corresponding hn(4) fallbacks to the original physical link 58# detection logic. 59# 60# All these features are mainly used to help live migration, during which 61# the network VF will be detached, while the network communication to the 62# VM must not be cut off. In order to reach this level of live migration 63# transparency, we use failover mode lagg(4) with the network VF and the 64# corresponding hn(4) attached to it. 65# 66# To ease user configuration for both network VF and non-network VF, the 67# lagg(4) will be created by the following rules, and the configuration 68# of the corresponding hn(4) will be applied to the lagg(4) automatically. 69# 70# NOTE: 71# If live migration is not needed at all, the following rules could be 72# commented out, and the network VF interface could be used exclusively. 73# Most often the corresponding hn(4) could be completely ignored. 74# 75# 76# Default workflow for the network VF bringup: 77# 1) ETHERNET/IFATTACH -> VF interface up (delayed by rc.conf hyperv_vf_delay 78# seconds). This operation will trigger HYPERV_NIC_VF/VF_UP. 79# 2) HYPERV_NIC_VF/VF_UP: 80# a) Create laggX corresponding to hnX. 81# b) Add hnX and VF to laggX. 82# c) Whack all previous network configuration on hnX, including stopping 83# dhclient. 84# d) Apply rc.conf ifconfig_hnX to laggX; i.e. including starting dhclient. 85# 86# NOTE: 87# HYPERV_NIC_VF/VF_UP action script could be customized per-interface by 88# adding /usr/libexec/hyperv/hyperv_vfup.hnX script. 89# /usr/libexec/hyperv/hyperv_vfup could be used as the template for the 90# customized per-interface script. 91# 92# NOTE: 93# For transparent network VF, hyperv_vfattach does nothing and 94# HYPERV_NIC_VF/VF_UP will not be triggered at all. 95# 96 97notify 10 { 98 match "system" "HYPERV_NIC_VF"; 99 match "type" "VF_UP"; 100 action "/usr/libexec/hyperv/hyperv_vfup $subsystem"; 101}; 102 103notify 10 { 104 match "system" "ETHERNET"; 105 match "type" "IFATTACH"; 106 action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0"; 107}; 108