Nemeth, Tamas
2008-Sep-29 13:02 UTC
[Xen-users] LVM related bug in the GPL PV drivers for Windows?
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. Take a look at the attached bootini_with_pvdrivers and bootini_with_bios pictures! 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 (see the attached damage1 and damage2 pictures). 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@lists.xensource.com http://lists.xensource.com/xen-users
Nemeth, Tamas
2008-Sep-29 14:21 UTC
[Xen-users] LVM related bug in the GPL PV drivers for Windows?
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@lists.xensource.com http://lists.xensource.com/xen-users
Bruno Bertechini
2008-Sep-30 15:33 UTC
RES: [Xen-users] LVM related bug in the GPL PV drivers for Windows?
Hey there, Quick question regarding your setup. When you say : "...I can even swith between the paravirtualized and fully virtualized mode of windows,..." What exactly do you mean ? How can we use "paravirtualized" Windows ? Is this what the PV drivers do so ? Regards Bruno Bertechini -----Mensagem original----- De: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] Em nome de Nemeth, Tamas Enviada em: segunda-feira, 29 de setembro de 2008 11:21 Para: xen-users@lists.xensource.com Assunto: [Xen-users] LVM related bug in the GPL PV drivers for Windows? 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@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nemeth, Tamas
2008-Sep-30 17:48 UTC
Re: RES: [Xen-users] LVM related bug in the GPL PV drivers for Windows?
2008. 09. 30, kedd keltezéssel 12.33-kor Bruno Bertechini ezt írta:> Hey there, > > Quick question regarding your setup. When you say : > > "...I can even swith between the > paravirtualized and fully virtualized mode of windows,..." > > What exactly do you mean ?I mean, my c:\boot.ini specifies two entries, one with the "/gplpv" option, the other without it. I can boot with gplpv and then without it (a comlete reboot of domU is needed of course) and then again with gplpv and so on, and no filesystem damage occurs.> How can we use "paravirtualized" Windows ? Is this what the PV drivers do so ?Yes. When i boot Windows with the /gplpv option given, the paravirtualization drivers for Windows (http://wiki.xensource.com/xenwiki/XenWindowsGplPv) activate themselves and Windows becomes somewhat paravirtualizes, I assume. Regards, Tamas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users