3 # Hyper-V specific events
6 match "system" "DEVFS";
7 match "subsystem" "CDEV";
9 match "cdev" "hv_kvp_dev";
10 action "/usr/sbin/hv_kvp_daemon";
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";
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";
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";
38 # Rules for non-transparent network VF.
40 # How network VF works with hn(4) on Hyper-V in non-transparent mode:
42 # - Each network VF has a cooresponding hn(4).
43 # - The network VF and the it's cooresponding hn(4) have the same hardware
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 cooresponding hn(4).
49 # This reception will happen, even if the the cooresponding hn(4) is
50 # down. The cooresponding 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
54 # o The cooresponding 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 cooresponding hn(4).
57 # o All of the reception goes through the cooresponding hn(4).
58 # o The cooresponding hn(4) fallbacks to the original physical link
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 # cooresponding hn(4) attached to it.
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 cooresponding hn(4) will be applied to the lagg(4) automatically.
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 cooresponding hn(4) could be completely ignored.
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 coresponding to hnX.
82 # b) Add hnX and VF to laggX.
83 # c) Whack all previous network configuration on hnX, including stopping
85 # d) Apply rc.conf ifconfig_hnX to laggX; i.e. including starting dhclient.
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.
94 # For transparent network VF, hyperv_vfattach does nothing and
95 # HYPERV_NIC_VF/VF_UP will not be triggered at all.
99 match "system" "HYPERV_NIC_VF";
100 match "type" "VF_UP";
101 action "/usr/libexec/hyperv/hyperv_vfup $subsystem";
105 match "system" "ETHERNET";
106 match "type" "IFATTACH";
107 action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";