[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |