Xen users - Jun 2008 - GPLV Drivers 0.9.8 Windows Server 2k3r2 on Debian Etch 64-bit + Backports + Xen 3.2.1 Crashed on first boot.

Hello all,

some hours ago I found out that there exist GPLed PV drivers for Windows 
HVM DomUs. Actually a highly appreciated and cool thing.

I got them from
http://wiki.xensource.com/xenwiki/XenWindowsGplPv

and installed them like told there after I read that no major show 
stoppers exist. (not knowing that there is a subpage
http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing)

The configuration used here is
GPLV Drivers 0.9.8 Windows Server 2k3r2 32-bit on Debian Etch 64-bit + 
Backports + Xen 3.2.1 .

Added the /GPLPV parameter to my Windows DomU and rebooted.
Just like it is written on the /Installing page, I am screwed now with a 
Windows DomU hanging on the Windows Screen with the running load indicator.
I did not experience a BSOD and the install of the tools went fine.

I did try to mount the Filesystem (which is stored in a LVM) with 
ntfs-3g tools, didn''t work, ntfs-3g said, I could not find the ntfs 
signature (so I suppose that this actually might be some qcow or 
something written in a lvm).

Would removing the /GPLPV option from boot.ini still work and result in 
a living system? Or do I need to reinstall the entire thing?

I tried to start the thing with and without type:ioemu parameters for 
harddisk and network in the xen config file. No difference.

If someone could
- help me in some way to reanimate my Windows DomU
- add a link to the /Installing Wiki-Page on the main GPLPV Page

that would be highly appreciated and very nice :)

If any more details are required it will be a pleasure to provide them.

Regards,
Joti

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Joti Mail wrote:
> Hello all,
>
> some hours ago I found out that there exist GPLed PV drivers for 
> Windows HVM DomUs. Actually a highly appreciated and cool thing.
>
> I got them from
> http://wiki.xensource.com/xenwiki/XenWindowsGplPv
>
> and installed them like told there after I read that no major show 
> stoppers exist. (not knowing that there is a subpage
> http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing)
>
> The configuration used here is
> GPLV Drivers 0.9.8 Windows Server 2k3r2 32-bit on Debian Etch 64-bit + 
> Backports + Xen 3.2.1 .
>
> Added the /GPLPV parameter to my Windows DomU and rebooted.
> Just like it is written on the /Installing page, I am screwed now with 
> a Windows DomU hanging on the Windows Screen with the running load 
> indicator.
> I did not experience a BSOD and the install of the tools went fine.
I have the same problem with my Win2K3 system.
>
> I did try to mount the Filesystem (which is stored in a LVM) with 
> ntfs-3g tools, didn''t work, ntfs-3g said, I could not find the
ntfs
> signature (so I suppose that this actually might be some qcow or 
> something written in a lvm).
>
> Would removing the /GPLPV option from boot.ini still work and result 
> in a living system? Or do I need to reinstall the entire thing?
Once I''ve installed the drivers I can''t boot with or without
/gplpv.  I
haven''t tried mounting the NTFS partition to see if it''s
readable.
>
> I tried to start the thing with and without type:ioemu parameters for 
> harddisk and network in the xen config file. No difference.
>
> If someone could
> - help me in some way to reanimate my Windows DomU
> - add a link to the /Installing Wiki-Page on the main GPLPV Page
>
> that would be highly appreciated and very nice :)
Whenever I install these drivers I take a copy of my domU and install 
the drivers in a running copy.  James has stated multiple times that 
they are not yet ready for production use and to use at your own risk.  
If you installed them in your only domU and now it won''t boot then I 
think you may need to reinstall it.  Have you tried booting in Safe Mode 
and manually un-installing the drivers?

As for the wiki, it''s a wiki so you can edit the page and add the link.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> and installed them like told there after I read that no major show
> stoppers exist. (not knowing that there is a subpage
> http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing)
There is a link to it... obviously not a prominent enough one.
> The configuration used here is
> GPLV Drivers 0.9.8 Windows Server 2k3r2 32-bit on Debian Etch 64-bit +
> Backports + Xen 3.2.1 .
> 
> Added the /GPLPV parameter to my Windows DomU and rebooted.
> Just like it is written on the /Installing page, I am screwed now with
a
> Windows DomU hanging on the Windows Screen with the running load
> indicator.
> I did not experience a BSOD and the install of the tools went fine.
How long did you let it run for? If it fails to start up a block device
or network device for some reason it could hang for a few minutes. It
should eventually either load or crash with a 0x7b bug check indicating
that it couldn''t find a boot device.
> I did try to mount the Filesystem (which is stored in a LVM) with
> ntfs-3g tools, didn''t work, ntfs-3g said, I could not find the
ntfs
> signature (so I suppose that this actually might be some qcow or
> something written in a lvm).
Try the following:

