I have this problem as well.  I'm installing using a slightly different situation -- I'm restoring a WinXP/Win2k3 backup that was made with fsarchiver -- but essentially I run across the same issue namely that boot fails when mbr tries to boot the first partition.  In my case I use install-mbr from the mbr package but have also tried to install the windows mbr from the boot cd without success.  Here are the steps I've taken and the partial fix I've discovered.

First, let me say that these steps worked perfectly in 9.10.  In fact, I can move the raw image from 9.10 to 10.04 and boot it without problem.  That was initially how I got these restores to work; I installed on a Karmic laptop and moved the raw image to Lucid.

Install Notes:

Install Procedure (for karmic or lucid):

1. boot system to image to rescuecd and backup xp or win2k3 using fsarchiver:
 fsarchiver savefs /some/remote/location/win.fsa /dev/sda1
2. on kvm host create restore disk:
 lvcreate -L10GB -n win vg
3. boot virt with rescuecd
 kvm -m 1024 -cdrom rescuecd.iso -hda /dev/vg/win -boot d
3. partition disk (entire disk, one partition, active):
 fdisk /dev/sda
 commands: o n p 1 [] [] t 7 a 1 w
4. restore archive:
 fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1
5. install mbr:
 install-mbr /dev/sda
6. halt virt and reboot to image:
 kvm -m 1024 -hda /dev/vg/win

At this point, the image will boot in 9.10. But following the same steps in lucid it will hang after the mbr boots the first partition.

I tried everything I could think of and all the different steps found on the web including repairing the mbr changing disk types and boot options to no avail.  What was odd for me is that the resulting image created on karmic would boot on lucid which indicated to me that once the install was completed successfully whatever kvm was doing didn't matter -- it was just the creation of the mbr or file system in the kvm boot that was at fault.

My next step at this point was to install hexedit and compare the two resulting images.  Specifically, the mbr at the beginning of the disk and the ntfs partition starting at sector 63.  On the net there is some talk about changing 0x7E1A to 'FF' -- which is supposed to indicate disk geometry of the ntfs partition.  There were three values that were different at this point in the ntfs file region -- 0x8E18, 0x7E1A, and 0x7E1C.  The first two did not seem to have any effect.  But changing 0x7E1C to the value of '3F' would result in the image booting properly.  Evidently this is the part of the NTFS file system that records the starting sector of the partition.  This change successfully booted all my test cases restores with a single partition.

OK, so at this point I backtracked and did just steps 1-4 on both Karmic and Lucid but instead of booting to a rescuecd in the virt I used kpartx to mount the raw file system:

1. make backup
 fsarchiver savefs win.fsa /dev/sda1
2. create disk
 lvcreate -L10GB -n win vg
3. partition
  fdisk /dev/vg/win
4. mount to loop, restore, detach
 kpartx -av /dev/vg/win
 fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1
 kpartx -dv /dev/loop0
5. install mbr
 install-mbr /dev/vg/win

At this point, unfortunately, these steps will not boot on either karmic or lucid -- the boot section of the ntfs partition does not seem to write correctly (0x8E18, 0x7E1A, and 0x7E1C are all '00').  However, if you change 0x7E1C to '3F', these resulting images will boot fine:

6. after hexedit, boot, success
 kvm -m 1024 -hda /dev/vg/win

Hope this helps track down this issue.  My feeling here is that this is not an issue with the mbr but rather the creation of the ntfs file system.  And it does seem that the disk geometry presented by the version of kvm in lucid is different enough from karmic to cause the ntfs file system incorrectly write sector 0x7E1C thus causing the resulting image to hang at boot.