Xen users - Mar 2011 - GPLPV drivers suspected to hinder live migration to different CPU type

Hi,

I''ve noticed that on a Xen cluster with three nodes (two E5620 CPUs and
one E5140 CPU) live migration works perfectly in between to two E5620 
nodes, but fails to and from the E5140. The error message is about a HVM 
context not being able to be set.
I strongly suspect the use 238 GPPVL drivers, but I cannot uninstall 
them at this point because someone else needs the server.

Could I be right and also, can this be helped? I fiddled with cupid 
masking so the CPUs looked the same to the hypervisor, but that did not 
help.

thx!


B.

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

> Hi,
> 
> I''ve noticed that on a Xen cluster with three nodes (two E5620
CPUs
and
> one E5140 CPU) live migration works perfectly in between to two E5620
> nodes, but fails to and from the E5140. The error message is about a
HVM
> context not being able to be set.
> I strongly suspect the use 238 GPPVL drivers, but I cannot uninstall
> them at this point because someone else needs the server.
> 
> Could I be right and also, can this be helped? I fiddled with cupid
> masking so the CPUs looked the same to the hypervisor, but that did
not
> help.
> 
I don''t see how GPLPV could impact that, but I can''t rule it
out. Can
you create the DomU on the E5140 and then migrate it to the others? That
might start it with the minimum feature set required (assuming the E5620
features are a superset of the E5140)

James

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

On Wednesday 30 March 2011 12:40:43 James Harper wrote:
> > Hi,
> > 
> > I''ve noticed that on a Xen cluster with three nodes (two
E5620 CPUs
> 
> and
> 
> > one E5140 CPU) live migration works perfectly in between to two E5620
> > nodes, but fails to and from the E5140. The error message is about a
> 
> HVM
> 
> > context not being able to be set.
> > I strongly suspect the use 238 GPPVL drivers, but I cannot uninstall
> > them at this point because someone else needs the server.
> > 
> > Could I be right and also, can this be helped? I fiddled with cupid
> > masking so the CPUs looked the same to the hypervisor, but that did
> 
> not
> 
> > help.
> 
> I don''t see how GPLPV could impact that, but I can''t rule
it out. Can
> you create the DomU on the E5140 and then migrate it to the others? That
> might start it with the minimum feature set required (assuming the E5620
> features are a superset of the E5140)
> 
> James


Hi James, 


thax for your quick reply!

I actually did that and in xentop you see the memory being built up to the 
actual value and then the DomU just disappears. If you do it the other way, 
the machine is migrated, but if you migrate back, the migration seems to take 
for ever and the original DomU has crashed with a blue screen.

Cheers,

B.




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

> 
> I actually did that and in xentop you see the memory being built up to
the
> actual value and then the DomU just disappears. If you do it the other
way,
> the machine is migrated, but if you migrate back, the migration seems
to take
> for ever and the original DomU has crashed with a blue screen.
> 
What is the BSoD code?

If you are running the debug version of the driver, there should be some
useful stuff in /var/log/xen/qemu-dm-<domu name>.log which could help me
debug the problem.

James

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

On Wednesday 30 March 2011 13:19:06 James Harper wrote:
> > I actually did that and in xentop you see the memory being built up to
> 
> the
> 
> > actual value and then the DomU just disappears. If you do it the other
> 
> way,
> 
> > the machine is migrated, but if you migrate back, the migration seems
> 
> to take
> 
> > for ever and the original DomU has crashed with a blue screen.
> 
> What is the BSoD code?
> 
> If you are running the debug version of the driver, there should be some
> useful stuff in /var/log/xen/qemu-dm-<domu name>.log which could help
me
> debug the problem.
> 
> James
James,

I''m not in this particular site currently, but tomorrow I am. I hope to
be
able to send you the necessary info by then.

thx!

B.


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

On Wednesday 30 March 2011 13:19:06 James Harper wrote:
> > I actually did that and in xentop you see the memory being built up to
> 
> the
> 
> > actual value and then the DomU just disappears. If you do it the other
> 
> way,
> 
> > the machine is migrated, but if you migrate back, the migration seems
> 
> to take
> 
> > for ever and the original DomU has crashed with a blue screen.
> 
> What is the BSoD code?
> 
> If you are running the debug version of the driver, there should be some
> useful stuff in /var/log/xen/qemu-dm-<domu name>.log which could help
me
> debug the problem.
> 
> James
By the way James, can I simply test the effect of non-GPLPV drivers by 
choowing the "other" option while booting (without /GPLPV)? Or should
I really
do a full uninstall?

thx,

B.


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

> 
> On Wednesday 30 March 2011 13:19:06 James Harper wrote:
> 
> > > I actually did that and in xentop you see the memory being built
up to
> 
> >
> 
> > the
> 
> >
> 
> > > actual value and then the DomU just disappears. If you do it the
other
> 
> >
> 
> > way,
> 
> >
> 
> > > the machine is migrated, but if you migrate back, the migration
seems
> 
> >
> 
> > to take
> 
> >
> 
> > > for ever and the original DomU has crashed with a blue screen.
> 
> >
> 
> > What is the BSoD code?
> 
> >
> 
> > If you are running the debug version of the driver, there should be
some
> 
> > useful stuff in /var/log/xen/qemu-dm-<domu name>.log which could
help me
> 
> > debug the problem.
> 
> >
> 
> > James
> 
> 
> 
> 
> By the way James, can I simply test the effect of non-GPLPV drivers by
> choowing the "other" option while booting (without /GPLPV)? Or
should
I really
> do a full uninstall?
> 
It depends on what the problem is. With /NOGPLPV (you don''t need /GPLPV
since version 0.10 - drivers are always active and you use /NOGPLPV to
disable) the xenvbd ''controller'' still appears but
doesn''t enumerate any
disks, and the xennet adapter appears but with a cable disconnected
state (to allow configuring with IP address etc before rebooting), so it
doesn''t disable the drivers completely.

