[libvirt] [RFC 5/5]: Rewrite findLuns function

Daniel P. Berrange berrange at redhat.com
Thu Jun 12 20:26:09 UTC 2008

On Thu, Jun 12, 2008 at 05:20:19PM +0200, Chris Lalancette wrote:
> Daniel P. Berrange wrote:
> >> # cat /sys/bus/scsi/devices/3:0:0:0/model
> >>
> >> and
> >>
> >> # cat /sys/bus/scsi/devices/3:0:0:0/type
> >>
> >> from both your netapp target and your sun target?  Here, at least, for our
> >> "control" LUN, model returns "Controller" while for the real LUNs model returns
> >> "VIRTUAL-DISK", so I'm hoping I can distinguish somehow based on what is in
> >> model, and if not that, based on type.
> > 
> > Can't you distinguish based on the fact that there'll be no /dev/sdNN
> > node for it ?
> Unfortunately, no.  The /sys/bus/scsi/devices/3:0:0:0/block:sda (or block/sda)
> link will only exist once udev has finished plugging the device in.  So we have
> to loop waiting for that to appear.  In the case of a control LUN, that will
> never appear, so we will wait 5 seconds (the current default) to see it appear,
> and then when it doesn't, we won't know how to distinguish the error case from
> the control LUN case.  I guess we could just not throw an error if we never see
> a block device, but we would still delay the libvirtd daemon (and the client)
> unnecessarily.

Hmmm, well, presumably udev knows to not create a /dev/sdNN node based on
some of the information in sysfs. So we just have to find out what udev's
decision is based on and copy it. Perhaps the 'driver' link in sysfs will
not exist ? Or point to something other than the 'sd' driver ?

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

More information about the libvir-list mailing list