Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs

[Ian Campbell <ian.campbell@citrix.com>]

On Mon, 2015-03-23 at 06:31 +0000, Hu, Robert wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:ian.campbell@citrix.com]
> > Sent: Friday, March 20, 2015 8:20 PM
> > To: Pang, LongtaoX
> > Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com; wei.liu2@citrix.com;
> > Hu, Robert
> > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport
> > APIs
> > 
> > On Fri, 2015-03-20 at 12:09 +0000, Pang, LongtaoX wrote:
> > > Add xen-devel in mail loop.
> > 
> > Here is what I wrong in reply to the private version without noticing
> > that it was private.
> > 
> > On Fri, 2015-03-20 at 11:59 +0000, Pang, LongtaoX wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:ian.campbell@citrix.com]
> > > > Sent: Friday, March 20, 2015 12:27 AM
> > > > To: Pang, LongtaoX
> > > > Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> > wei.liu2@citrix.com;
> > > > Hu, Robert
> > > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport
> > > > APIs
> > > >
> > > > On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote:
> > > > > From: "longtao.pang" <longtaox.pang@intel.com>
> > > > >
> > > > > 1. Designate vif model to 'e1000', otherwise, with default device
> > > > > model, the L1 eth0 interface disappear, hence xenbridge cannot work.
> > > > > Maybe this limitation can be removed later after some fix it. For now,
> > > > > we have to accomodate to it.
> > > >
> > > > You have done this unconditionally, which means it affects all guests.
> > > > You need to make this configurable by the caller, probably by plumbing it
> > > > through in $xopts (a hash of extra options).
> > > >
> > > > I see now you were told this last time around by Ian J, please don't just
> > resend
> > > > such things without change either fix them, make an argument for doing it
> > your
> > > > way or ask for clarification if you don't understand the requested change.
> > > >
> > >
> > > Thanks for your advice, I will try it. But, do you have any idea about below
> > issue that confused me?
> > > After L1 Debian hvm guest boot into XEN kernel, it failed to load 8139cp
> > driver(Realtek RTL-8139),
> > > that cause L1 guest's network unavailable, and I have to specify
> > 'model=e1000' to make L1's network available.
> > > The issue does not exist in RHEL6u5 OS(L0 and L1 are both RHEL6u5 OS).
> > 
> > Could just be a bug in Debian's kernel. Without more information it's
> > rather hard to say.
> > 
> Yes, it's hard to identify the root cause and we don't plan to dig out why here.
> How about we move this designation to ts-nested-setup, after first step the normal
> guest was created, we modify guest's configuration then?

Make it an option to the function which creates the configuration in the
first place. Quoting myself from earlier in this very thread:

> You have done this unconditionally, which means it affects all guests.
> You need to make this configurable by the caller, probably by plumbing
> it through in $xopts (a hash of extra options).

> The prerequisite here is to get configuration reloaded when guest 'reboot'. Do you
> know any approach to achieve this? seems 'restart' action on reboot event
> doesn’t read new configuration.

Look at hos ts-debian-hvm-install does it, it uses OnReboot=preserve
when calling more_prepareguest_hvm, then it waits for the guest to
reboot (which ends up preserved), then it manually destroys it, rewrites
the config and restarts the guest.

AFAICT this is exactly what you need.

> > Anyway, it's not clear why you need to edit this into the nestedhvm
> > configuration, instead of adding it when the configuration is created
> > via more_prepareguest_hvm. What harm is there in enabling this during
> > guest install?
> Seems no harm if when create a normal guest with 'nestedhvm' in its config.
> So
> 1. we have this option enabled in guest configure ever since.
> 2. We add in this primitive after first step (normal guest setup),
> in ts-nested-setup.
> 
> Which would you prefer?

If there is no harm in it then I don't see why you wouldn't just do #1.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel