INACCESSIBLE_BOOT_DEVICE on Hyper-V 2012 R2 virtual machines
We escalated the problem up to Microsoft Premier Support and got a kernel debug specialist working on it; he discovered that something uninstalled all Hyper-V drivers from the guest VMs, thus rendering them completely unable to boot; he managed to get one of them to boot by manually injecting the drivers in the file system and Registry of the VM, and we were able to get back some critical data (it was a Certification Authority); however, the VM was now in a completely unsupported state, and thus we decided to rebuild it; we also rebuilt all the other VMs, which had no critical data on them.
As for what actually caused the driver uninstallation, the case is still opened, and the cause has not been found yet; the problem was latent in the template we used, because it sooner of later affected all the VMs which had been deployed using that template; we built another template, and this one didn't show the same issue, so we are running fine now... but we still don't know what caused the problem in the first place.
Update:
After a while, we FINALLY found what happened (I just forgot to update this answer before).
It looks like someone or something forcibly updated the Hyper-V Integration Services in the base template, which already had them, being based on the exact same O.S. release of the hosts; this caused a latent issue in the guest system where those drivers would be marked as duplicate and/or superseded, and thus in need of being removed; but this event would only trigger after a variable time interval, when Windows performs some periodical automated cleanup process. This eventually led to the complete uninstallation of all Hyper-V drivers on each VM instantiated from that template, rendering it completely unable to boot.
As for who or what performed this update (which can't be done by inserting the Integration Services setup disk and running its setup, because the installer correctly detects the drivers are already installed and exits), we still have no clue. Either someone who should have known better did it manually using PowerShell or DISM, or SCVMM was the culprit.