[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Xen 4.2 + XP x64 + PVGPL 2K3 x64 = BSOD (UNMOUNTABLE_BOOT_VOLUME)

Good day, Gordan,
On Mon, May 20, 2013 at 4:36 AM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
On Sun, 19 May 2013 10:42:06 -0700, Andrew Bobulsky <rulerof@xxxxxxxxx> wrote:
On May 19, 2013, at 10:18 AM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:

On 05/19/2013 06:14 PM, Andrew Bobulsky wrote:
On May 19, 2013, at 5:10 AM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:

The subject says it all, really.

I couldn't find any XP x64 specific drivers, but in all other cases
2K3 x64 drivers have worked for me on XP x64, so since the kernels
and driver models are the same, I am guessing this should work.

Thankfully I took a snapshot of the block device before installing the drivers.

Is there a better driver to use on XP x64?

The HVM disk performance is really quite attrocious. From dom0,
I get about 60MB/s on unbuffered reads with dd iflag=direct and
hdparm -t. From domU I get 5MB/s and qemu-dm hits 100% CPU usage.

Is there a way to make this work

Always!  I'm just not sure how :P

establish why it doesn't work?

If you could get the system booted from a completely different storage
device, and then try to get GPLPV working on a volume that's not the
boot volume, that might be a good place to start.  Personally, due to
either my brand of weirdness or perhaps tunnel vision, I would boot
from an iSCSI volume and then attempt to interact with the "local"
disks that way.

Funny you should mention iSCSI. My setup is an iSCSI volume exposed
to the domU "raw" as a physical IDE disk. But domU seems to be
alergic to it. If I leave the disk spec in the domU config as hda,
it BSODs with the mentioned error. If I change it in the config to
xvda, the domU starts to burn through 100% of CPU on all cores given
to it and never finishes booting.

Ooooo..... Well, you can try it if you like.  Download the Microsoft
iSCSI boot-capable initiator, install it, then download and install
sanbootconf from the iPXE web site.

Once you're done, reboot the domain and boot from the built-in iPXE.
Use Ctrl-B to enter the command line and run the following:

dhcp net0
sanboot iscsi:your.iscsi.server::::name.of.target

That's assuming you're not using chap auth or something, and that your
LUN is also LUN 0 on the target.  I can dig up the doc if you need
help on that, though :)

I have considered PXE booting the domU, but my concern is that I can
only do that via the emulated NIC. If qemu-dm tops out at 5MB/s on
emulated devices, this is presumably going to be just as bad.

Is there a way to PXE boot the domU via the physical PCI passthrough

If PCI passthrough works the way I think it works, then it just might.  Pre-OS interaction with PCI devices (a-la Primary/VGA Passthrough) requires mapping memory such that an option ROM can interact with the device in the same way it would when a system is first booted.  One of the great things about iPXE is that, while it interacts with the BIOS via that tradition option ROM interface, it scans the PCI bus itself, hunting for PNP devices in much the same way that a Windows or Linux kernel would when it starts up..... and since utilization of passed-through PCI devices works extremely well in those circumstances, I wouldn't be at all surprised if it does work.
The build of iPXE that is included with Xen is... a little on the old side.  All I really know about it is that my scripts don't work properly in it---I actually chainload a custom iPXE build from Xen's built-in copy, and then go from there.  If you happen to have iPXE deployed on your network, give that a try.  Otherwise, download and boot the pre-built iPXE ISO image[1] and use that instead, as it is designed to be highly compatible. Just pop it into you DomU config file and see what happens?  (I'm super curious!)
PS: As I think about it, the ability to have iPXE work directly on a passed-through NIC I speculate that, especially with the coming disruption to the entire logistics of VM networking represented by SR/MR-IOV would make this a very useful note for someone, I'm sure :)
Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.