[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH OSSTEST 03/12] Designate vif device model to e1000



> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Wednesday, February 11, 2015 10:50 PM
> To: Hu, Robert
> Cc: xen-devel@xxxxxxxxxxxxx; jfehlig@xxxxxxxx; wei.liu2@xxxxxxxxxx;
> ian.campbell@xxxxxxxxxx; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 03/12] Designate vif device model to e1000
> 
> Robert Ho writes ("[PATCH OSSTEST 03/12] Designate vif device model to
> e1000"):
> > 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.
> 
> I don't understand this, I'm afraid.  Can you please explain the bug
> in more detail in the commit message ?
I didn't look into details. Just observed the phenomenon if not designate it as
e1000, in L1, we will not have eth0 visible, therefore bridge on it won't work.
As long as we designate vif to e1000, it works.
But this is not a problem in our test environment in
which we don't use Debian as nested Dom0. So I guess this is Debian-specific
bug.
> 
> It is definitely not acceptable to change the default network card for
> all guests in prepareguest_part_xencfg.  It would be OK to provide a
> guest-specific runvar to specify the guest network card, and it might
> be OK to set that in the nested-specific test job creation.
OK, will use this approach to walk around and for the consideration of
future test scope scaling.
> 
> Thanks,
> Ian.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.