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...
Best Answer
XSAVE and /dev/xvda1 have nothing to do with each other. That link is incorrect.
XSAVE is a CPU feature that Xen should not present to a kernel running in a VM. See https://partner-bugzilla.redhat.com/show_bug.cgi?id=524719
When configuring Xen you present a block device to the guest VM (domU, "AMI"). By convention (was a requirement in the past) they are prefixed with "xvd" (Xen virtual disk). In the host OS (dom0, "AWS system") this block device will be called something different. In the EC2 case it is a SCSI-like disc hence the "sd" prefix.