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