There's a couple of potential pitfalls here. First of all, you mention dd for backups. While dd can be a wonderful tool, it's not an ideal backup tool, and if you're referring to using it to backup a live machine, it's a very poor choice. You're going to have some really badly inconsistent data and may not end up with a working image file.
Also, one note for the future. . . always setup your disk layout with LVM (and leave a few GB unallocated in the Volume Group), as it makes these kinds of situations about a hundred times easier to deal with. If the partitions were logical volumes under LVM, you could snapshot them, and then make use of the snapshot to give you a fairly consistent image.
Now, how critical is it that this box stay up? If you can take it down for a few minutes, there are P2V (Physical to Virtual) converters that you can use to make this transition a lot easier.
What kind of hardware configuration are you dealing with? If you have mirrored disks (RAID1) you might be able to break the mirror, pull a disk, and bring up the yanked disk in a second box. You could then clone that non-production copy.
Another important thing to consider, is what are you using for Xen? Is it RHEL and the Xen that's included? Or is it Citrix XenServer (now free)? This makes a difference as they both expect (by default) a slightly different disk format. Manually building an image for XenServer is a bit more complicated than building one for stock Xen.
It may sound a little unorthodox, but I've actually had better success in this type of situation by doing a simple base Linux install on a separate box, then running rsync from the production box to the new box, and then converting the non-production rsync'ed clone into the Xen domU (I've even had some luck just rsynch'ing from the production box to a Xen domU). Just run rsync (I recommend the options -HavSux) the old box to the new one while it's running, and once the rsync has completed, run rsync again. The first one will take a while to run, and will leave you with a lot of inconsistencies. The second one will run faster and because it only has to pull the changed stuff this time, put things in a more consistent state.
Whether that will be "good enough" for you, with regards to consistency, will depend on your requirements and what applications you're running. For example, if you've got an active database server on the production box, you'd definitely not want to leave rsync'ed file backups as "good enough". Instead, after the second rsync you'd take a database backup using the database tools, and import that on the clone. Or you'd wait to do that final synchronization until you have your xen domU up and running.
Good luck, and plan on a couple of dry runs and a couple more practice runs to get things working smoothly before you go for real.
mount: cannot read /etc/fstab: No such file or directory
That's a pretty clear sign that your initramfs is borked. Probably because your install is borked.
How did you get past partitioning in debian-installer? Last time I did it (ummm... yesterday) I had to export something that I could partition, so your disk being hda1 is rather weird. Mine looks like:
disk = ['phy:/dev/GLaDOS/xen-portaltest,xvda,w']
its on a logical volume, not a file, but that shouldn't matter. Giving it xvda1 or whatever didn't work; it wanted to partition that, which is fairly silly.
With xvda, I went ahead and partitioned that (into a xvda1 for /boot and an xvda2 for a LVM physical volume, but you could certainly just use that for root). The installer then completed normally, and it works after dealing with the bootloader not executable error documented on the Debian Wiki's Xen entry.
Best Answer
That`s what I initially did (convert p2v). This is a troublesome way to do it.
Better install a fresh, clean DomU with a PV kernel right from the start and then migrate the services to that box.
It is basically the same task as a pyhsical upgrade - but will get you a stable machine faster then the other way round.
I tried to emulate "/dev/sda" for years in my DomUs - just to find that after a certain sles-kernel-update the DomUs did not boot any longer (because sda was now hardcoded to use physical drivers). Now I use the standard-pv-driver (xenblk) with the standard device name (xvda) and everything is fine again.