hyperv.conf revision 322129 
1# $FreeBSD: stable/10/etc/devd/hyperv.conf 322129 2017-08-07 02:15:13Z sephe $
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 cooresponding hn(4).
43# - The network VF and the it's cooresponding 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 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
53#      network VF.
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
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# cooresponding 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 cooresponding 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 cooresponding 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 coresponding 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