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