Xen users - Jul 2008 - Problem with GPLPV drivers 0.9.11.pre8

I have another domU that previously had the 0.8 drivers, so removed all 
traces of them using the same registry hacking method as before, the 
domU then rebooted cleanly without /gplpv flag.

I installed the 0.9.11-pre8 drivers, first I installed just the 
certificate (to try to cut down the number of dialogs) then I installed 
the Win2K3 drivers (I saw the installer messages about not loading 
devices due to them being unplugged or whatever the phrasing is).

Then used bootcfg.exe to set my /gplpv entry to be my default in 
boot.ini and rebooted

At this point the machine still had yellow bangs for the Xen devices, 
and the QEMU devices were present, the new hardware wizard then detected 
the Xen devices and went through loading drivers, and wanted a reboot.

At this stage both the QEMU and Xen drivers were visible at once!

my "xvda hard disk" showed as "C:" and "E:"
my "xvdc cd iso" showed as "D: and "F:"

At the next boot the machine crashed after the grey GUI screen (actually 
I wasn''t watching the console, instead of crashing, it may have been 
chkdisk repairing corrupt filesystem and then rebooting)

It booted again and I saw chkdsk referring to "E:" drive as clean,
the machine then gave a login dialog, I can logon to the console with 
the administrator username and password, but my session immediately logs 
off again (presumably due to lack of the expected C: drive, or perhaps 
the corruption was worse then chkdsk could fix properly?)

I''ll have a go at rescuing the machine with DISKPART.EXE from a 
bartpe/winpe CD, but I think this (double mounting of the same disk) was 
an potential issue James was worried about before releasing 0.9.11?



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

> Then used bootcfg.exe to set my /gplpv entry to be my default in
> boot.ini and rebooted
> 
> At this point the machine still had yellow bangs for the Xen devices,
> and the QEMU devices were present, the new hardware wizard then
detected
> the Xen devices and went through loading drivers, and wanted a reboot.
> 
> At this stage both the QEMU and Xen drivers were visible at once!
I guess you''ve found out by now that the disk is toasted...

This will happen if the drivers get installed when /GPLPV is booted. The
thing that concerns me is how easy this is to get wrong...

I think what you should have done was to reboot without /GPLPV, let the
drivers detect properly, then reboot with /GPLPV.

I have had problems with the installer under 2003x64... it just refuses
to install the drivers and I have to install them manually. Any advice
on that would be appreciated!

James

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

On 20/07/2008 04:31, James Harper wrote:
> I guess you''ve found out by now that the disk is toasted...
Not as throughly as I expected, I booted from a winPE .iso and used 
diskpart to re-assign C: to the disk, the domU still boots, get the 
dialogue warning that at least one service failed to start, but won''t 
allow administrator to log in properly, it just gets kicked straight 
out, tried a repair install and that wanted to go through re-validation 
of the windows licence, so I''ll restore the LV from a disk image
instead
(wish I''d started another snapshot, but having upgraded one machine I 
thought I knew the right order to do it in).
> This will happen if the drivers get installed when /GPLPV is booted. The
> thing that concerns me is how easy this is to get wrong...
It will need some considerable pointing out in release notes, have you 
considered automating the boot.ini changes?

Do you know what the other PV drivers do here to avoid this?
> I have had problems with the installer under 2003x64... it just refuses
> to install the drivers and I have to install them manually. Any advice
> on that would be appreciated!
Sorry, the most I''ve done with 64bit windows on Xen is to install the 
30(?) day eval copy, just to see if it would run.



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

> On 20/07/2008 04:31, James Harper wrote:
> 
> > I guess you''ve found out by now that the disk is toasted...
> 
> Not as throughly as I expected
Well that''s a first. Every time I have had this happen, my disk has
been
completely unrecoverable, at least using standard tools. As far as
everything I tried is concerned the filesystem was dead. I guess you
just got lucky (or I''ve been unlucky :)
> > This will happen if the drivers get installed when /GPLPV is booted.
The
> > thing that concerns me is how easy this is to get wrong...
> 
> It will need some considerable pointing out in release notes
Yes, although I''d prefer a system rather than procedure based solution
-
as you found, you thought the drivers had been installed successfully
and sobooted up with /GPLPV, only to find that they had not in fact been
installed successfully...

> have you considered automating the boot.ini changes?
Yes, but for the reasons above decided it wasn''t such a good idea at
this point so haven''t implemented them. Also, if you google with the
right keywords (can''t remember what they are) you''ll find a
few examples
of programs that do this but goofed and left the systems unbootable.

I think what I''ll need to do is have xenhide fall back to not gplpv if
it detects that the AddDevice callback is running after boot time. I
don''t know how easy it is to detect this though...
> Do you know what the other PV drivers do here to avoid this?
I did see some comments on other solutions stating that they required
modification to the Dom0 side of things to make it work. Something about
qemu only reporting the devices on the first call to the pci detection
(eg the BIOS).

James


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

On 20/07/2008 04:31, James Harper wrote:
> I guess you''ve found out by now that the disk is toasted...
I did have to restore the domU in the end (from a bzip''ed dd image of 
the LV), which caused windows to complain

	"Since windows was first activated on this computer, the hardware
	on the computer has changed significantly, due to these changes
	windows must be reactivated within 3 days"

