The domain controller is a always using the hardware clock. The W32time client is just making periodic corrections to it. (Note that "hardware" becomes a nebulous term when talking about a virtualized server.)
If it cannot sync with an external time server, the local clock will keep ticking, but will lose accuracy over time. The local hardware clock will drift by 1-10 seconds per day. That drift can be much higher in the case of a VM.
If the domain controller has lost its connection to an outside time source, it will stop advertising as a "reliable" time server, but it will still be a time server. The clients will still synchronize their clocks against the domain controller. This will continue to happen, even if the domain controller is unsynchronized (at least by default).
When your Internet connection comes back up, the domain controller will re-establish the connection to the outside NTP source, and it will correct itself. The Windows Time Service might make small periodic adjustments to the clock, or it may just "jump" the clock to the correct time, depending on how far out of sync it is. Note that if your clock is way out of sync (>48 hours), the Windows Time Service will not trust the outside time server (at least for Windows 2008 and later).
Once the domain controller clock is corrected, that will eventually propagate across your domain.
Keep in mind everything I described above is the default behaviour of the Windows Time Service. It can be configured via Group Policy, Command Line, or registry settings to behave quite differently.
http://blogs.msdn.com/b/w32time/archive/2007/09/04/keeping-the-domain-on-time.aspx
http://support.microsoft.com/kb/223184