James

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

On 03/31/11 01:16, James Harper wrote:
>>
>> On Wednesday 30 March 2011 13:19:06 James Harper wrote:
>>
>>>> I actually did that and in xentop you see the memory being
built
> up to
>>
>>>
>>
>>> the
>>
>>>
>>
>>>> actual value and then the DomU just disappears. If you do it
the
> other
>>
>>>
>>
>>> way,
>>
>>>
>>
>>>> the machine is migrated, but if you migrate back, the migration
> seems
>>
>>>
>>
>>> to take
>>
>>>
>>
>>>> for ever and the original DomU has crashed with a blue screen.
>>
>>>
>>
>>> What is the BSoD code?
>>
>>>
>>
>>> If you are running the debug version of the driver, there should be
> some
>>
>>> useful stuff in /var/log/xen/qemu-dm-<domu name>.log which
could
> help me
>>
>>> debug the problem.
>>
>>>
>>
>>> James
>>
>>
>>
>>
>> By the way James, can I simply test the effect of non-GPLPV drivers by
>> choowing the "other" option while booting (without /GPLPV)?
Or should
> I really
>> do a full uninstall?
>>
>
> It depends on what the problem is. With /NOGPLPV (you don''t need
/GPLPV
> since version 0.10 - drivers are always active and you use /NOGPLPV to
> disable) the xenvbd ''controller'' still appears but
doesn''t enumerate any
> disks, and the xennet adapter appears but with a cable disconnected
> state (to allow configuring with IP address etc before rebooting), so it
> doesn''t disable the drivers completely.
>
> James
I see, better uninstall them then.
Thx!!



B.

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

On Wednesday 30 March 2011 13:19:06 James Harper wrote:
> > I actually did that and in xentop you see the memory being built up to
> 
> the
> 
> > actual value and then the DomU just disappears. If you do it the other
> 
> way,
> 
> > the machine is migrated, but if you migrate back, the migration seems
> 
> to take
> 
> > for ever and the original DomU has crashed with a blue screen.
> 
> What is the BSoD code?
> 
> If you are running the debug version of the driver, there should be some
> useful stuff in /var/log/xen/qemu-dm-<domu name>.log which could help
me
> debug the problem.
> 
> James
I just uninstalled the GPLPV drivers on this one DomU and rebooting it after 
results into a BSoD with code 0x0000007B. This one is probably different from 
the ones we get when live migrating. I will restore the guest, but I''m
afraid
I can''t test without the GPLPV drivers.

B.



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

> 
> I just uninstalled the GPLPV drivers on this one DomU and rebooting it
after
> results into a BSoD with code 0x0000007B. This one is probably
different from
> the ones we get when live migrating. I will restore the guest, but
I''m
afraid
> I can''t test without the GPLPV drivers.
> 
After you uninstall GPLPV but before you reboot, look for any reference
to xenpci in the upper/lower filter registry entries under HKLM\System
and remove them.

James

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

----- "James Harper" <james.harper@bendigoit.com.au> schreef:
> > 
> > I just uninstalled the GPLPV drivers on this one DomU and rebooting
> it
> after
> > results into a BSoD with code 0x0000007B. This one is probably
> different from
> > the ones we get when live migrating. I will restore the guest, but
> I''m
> afraid
> > I can''t test without the GPLPV drivers.
> > 
> 
> After you uninstall GPLPV but before you reboot, look for any
> reference
> to xenpci in the upper/lower filter registry entries under
> HKLM\System
> and remove them.
> 
> James
Hi James,

remove the data of the entry or the complete entry? 
thx again,


B.

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

> Hi James,
> 
> remove the data of the entry or the complete entry?
> thx again,
> 
Either would be fine. If xenpci is the only thing in there then you can just
delete the whole value.

James

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

----- "James Harper" <james.harper@bendigoit.com.au> schreef:
> > Hi James,
> > 
> > remove the data of the entry or the complete entry?
> > thx again,
> > 
> 
> Either would be fine. If xenpci is the only thing in there then you
> can just delete the whole value.
> 
> James
Hi James,

I removed whatever occurrence and this had the same BSoD as a result.


B. 

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

> 
> Hi James,
> 
> - booted with NOGPLPV
> - ran the uninstall batch file
> - booted again with NOGPLPV on the Dom0 with the newer CPU
> - did a succesfull life migration to the Dom0 with the older CPU
> - did one back to the newer one and this resulted into a 0x0000007E BSoD on
> the windows machine on the target DomU
> 
> So either I did not perform the uninstall correctly, either this had
nothing
> to do with the GPLPV drivers.
> 
The only way to be really sure would be to test on a machine that had never had
GPLPV installed, but it looks like GPLPV is nothing to do with the problem.

On the machine with GPLPV removed, can you make sure there are no xen*.sys files
in C:\windows\system32\drivers? If these files are deleted then you can be sure
that GPLPV is not running.

James

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