Differential D11635 Diff 31371 head/etc/devd/hyperv.conf

Changeset View

Standalone View

head/etc/devd/hyperv.conf

	Show All 27 Lines

	notify 11 {			notify 11 {
	match "system" "DEVFS";			match "system" "DEVFS";
	match "subsystem" "CDEV";			match "subsystem" "CDEV";
	match "type" "DESTROY";			match "type" "DESTROY";
	match "cdev" "hv_fsvss_dev";			match "cdev" "hv_fsvss_dev";
	action "pkill -x hv_vss_daemon";			action "pkill -x hv_vss_daemon";
	};			};

				#
				# Rules for non-transparent network VF.
				#
				# How network VF works with hn(4) on Hyper-V in non-transparent mode:
				#
				# - Each network VF has a cooresponding hn(4).
				# - The network VF and the it's cooresponding hn(4) have the same hardware
				# address.
				# - Once the network VF is up, e.g. ifconfig VF up:
				# o All of the transmission should go through the network VF.
				# o Most of the reception goes through the network VF.
				# o Small amount of reception may go through the cooresponding hn(4).
				# This reception will happen, even if the the cooresponding hn(4) is
				# down. The cooresponding hn(4) will change the reception interface
				# to the network VF, so that network layer and application layer will
				# be tricked into thinking that these packets were received by the
				# network VF.
				# o The cooresponding hn(4) pretends the physical link is down.
				# - Once the network VF is down or detached:
				# o All of the transmission should go through the cooresponding hn(4).
				# o All of the reception goes through the cooresponding hn(4).
				# o The cooresponding hn(4) fallbacks to the original physical link
				# detection logic.
				#
				# All these features are mainly used to help live migration, during which
				# the network VF will be detached, while the network communication to the
				# VM must not be cut off. In order to reach this level of live migration
				# transparency, we use failover mode lagg(4) with the network VF and the
				# cooresponding hn(4) attached to it.
				#
				# To ease user configuration for both network VF and non-network VF, the
				# lagg(4) will be created by the following rules, and the configuration
				# of the cooresponding hn(4) will be applied to the lagg(4) automatically.
				#
				# NOTE:
				# If live migration is not needed at all, the following rules could be
				# commented out, and the network VF interface could be used exclusively.
				# Most often the cooresponding hn(4) could be completely ignored.
				#
				#
				# Default workflow for the network VF bringup:
				# 1) ETHERNET/IFATTACH -> VF interface up (delayed by rc.conf hyperv_vf_delay
				# seconds). This operation will trigger HYPERV_NIC_VF/VF_UP.
				# 2) HYPERV_NIC_VF/VF_UP:
				# a) Create laggX coresponding to hnX.
				# b) Add hnX and VF to laggX.
				# c) Whack all previous network configuration on hnX, including stopping
				# dhclient.
				# d) Apply rc.conf ifconfig_hnX to laggX; i.e. including starting dhclient.
				#
				# NOTE:
				# HYPERV_NIC_VF/VF_UP action script could be customized per-interface by
				# adding /usr/libexec/hyperv/hyperv_vfup.hnX script.
				# /usr/libexec/hyperv/hyperv_vfup could be used as the template for the
				# customized per-interface script.
				#
				# NOTE:
				# For transparent network VF, hyperv_vfattach does nothing and
				# HYPERV_NIC_VF/VF_UP will not be triggered at all.
				#

				notify 10 {
				match "system" "HYPERV_NIC_VF";
				match "type" "VF_UP";
				action "/usr/libexec/hyperv/hyperv_vfup $subsystem";
				};

				notify 10 {
				match "system" "ETHERNET";
				match "type" "IFATTACH";
				action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
				};