Re: RFC: Xen cdrom haldaemon

["Pat Campbell" <plc@novell.com>]

>>> On Wed, Sep 5, 2007 at 11:56 AM, in message <20070905175633.GI5503@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com> wrote: 
> On Wed, Sep 05, 2007 at 10:43:30AM - 0600, Pat Campbell wrote:
>> The basic flow of the patch is:
>> 
>>  Kernel:
>>      blkback driver: 
>>        if block device is a physical cdrom then
>>           Add media_present=1 into xenstore  backend/vbd 
>>              for this device
>>           Place a xenstore watch on media_present
>>        
>>        watch_handler
>>           if watch token is media_present
>>               read value
>>               if 0 then close block device fd
>>               if 1 then re- open block device fd
>> 
>>        Any access with fd closed results in EACCESS error
>> 
>>     qemu
>>        if block device is a cdrom
>>           Place a xenstore watch on media_present 
>>        watch_handler
>>           if watch token is media_present
>>               read value
>>               if 0 then close block device
>>               if 1 then re- open block device and set media_changed
>> 
>>        Any access with fd closed results in EACCESS error
>>  
>>     xend
>>        Starts XEN HalDaemon process
>>     
>>     XEN HalDaemon   
>>       Registers event callback for HALD events
>>        callback handler
>>           gets device major/minor numbers
>>           for each vbd in xenstore
>>              if matching major and minor
>>                 if add_event ( cdrom door closed with media )
>>                    xenstore write 1 to vbd/media_present
>>                 else         ( cddrom door open )
>>                    xenstore write 0 to vbd/media_present
>> 
>>       I am just learning python, could use a python guy to enhance and 
>>       generalize.
> 
> To be honest this sounds like rather overkill. Why on earth is blkback
> opening the device in the first place? blkback/blkfront don't have any
> kind of support for CDROM capabilities, so paravirt drivers for a disk
> device Xend marked as a cdrom don't make sense. If we stop blkback from
> processing any devices with the ':cdrom' annotation, then only QEMU will
> have the device open & the problem should go away if I'm understanding
> your description properly.
> 
> Dan.

Getting rid of the blkback open FD for QEMU guests would help but the
root problem still exists.  We still need to get all open file descriptors to the
CDROM device closed and reopened when the media is swapped out.

This is a contrived scenario but possible.  
    4 active FV guests, all configured to the same physical CDROM 
       ( These guests for whatever reason share the CDROM data )
    Currently there will be 8 open descriptors, 4 if blkback is changed
    Admin wants to swap out the CD with a new one that has additional info
      All open descriptors have to be closed before any guest will be 
      able to access the additional info because of the CD size not being 
      changed while any app has the CD device open. 

Pat