Dear Xen users!
In case you were struggling with recent version of th gplpv drivers,
I've possibly found an LVM related bug in it, and reported to James
Harper. Thats's the point:
I've tested the mentioned version of your driver on top of 32bit
xen-3.2.1 32bit xen-3.3.0 and 64bit xen xen-3.3.0 hypervisors, dom0 was
always an appropriate version of a 32bit PAE kernel, downloaded from
xen.org, together with the hypervisor. domU was either 32bit hungarian
windows xp of 32 bit english w2k3 enterprise. I experienced a lot of
BSODs in every scenario, but today I got an idea about the basic reason
behind these symptoms:
It seems to me that the BIOS and the built-in Windows', not
paravirtualized intel ATA(?) driver has a different view of the same
disk as your paravirtualized driver! For example, when I change the
contents of c:\boot.ini while Windows runs on your driver, these changes
remain invisible for the BIOS and the built-in driver. But
when I boot windows after it's bootloader displayed an earlier version
of the boot.ini, it will display the most recent version when running on
gplpv drivers. However, I have to choose to boot without the "/gplpv"
parameter to be able to edit c:\boot.ini.
After boot entry changes, windows wants to check the integrity of the
disk, and sometimes it finds severe filesystem errors. It seems to me that
the different modes see a different view of the disk and damage it very bad.
I've tried to change the type of the disk from 'hda' to 'xvda' in the
domU config file, but it didn't help the BIOS and the buil-in driver.
Changing it to 'sda' has broken the boot proces, even the boot loader
screen of Windows haven't appeared.
Beside this, the shutdown monitor of the mentioned version of the driver
couldn't be installed on the hungarian windows xp, because the XP said,
that shutdownmon.exe was not a win32 application or something like
that. It said the same thing about copyconfig.exe, however, the same
programs from version 0.9.10, were OK on XP too.
The disk is a multipath LVM volume with four FibreChannel paths to a
volume on a Sun Storagetek 6140 storage:
carrier3:~ # multipathd -k
multipathd> show topology
...
...
...
vw-storman2 (3600a0b80004807f80000091248da00ef) dm-0 SUN ,CSM200_R
[size=20G][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=6][active]
\_ 3:0:1:19 sdcc 69:0 [active][ready]
\_ 1:0:0:19 sdag 66:0 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:1:19 sdbi 67:192 [active][ghost]
\_ 3:0:0:19 sdbh 67:176 [active][ghost]
...
...
...
multipathd>
A Linux fdisk command in the dom0 has the following view of the volume:
carrier3:~ # fdisk -l /dev/mapper/vw-storman2
Disk /dev/mapper/vw-storman2: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x95f9a265
Device Boot Start End Blocks Id
System
/dev/mapper/vw-storman2p1 * 1 2609 20956761 7
HPFS/NTFS
carrier3:~ #
And finally, here is the config file of the domU:
name="vw-storman2"
uuid="7b77d277-e99a-e25b-3652-61e936f78abb"
memory=1024
vcpus=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
on_xend_start = "ignore"
on_xend_stop = "shutdown"
localtime=1
timer_mode=1
builder="hvm"
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="c"
disk=[ 'phy:/dev/mapper/vw-storman2,hda,w' ]
vif=[ 'mac=00:16:3e:0b:e9:5a,bridge=eth0', ]
keymap="hu"
stdvga=0
vnc=1
vncunused=0
vncdisplay=27
apic=1
acpi=1
pae=1
usb=1
usbdevice='tablet'
serial="pty"
Then, I've made an image out of the LVM volume by this command:
dd if=/dev/mapper/vw-storman2 of=/home/vw-storman2.bin bs=1048576
After doing so, I changed the domU config this way:
#disk=[ 'phy:/dev/mapper/vw-storman2,xvda,w' ]
disk=[ 'file:/home/vw-storman2.bin,xvda,w' ]
And it works now!!! The BOIS and the builtin windows driver has the same
view of the disk as the gplpv driver. I can even swith between the
paravirtualized and fully virtualized mode of windows, it doesn't even
want to check the integrity of the disk after the changes in either
direction, and virtually no filesystem damage occurs when I do so.
I've examined the disk image when to domU was running:
carrier3:~ # losetup -a
/dev/loop0: [0808]:49155 (/home/vw-storman2.bin)
carrier3:~ # fdisk -l /dev/loop0
Disk /dev/loop0: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x95f9a265
Device Boot Start End Blocks Id System
/dev/loop0p1 * 1 2609 20956761 7 HPFS/NTFS
carrier3:~ #
It seems to me the same as formerly.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home