Just to be clear, the "parent partition" on the virtual host, regardless of whether you want to technically refer to it as a VM or not, would not have the same issues with timekeeping. If you do end up deciding to instead run AD on a normal VM that actually appears in Hyper-V manager, be careful about how you manage it: 1) don't ever take snapshots of that VM because they are worthless on a DC and reverting to one of them will cause lots of trouble, and 2) don't expect to have the same flexibility with reverting to a backup of that VM either (in the way that you could with another box like a web server). More on these issues here: http://support.microsoft.com/kb/888794. As has been previously mentioned, the best config is to run these roles (Hyper-V and DC) on separate boxes.
Hyper-V is not actually an add-on to Windows at all, it's actually a full hypervisor that takes over. The originally installed OS then becomes a root partition, subordinate to Hyper-V. So what was the base OS is technically a special VM now. To that extent the "special" VM can have hardware passed through (to give the appearance of being a normal OS still). This is the default configuration for almost all hardware after Hyper-V is enabled. When you create a virtual network for Hyper-V that's connected to a physical NIC however, Hyper-V takes ownership of the NIC and it is no longer passed through.
Your NIC configuration should be as follows:
Physical NIC should have the "Microsoft Virtual Network Switch" protocol enabled only (the one exception is when this isn't an actual physical NIC, like a software configured team, you'll usually have some sort of other protocol that can't be disabled).
In Hyper-V Manager's Virtual Network Manager; create a "Network", this will create a Virtual Network Switch in Hyper-V. Make it an External One, attached to the Physical NIC, also check the box to allow the Management OS access. This will create a new vNIC for the Base OS (remember it's actually a special VM, so you're adding a vNIC to this VM...). The new NIC may have to be configured for the IPs taken off the old Physical NIC (depends on the version of Hyper-V that you're using, if it will do this automatically or not).
Create VMs as desired, add vNICs to them and attach those vNICs to the appropriate virtual Network.
External Virtual Networks are attached to a Physical NIC. They allow VMs to connect to the Physical NICs. Internal Virtual Networks always create a new vNIC for the Management OS (there's no checkbox, it's just always done). This allows VMs to communicate with the base OS, but not with any Physical NICs. Private Virtual Networks are for VMs only and does not attach to the Management OS in any way.
You also mentioned problems keeping things running. If you are not using Server grade NIC chips (particularly Intel, Broadcom, QLogic, Emulex, NexGen, Mellanox, etc) expect problems. Similarly be sure you have the latest firmware. If you're running Via or Realtek chips you can save your time and dump the idea of reliable Level 1 Hypervisors (Hyper-V, ESXi, KVM, etc).
Best Answer
Your problem stems from a misunderstanding about default gateways. There is only one total, not one per NIC. Setting additional default gateways is for redundancy only.
You only have one default gateway, but you still need to set route for the other interfaces for non-default situations. If you don't do this, all traffic leaving your server will attempt to go out of the interface that has the default gateway on it, since that is the only gateway. It's pretty obvious why this won't work well for you.
So, in conclusion, if you define your default gateway for the 10.x.x.x interface, you need to add static routes for the 128.210.x.x interfaces which define the next hop for traffic leaving those NICs.