fdisk /dev/vgname/lvname
u (to change units)
p (to print the partition table)
q (to quit)

Find the partition you are interested in - probably the first one - and
note the starting sector (probably 63). Multiply that starting sector by
512 and use that number as the offset in a mount command, eg:

mount -oloop,offset=32256 /dev/vgname/lvname /mnt

or as the offset in a losetup command.

The problem is that your lv is a disk image not a filesystem image, so
you have to use the offset.

Alternatively, pass the disk image to another windows DomU and tinker
with it from there as the D: or E: drive.
> 
> Would removing the /GPLPV option from boot.ini still work and result
in
> a living system? Or do I need to reinstall the entire thing?
Depends on what went wrong. If you can, please persist with it as I''d
like to know what went wrong for you so I can reproduce it and fix it.
The install page does say to have two boot entries, one with gplpv and
the other without.

Thanks for the feedback, and sorry it didn''t go so smoothly.

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hello James,

thank you for your fast answer :)

I already was able to fix it by using the Windows Setup Repair function. 
I wrote the solution in another mail, which obviously went to someone 
else, I will redirect it to the list.

Concerning the time I waited for something to happen. I estimate about 
5-10 minutes. I skimmed through the xen-log files and found something 
that looked like it would have some disk-access problems but nothing too 
specific.

If you are interested I could add my fixing experience with this case to 
the Wiki if it would help.

Your suggestion with fdisk sounds good, I would not have had the idea 
with the offset - maybe that would fit in a "Possible install problems 
and how to (maybe) fix them" in the wiki.

The current status is that it is now up and running quite well, the felt 
speed increase is actually ~30-50% . I will conduct measurements with 
iperf and some disk speed programm later on as it too late now.


Thanks you and regards :)
Joti

James Harper schrieb:
>> and installed them like told there after I read that no major show
>> stoppers exist. (not knowing that there is a subpage
>> http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing)
> 
> There is a link to it... obviously not a prominent enough one.
> 
>> The configuration used here is
>> GPLV Drivers 0.9.8 Windows Server 2k3r2 32-bit on Debian Etch 64-bit +
>> Backports + Xen 3.2.1 .
>>
>> Added the /GPLPV parameter to my Windows DomU and rebooted.
>> Just like it is written on the /Installing page, I am screwed now with
> a
>> Windows DomU hanging on the Windows Screen with the running load
>> indicator.
>> I did not experience a BSOD and the install of the tools went fine.
> 
> How long did you let it run for? If it fails to start up a block device
> or network device for some reason it could hang for a few minutes. It
> should eventually either load or crash with a 0x7b bug check indicating
> that it couldn''t find a boot device.
> 
>> I did try to mount the Filesystem (which is stored in a LVM) with
>> ntfs-3g tools, didn''t work, ntfs-3g said, I could not find the
ntfs
>> signature (so I suppose that this actually might be some qcow or
>> something written in a lvm).
> 
> Try the following:
> 
> fdisk /dev/vgname/lvname
> u (to change units)
> p (to print the partition table)
> q (to quit)
> 
> Find the partition you are interested in - probably the first one - and
> note the starting sector (probably 63). Multiply that starting sector by
> 512 and use that number as the offset in a mount command, eg:
> 
> mount -oloop,offset=32256 /dev/vgname/lvname /mnt
> 
> or as the offset in a losetup command.
> 
> The problem is that your lv is a disk image not a filesystem image, so
> you have to use the offset.
> 
> Alternatively, pass the disk image to another windows DomU and tinker
> with it from there as the D: or E: drive.
> 
>> Would removing the /GPLPV option from boot.ini still work and result
> in
>> a living system? Or do I need to reinstall the entire thing?
> 
> Depends on what went wrong. If you can, please persist with it as
I''d
> like to know what went wrong for you so I can reproduce it and fix it.
> The install page does say to have two boot entries, one with gplpv and
> the other without.
> 
> Thanks for the feedback, and sorry it didn''t go so smoothly.
> 
> James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

i conducted some benchmarks using ''postmark'' on the 0.9.6
drivers under
windows xp and 2003 server, the results are posted here:

 http://recoverymonkey.net/wordpress/?p=65

-randall

