Well, seeing as though I pulled my hair out solving this, let me answer my question and save someone else the trouble of hair pulling :)
Solution:
After playing around, plenty of Googling and repartitioning etc... I came to a setup that works like a charm.
There is probably a quicker way to do this but I am not going to over complicate this answer
I did a standard install with the partitions like this (I have a 500g hard drive) :
/boot 100mb
/swap 4gb
/ 40gb
The balance of the disk space is to be left as unpartitioned space.
Then, I created a primary partition called /dev/sda4 by following these steps:
~: fdisk /dev/sda
~: (fdisk shell) p4 (for primary partition # 4)
~: (fdisk shell) t (hit t and enter to edit the partition type)
~: (fdisk shell) 08e (Linux LVM)
Reboot the server so that the new partitions can take effect.
Now create logical volumes by:
~: pvcreate /dev/sda4
~: vgcreate xenvg -s 4M /dev/sda4 # (xenvg is the name of my virtual group, you can rename it)
~: lvcreate -L400G -n xenroot xenvg # (xenroot is going to be my drbd resource and root partition for my DomU)
~: lvcreate -L4G -n xenswap xenvg # (xenswap is my swap file for my DomU)
Now that you have the correct partitioning you can go ahead and install DRBD with the following config file directives (drbd.conf)
Just displaying the 2 important directives here...
{
device /dev/drbd0;
disk /dev/xenvg/xenroot;
}
Your XEN VM config file needs to look like this (again, just the important one)
{
disk = [ "drbd:xenvm,xvda,w","phy:xenvg/xenswap,xvdb,w" ]
}
I hope this helps someone out there...
The kernel has an in-memory image of the state it thinks the file system is in and it doesn't check the disk to see if it might have changed, because this can't happen, as only the local kernel is allowed to change the file system and it knows what it does and doesn't need to check. If you make changes on the second node, the on-disk structures will be different from what the kernel expects and data-loss is nearly guaranteed.
And since cluster-aware file systems add quite a lot of synchronization and checks to the picture to avoid all kind of problems, it's not as easy as letting the kernel read the file system before every operation to make e.g. ext4 cluster capable.
Best Answer
As long as you're certain that the future peer's disk is going to be the same size, or bigger than, the Primary you're about to force promote, then you shouldn't run into any troubles:
If the future disk ends up being smaller, even by a single sector, you will not be able to connect the two devices. DRBD exchanges disk properties when the peers first connect.