This is a bug which has been reported to me by a few people now, and a KB has recently been published. This issue only occurs if the VM is:
- Running Windows Server 2012 (not Windows Server 2012 R2)
- Is configured to use SR-IOV and a VF was available for use by the VM when it powers on (or restarts)
Under these circumstances, even if the Integration Services are up to date in the guest operating system, Hyper-V Manager will incorrectly indicate that the Integration Services need an update. Functionally, there's no impact, the guest will run just fine - it's only the reporting side which is incorrect. If you are in doubt, you can always turn off SR-IOV temporarily and see that the correct status is reported.
For those of you interested why this occurs, it's a bug in the detection logic in the parent partition, and the way in which devices are enumerated/detected. For support of SR-IOV in guest operating systems, we have a driver which runs in the guest, VPCI.sys (Virtual PCI). This is enumerated on VMBus.
The detection logic is that when the guest starts, it communicates the Integration Services status through KVP by enumerating devices on VMBus, looking at their version numbers. When SR-IOV is in use, as per above, this will include VPCI.sys. However, VPCI.sys while enumerated on VMBus, is not installed or serviced as part of the Integration Services setup. Hence for a Windows Server 2012 guest, the version number of VPCI.sys will (correctly) be 6.2.xxxx, even when running on a Windows Server 2012 R2 parent where VPCI.sys is (correctly) 6.3.xxxx.
So you can probably see the issue - the parent side determination has faulty logic when SR-IOV is in use, incorrectly including VPCI.sys in the list which it validates against.
The KB can be found at http://support.microsoft.com/kb/2923885.