On Tue, Jun 10, 2008 at 4:49 PM, Joti Mail <joti.mail@gmail.com> wrote:
> Hello James,
>
> thank you for your fast answer :)
>
> I already was able to fix it by using the Windows Setup Repair function. I
> wrote the solution in another mail, which obviously went to someone else, I
> will redirect it to the list.
>
> Concerning the time I waited for something to happen. I estimate about 5-10
> minutes. I skimmed through the xen-log files and found something that
looked
> like it would have some disk-access problems but nothing too specific.
>
> If you are interested I could add my fixing experience with this case to
> the Wiki if it would help.
>
> Your suggestion with fdisk sounds good, I would not have had the idea with
> the offset - maybe that would fit in a "Possible install problems and
how to
> (maybe) fix them" in the wiki.
>
> The current status is that it is now up and running quite well, the felt
> speed increase is actually ~30-50% . I will conduct measurements with iperf
> and some disk speed programm later on as it too late now.
>
>
> Thanks you and regards :)
> Joti
>
> James Harper schrieb:
>
>  and installed them like told there after I read that no major show
>>> stoppers exist. (not knowing that there is a subpage
>>> http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing)
>>>
>>
>> There is a link to it... obviously not a prominent enough one.
>>
>>  The configuration used here is
>>> GPLV Drivers 0.9.8 Windows Server 2k3r2 32-bit on Debian Etch
64-bit +
>>> Backports + Xen 3.2.1 .
>>>
>>> Added the /GPLPV parameter to my Windows DomU and rebooted.
>>> Just like it is written on the /Installing page, I am screwed now
with
>>>
>> a
>>
>>> Windows DomU hanging on the Windows Screen with the running load
>>> indicator.
>>> I did not experience a BSOD and the install of the tools went fine.
>>>
>>
>> How long did you let it run for? If it fails to start up a block device
>> or network device for some reason it could hang for a few minutes. It
>> should eventually either load or crash with a 0x7b bug check indicating
>> that it couldn''t find a boot device.
>>
>>  I did try to mount the Filesystem (which is stored in a LVM) with
>>> ntfs-3g tools, didn''t work, ntfs-3g said, I could not find
the ntfs
>>> signature (so I suppose that this actually might be some qcow or
>>> something written in a lvm).
>>>
>>
>> Try the following:
>>
>> fdisk /dev/vgname/lvname
>> u (to change units)
>> p (to print the partition table)
>> q (to quit)
>>
>> Find the partition you are interested in - probably the first one - and
>> note the starting sector (probably 63). Multiply that starting sector
by
>> 512 and use that number as the offset in a mount command, eg:
>>
>> mount -oloop,offset=32256 /dev/vgname/lvname /mnt
>>
>> or as the offset in a losetup command.
>>
>> The problem is that your lv is a disk image not a filesystem image, so
>> you have to use the offset.
>>
>> Alternatively, pass the disk image to another windows DomU and tinker
>> with it from there as the D: or E: drive.
>>
>>  Would removing the /GPLPV option from boot.ini still work and result
>>>
>> in
>>
>>> a living system? Or do I need to reinstall the entire thing?
>>>
>>
>> Depends on what went wrong. If you can, please persist with it as
I''d
>> like to know what went wrong for you so I can reproduce it and fix it.
>> The install page does say to have two boot entries, one with gplpv and
>> the other without.
>>
>> Thanks for the feedback, and sorry it didn''t go so smoothly.
>>
>> James
>>
>
>
> _______________________________________________
> 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

> Try the following:
> 
> fdisk /dev/vgname/lvname
> u (to change units)
> p (to print the partition table)
> q (to quit)
> 
> Find the partition you are interested in - probably the first one - and
> note the starting sector (probably 63). Multiply that starting sector by
> 512 and use that number as the offset in a mount command, eg:
> 
> mount -oloop,offset=32256 /dev/vgname/lvname /mnt
> 
> or as the offset in a losetup command.
Just to add my two cents,

its much easier using kpartx.

# kpartx -a /dev/vgname/lvname
# mount -o loop /dev/mapper/vgname--lvname--pnumber /mnt
# ...
# umount /mnt
# kpartx -d /dev/vgname/lvname
          ^^^ if this last step is skipped, bad things may happen ;)

cheers,

Stephan




_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Thu, Jun 12, 2008 at 10:08:44PM +0200, Stephan Seitz
wrote:
> > Try the following:
> > fdisk /dev/vgname/lvname
> > u (to change units)
> > p (to print the partition table)
> > q (to quit)
> > Find the partition you are interested in - probably the first one -
and
> > note the starting sector (probably 63). Multiply that starting sector
by
> > 512 and use that number as the offset in a mount command, eg:
> > mount -oloop,offset=32256 /dev/vgname/lvname /mnt
> > or as the offset in a losetup command.
> 
>  Just to add my two cents,
> 
>  its much easier using kpartx.
> 
>  # kpartx -a /dev/vgname/lvname
>  # mount -o loop /dev/mapper/vgname--lvname--pnumber /mnt
Don''t use loop. kpartx creates a usable block device.

-- 
lfr
0/0


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users