Hi Keir,
Unfortunately, my fix for losing device config [1] has caused duplicate
devices to appear when successfully starting a managed domain that uses
tapdisk :(.
# xm li -l domu1 | grep tap
(tap2
(uname tap:aio:/mnt1/images/domu1/disk0)
# xm start domu1
# xm li -l domu1 | grep tap
(tap2
(uname tap:aio:/mnt1/images/domu1/disk0)
(tap
(uname tap:aio:/mnt1/images/domu1disk0)
This particular host does not have blktap2 driver so blktap1 is used
instead. (NB: I do not see the problem when using blktap2, but we are
not yet supporting it.)
c/s 21223 attempted to make to_sxp() consult the stored config if no
running config was found for a given device class. tap2 vs tap provides
an interesting twist. If blktap2 dev controller is consulted (cls =tap2), no
running config is returned since the device is really being
handled by blktap1. The existing config is then consulted, in which
case a blktap2 (tap2) device is found. When blktap1 controller is
consulted (cls == tap), it returns running config found in xenstore
resulting in duplicate devices.
Frankly, I''m not sure how best to handle this case. The current
philosophy seems to be treat all ''tap:foo'' devices as blktap2
(see c/s
19874 - author cc''d), but fall back to blktap1 if blktap2 is not found
when domU is started. I''m certainly having problems differentiating
between the two in to_sxp().
Any suggestions on how to prevent the bug reported in [1] without this
new regression?
Thanks,
Jim
[1] http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01127.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 07/05/2010 04:36, "Jim Fehlig" <jfehlig@novell.com> wrote:> Frankly, I''m not sure how best to handle this case. The current > philosophy seems to be treat all ''tap:foo'' devices as blktap2 (see c/s > 19874 - author cc''d), but fall back to blktap1 if blktap2 is not found > when domU is started. I''m certainly having problems differentiating > between the two in to_sxp(). > > Any suggestions on how to prevent the bug reported in [1] without this > new regression?Way outside my comfort zone with xend I''m afraid. Do you think we need explicit differentiation between tap and tap2? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 07/05/2010 04:36, "Jim Fehlig" <jfehlig@novell.com> wrote: > > >> Frankly, I''m not sure how best to handle this case. The current >> philosophy seems to be treat all ''tap:foo'' devices as blktap2 (see c/s >> 19874 - author cc''d), but fall back to blktap1 if blktap2 is not found >> when domU is started. I''m certainly having problems differentiating >> between the two in to_sxp(). >> >> Any suggestions on how to prevent the bug reported in [1] without this >> new regression? >> > > Way outside my comfort zone with xend I''m afraid. Do you think we need > explicit differentiation between tap and tap2? >That is certainly an approach we are considering for our Xen 4.0-based packages - see attached patch. As mentioned previously, we are not yet supporting blktap2 so such a change seems appropriate in our case. I''m hoping some of the folks that integrated blktap2 in xend can provide suggestions. Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/05/2010 14:37, "Jim Fehlig" <jfehlig@novell.com> wrote:>> Way outside my comfort zone with xend I''m afraid. Do you think we need >> explicit differentiation between tap and tap2? >> > > That is certainly an approach we are considering for our Xen 4.0-based > packages - see attached patch. As mentioned previously, we are not yet > supporting blktap2 so such a change seems appropriate in our case.Does that simple patch really "just work"? I suppose it really just punts the tap2 issues, unless we also get rid of the tap2-falls-back-to-tap1 logic? -- Keir> I''m hoping some of the folks that integrated blktap2 in xend can provide > suggestions._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 07/05/2010 14:37, "Jim Fehlig" <jfehlig@novell.com> wrote: > > >>> Way outside my comfort zone with xend I''m afraid. Do you think we need >>> explicit differentiation between tap and tap2? >>> >>> >> That is certainly an approach we are considering for our Xen 4.0-based >> packages - see attached patch. As mentioned previously, we are not yet >> supporting blktap2 so such a change seems appropriate in our case. >> > > Does that simple patch really "just work"?It does for me, and I''ve done quite a bit of testing using ''tap:foo'' and ''tap2:foo'', with and without blktap2 module loaded.> I suppose it really just punts > the tap2 issues, unless we also get rid of the tap2-falls-back-to-tap1 > logic? >It reverts 2 hunks of c/s 19874, which implicitly converts the device to tap2 in a xend client app! If the same configuration is provided to xend through libvirt, this implicit conversion does not occur. I''d suspect this is true for direct users of XenAPI as well. But yes, I agree that if an explicit differentiation between tap and tap2 exists, then the tap2-fall-back-to-tap1 logic should be removed. It would be nice to get input from others, particularly authors of blktap2 integration patches :-). Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/05/2010 20:31, "Jim Fehlig" <jfehlig@novell.com> wrote:>> I suppose it really just punts >> the tap2 issues, unless we also get rid of the tap2-falls-back-to-tap1 >> logic? >> > > It reverts 2 hunks of c/s 19874, which implicitly converts the device to > tap2 in a xend client app! If the same configuration is provided to > xend through libvirt, this implicit conversion does not occur. I''d > suspect this is true for direct users of XenAPI as well. > > But yes, I agree that if an explicit differentiation between tap and > tap2 exists, then the tap2-fall-back-to-tap1 logic should be removed. > It would be nice to get input from others, particularly authors of > blktap2 integration patches :-).Well, in the absence of that I''m happy to take the patch, and I guess backport it for 4.0.1. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-May-16 10:54 UTC
[Xen-devel] Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?
Sorry, if i missed something in previous discussion (threads) .
But it sounds for me that answer is "NO" due to 3.4.3
doesn''t have all required CSs for IOAPIC (2.6.32.X) back ported.
Boris.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-16 11:09 UTC
[Xen-devel] Re: Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?
On 16/05/2010 11:54, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:> Sorry, if i missed something in previous discussion (threads) . > But it sounds for me that answer is "NO" due to 3.4.3 > doesn''t have all required CSs for IOAPIC (2.6.32.X) back ported.Yeah, I think it misses the boat. Maybe 3.4.4 if there is some developer interest in cherry-picking the patches, and sufficient testing effort. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Joanna Rutkowska
2010-May-16 12:11 UTC
Re: [Xen-devel] Re: Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?
On 05/16/2010 01:09 PM, Keir Fraser wrote:> On 16/05/2010 11:54, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote: > >> Sorry, if i missed something in previous discussion (threads) . >> But it sounds for me that answer is "NO" due to 3.4.3 >> doesn''t have all required CSs for IOAPIC (2.6.32.X) back ported. > > Yeah, I think it misses the boat. Maybe 3.4.4 if there is some developer > interest in cherry-picking the patches, and sufficient testing effort. >Hmmm... I''m just running 2.6.32.12 for my Dom0 (Based on Young''s RPMS with some minor modifications for Qubes) on Xen 3.4.3-rc3 and it seems to be working fine. j. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel