|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] regression with c/s 21223
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] regression with c/s 21223,
Jim Fehlig <=
|
|
|
|
|