Here at BeefyApps we run our infrastructure atop the Xen Cloud Platform to maximize the utility of physical hardware. Working in a virtual environment has some excellent advantages for when things do not go quite as planned. Say for instance while messing with a boot loader, or kernel you ended up with a machine that was not in a bootable state. Because all the disks are on the hypervisor, we can just take the device and mount it on another virtual machine without needing a screwdriver.

xe vm-list
xe vm-disk-list vm=<dead-vm>
xe vdb-create vm-uuid=<good-vm> device=1 vdi-uuid=<disk-vdi-from-dead-vm> mode=RW type=Disk
# returned newly-minted-uuid
xe vbd-plug uuid=<newly-minted-uuid>

First we find our <dead-vm> and <good-vm> UUIDs and keep them handy. Look up the VDI (not the VDB) from the dead host; depending on your setup, you may have a lot of disks listed for the machine, in our case we only had the system default Local storage.

With the virtual device interface we create a new block device on a good host, and plug it in. Our example uses device 1, which will create and install /dev/xvdb in the virtual machine. Using device 0 gives you /dev/xvda which is probably already in use. Inside the good host we simply mapped the partitions and mounted them

kpartx -a /dev/xvdb
mount /dev/mapper/xvdb3 /mnt

So earlier I had one solution for connecting to a Xen domU instance that you had created, but I just came across another, more native way and I thought I should include it up here.

Once you have created your domU guest you can find it’s domain id by entering:

xe vm-list params=dom-id uuid=<uuid-of-vm> --minimal

That will give you the domain id and then you just plug that into:

/usr/lib/xen/bin/xenconsole <dom-id>

and you are off to the races.

I would like to credit the XVP installation guide for pointing that out to me:
http://www.xvpsource.org/?topic=build&page=appliancevm