VMkernel NIC what is it

At least with Xen my experience is that it's better to let the Dom0 handle the block devices. I haven't dealt with DRDB but with iSCSI it's better to have Dom0 be the iSCSI initiator and then just have the DomU use the resulting block device.

DRBD doesn't care about the filesystem that's running on the volumes so I would say this is probably best done in the DomO. This also gives you the ability to have DRBD backup Window DomUs.

You may also want to check out this question as it addresses some of your questions about running heartbeat on a vm.

In addition to the info on Why do people tell me not to use VLANs for security? here are some more specific & general bits to consider:

General Thoughts on Security
The most secure system is one where each subnet's hosts are connected to a switch having exactly the number of ports that will be used by connected devices. In such a configuration you can't plug random machines into your secure networks, since doing so would require unplugging something (and theoretically your monitoring system would notice that).

VLANs give you something similar in terms of security, breaking your switch up into smaller virtual switches (virtual LANs: VLANs) that are isolated from each other logically, and with proper configuration can appear to all the systems connected to them as if they were physically isolated.

General Thoughts on relatively-secure VLAN Setups
My practice for VLAN-capable switches is that all traffic must be assigned to a VLAN, with the following basic configuration:

Assign all unused ports to an "unused" VLAN.

All ports connecting to a specific computer should be assigned natively to the VLAN that computer should be in. These ports should be in one and only one VLAN (barring certain exceptions that we'll ignore for now).
On these ports all incoming packets (to the switch) are tagged with the native VLAN, and outgoing packets (from the switch) will (a) only originate from the assigned vlan, and (b) be untagged and appear just like any regular ethernet packet.

The only ports that should be "VLAN trunks" (ports in more than one VLAN) are trunk ports -- those carrying traffic between switches, or connecting to a firewall that will split up the VLAN traffic on its own.
On the trunk ports the vlan tags coming in to the switch will be respected, and vlan tags will not be stripped from packets leaving the switch.

The configuration described above means that the only place you can easily inject "VLAN hopping" traffic is on a trunk port (barring a software problem in your switches' VLAN implementation), and much like in the "most secure" scenario this means unplugging something important and causing a monitoring alarm. Similarly if you unplug a host to connect to the VLAN it lives in your monitoring system should notice that host's mysterious disappearance and alert you.
In both of these cases we're talking about an attack involving physical access to the servers -- While it may not be completely impossible to break VLAN isolation it is at a minimum very difficult in an environment set up as described above.

Specific Thoughts on VMWare and VLAN Security

VMWare Virtual Switches can be assigned to a VLAN -- When these virtual switches are connected to a physical interface on the VMWare host any traffic emitted will have the appropriate VLAN Tag.
Your VMWare machine's physical interface would need to be connected to a VLAN trunk port (carrying the VLANs that it will need access to).

In cases like this it is doubly important to pay attention to VMWare Best Practices for separating the Management NIC from the Virtual Machine NIC: Your Management NIC should be connected to a native port in an appropriate VLAN, and your Virtual Machine NIC should connect to a trunk that has the VLANs the virtual machines need (which ideally shouldn't carry the VMWare Management VLAN).

In practice enforcing that separation, in concert with the items I mentioned and what I'm sure others will come up with, will yield a reasonably secure environment.