This is on the same physical dom0, but now with Centos 5.2 + xen 3.2.0 
instead of Fedora8 + 3.1.3, the domU has been re-created (for a change 
of LVM mount point) does anyone know if a different domU UUID or NIC''s 
MAC address passes sufficiently different info into the domU that 
triggers windows into doing this?

If this reactivation changes everytime I upgrade Xen, or the PV drivers, 
or use an LVM snapshot or whatever is causing it, I''m worried Microsoft
will eventually disallow further re-activations ...



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

> 
> This is on the same physical dom0, but now with Centos 5.2 + xen 3.2.0
> instead of Fedora8 + 3.1.3, the domU has been re-created (for a change
> of LVM mount point) does anyone know if a different domU UUID or
NIC''s
> MAC address passes sufficiently different info into the domU that
> triggers windows into doing this?
> 
> If this reactivation changes everytime I upgrade Xen, or the PV
drivers,
> or use an LVM snapshot or whatever is causing it, I''m worried
Microsoft
> will eventually disallow further re-activations ...
> 
I haven''t seen that happen yet, at least on Server products, and even
if
it does I think you just have to pick up the phone instead.

Btw, I believe that if you slipstream SP3 onto your XP install disk, you
don''t need a product key until the product requires activation, 30 days
later (or is it 60?). I haven''t tried this, but it would sure make
testing heaps easier, especially if you are testing things that
routinely corrupt disks. LVM Snapshots relieve some of that but if you
are testing for performance they just get in the way.

I certainly don''t bother activating any of the products I''ve
been
testing with (from the MSDN library) - if they last 60 days without
being killed in some way then I don''t mind reinstalling anyway :)

James


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

On 20/07/2008 11:28, James Harper wrote:
> Yes, but for the reasons above decided it wasn''t such a good idea
at
> this point so haven''t implemented them. Also, if you google with
the
> right keywords (can''t remember what they are) you''ll find
a few examples
> of programs that do this but goofed and left the systems unbootable.
There is a risk of that, but booting from bartpe/winpe (even linux live
cd with fuse ntfs) could repair the boot.ini, easier than recovering
from a corrupted filesystem.




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

On 20/07/2008 11:48, James Harper wrote:
> I haven''t seen that happen yet, at least on Server products, and
even if
> it does I think you just have to pick up the phone instead.
This is Win2K3 SBS edition.
> Btw, I believe that if you slipstream SP3 onto your XP install disk, you
> don''t need a product key until the product requires activation, 30
days
> later (or is it 60?). I haven''t tried this, 
I believe you are correct, you can defer it until activation that way.



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

On Sun July 20 2008 6:32:13 am Andy Burns wrote:
> This is on the same physical dom0, but now with Centos 5.2 + xen 3.2.0
> instead of Fedora8 + 3.1.3, the domU has been re-created (for a change
> of LVM mount point) does anyone know if a different domU UUID or
NIC''s
> MAC address passes sufficiently different info into the domU that
> triggers windows into doing this?
Reactivating Windows has been a minor annoyance for me. I think only once has 
it asked me for a key. It just goes out to the internet and comes back and 
says ''OK''.

I hard code my UUID into my domain''s config, (not to mention the mac),
and
didn''t suffer any problems when Fedora upgraded from 3.1.0 to 3.1.3.
Changing
your disk= parm *should* have no effect (unless maybe if the geometry is 
different). In fact, back when the netfront drivers still worked (they stopped 
working for some reason after that same xen upgrade), I got no activation 
request from going back and forth between netfront and realtek (altho''
I never
changed the mac either).

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

On 20/07/2008 14:25, jim burns wrote:
> Reactivating Windows has been a minor annoyance for me. I think only once
has
> it asked me for a key. It just goes out to the internet and comes back and 
> says ''OK''.
I wasn''t sure how many times it would allow that before getting
"heavier"
> I hard code my UUID into my domain''s config, (not to mention the
mac), and
> didn''t suffer any problems when Fedora upgraded from 3.1.0 to
3.1.3. Changing
> your disk= parm *should* have no effect (unless maybe if the geometry is 
> different). In fact, back when the netfront drivers still worked (they
stopped
> working for some reason after that same xen upgrade), I got no activation 
> request from going back and forth between netfront and realtek
(altho'' I never
> changed the mac either).
I have found an older copy of my domU xml config file containing the 
original UUID and MAC, then restored the LVM disk from backup again, 
this time it was sufficient to prevent it from triggering Windows 
Product Activation.

According to Wikipedia[1] there are several inputs which can trigger 
re-activation

     * SCSI Adapter
     * IDE Adapter
     * Network Adapter (including the MAC Address)
     * Optical Drive (e.g. CD-ROM)
     * Hard Drive Device and Volume Serial Number
     * Display Adapter
     * RAM Amount Range (e.g. 0-512 MB)
     * Processor Type and Serial Number

I suppose switching between QEMU and GPLPV drivers can affect the first 
four, possibly the fifth too, I don''t know how many individual changes 
are required to trigger it, thankfully it seems so long as I preserve 
the MAC address I don''t exceed the limit.

[1] 
http://en.wikipedia.org/wiki/Windows_Product_Activation#Process_of_Windows_Product_Activation


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