The patch passed all tests on Azure.

Pass the Azure test.

We have to modify the $PATH in init/FreeBSD/waagent, otherwise, we'll see an error in /var/log/waagent.log even though it does not hurt any functionality:

The fix looks ok to me. But I need to verify whether 2.2.13 works fine on Azure, and there is no error complained in the log.

Put all installed binary and configuration to $PREFIX (typically /usr/local) folder, then it is not necessary to set symlinks.

In D10566#220480, @bapt wrote:

So after looking at the content of the package:
it installs plenty of rc.d/*.orig files that should be removed

The cloudinit_override function is all wrong and should just be removed

The NetworkManager hook should just not be installed we do not support networkmanager on freebsd

The libudev rules has no sense on freebsd

/etc/dhcp/dhclient-exit-hooks.d/hook-dhclient is also not valid on freebsd

add the missing build for cloud-init-azure

In D8224#170848, @kib wrote:

Do you have specific questions to me, e.g. about the interfaces used ? I definitely would not read the hv daemon code, but sure can answer questions about the supposed use of the FreeBSD interfaces to VFS/VM.

It missed the man for hv_vss_daemon.

To understand the issue, I captured the DVD and OS Disk configuration on Hyper-V manager. From the picture, we can see there are 2 IDE Controllers and each IDE Controller has 2 locations. Changing the controller for DVD and OS Disk will cause DVD missing on VM side.

Then let me remind you one more of my arguments that I was told to never happen: your patch completely disables ATA disks, not looking where they are connected, so it can easily be real ATA disk, connected to passed through PCIe SATA controller, that as I understand is going to be supported in 2016 version.

I did not find a workable solution except to hack CAM until now. If you have suggestions, I'd like to try. The hv_ata_pci_disengage.c approach cannot determined which IDE controller CD/DVD locates in "probe" method.

In D7693#159708, @mav wrote:

From the beginning I was against hacking CAM to workaround Hyper-V problems. Here it returns again. What is exactly wrong with the hv_ata_pci_disengage.c approach?