Recently we noticed a problem that our Hyper-V guests did not seem to accept leases from the DHCP server. We are using the OpenStack network component to distribute DHCP addresses, which are leased for very short periods of time. Further investigation revealed that the problem is connected with the system time of the instance during boot.

When you have a Hyper-V server in time zone A and a guest in time zone B, the following happens: Windows always expects the local time in the BIOS. So, during boot, Hyper-V sets the local time in the BIOS of the guests. Then, the guest assumes that to be the local time in time zone B, so its clock is off by whatever amount these time zones differ. You will not notice that when you log in because the Hyper-V Time Synchronization Service will sync the correct time with the host long before you have a chance to log in.

However, when the DHCP client service starts, this synchronisation may or may not have taken place. In case it has not, we experienced problems with the leases. However, it is easy to fix. You simply run this command on the affected virtual machines:

sc.exe config nsi depend= nsiproxy/vmictimesync

Shows how Network Store Interface Service is dependend on Hyper-V Time Syncronization service now.

This causes the Network Store Interface Service to be dependent on the Hyper-V Time Synchronization Service while, of course, retaining its existing dependency on the NSI proxy driver. All other network services in turn depend on NSI. This will ensure the time is correct when the DHCP lease is acquired.

If you deploy a cloud you want to do this on your master image of course.