Re: blktap, qdisk, xl cd-eject, and xencommons

[George Dunlap <george.dunlap@eu.citrix.com>]

On 04/30/2013 11:22 AM, Wei Liu wrote:
> On Tue, Apr 30, 2013 at 11:02:38AM +0100, George Dunlap wrote:
> [...]
>> The second is problems with xl cd-insert and eject, initially reported
>> by Fabio Fantoni, and then (accidentally) reproduced by me.  The problem
>> turns out to be libxl using blktap for cdroms.  Basically, AFAICT, the
>> whole cd-insert cd-eject thing completely doen't work if blktap is used
>> to provide it; and it's not a simple fix.
>>
>> To address these issue for 4.3, I would like to propose:
>>
>> 1. Have libxl default to qdev for everything, except for things that it
>> needs blktap for (like vhd, IIRC)
>>
>> 2. Simply remove the hard-coded modprobe from xencommons
>>
>
> Presumably you only mean "modprobe blktap ..."?
>
>> 3. Add code into libxl to do modprobe-ing as part of the "does this
>> system support blktap" check.
>>
>> But I think #3 can probably wait until 4.4.
>>
>
> I don't quite understand 2, 3 and the statment "#3 can probably wait
> until 4.4". If blktap is necessary for VHD, we can not simply remove the
> modprobe while not adding infrastructure in libxl to automatically load
> blktap.

Well we didn't have that before 4.3, and it didn't seem to be a major 
problem; I think people just knew to make sure blktap got modprobed 
themselves.  So I wouldn't personally consider this a blocker -- but I'm 
still open to other ideas.

In any case, it would certainly be *better* if we can have libxl attempt 
a modprobe, so if we can get it in before the release, I think that 
would be a good thing.

  -George