[libvirt] [PATCH 0/5]: Rework iSCSI lun handling
These patches are now better tested, so I'm sending them for review again. To recap, these patches: 1) Do minor cleanup of the existing code 2) Fix a bug where we aren't properly finding the LUNs on pre 2.6.24 kernels 3) Fix a bug seen in oVirt where we race between libvirtd scanning the sysfs path and udev actually making the sysfs path in the first place 4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future. Changes since last time include: 1) Fixing the 0th LUN problem as pointed out by Stefan de Konink. We now use a sysfs file to determine whether this is a valid LUN for us to have. 2) Fix all my whitespace damage 3) Small cleanups based on feedback from the list. Also, I'm putting a build through koji, available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=663583 Chris Lalancette
Chris Lalancette schreef:
4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future.
How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself? Stefan
Stefan de Konink wrote:
Chris Lalancette schreef:
4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future.
How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself?
Yeah, it's not a bad plan at all. Someone just needs to work with upstream open-iscsi tools to split their stuff out into a library. I'm totally for this type of implementation; not only will we not have to fork and exec for some of this stuff, we should be able to get better error messages as well. That being said, until this sort of change makes it upstream, we have to work with what we've got at the moment. Chris Lalancette
Chris Lalancette schreef:
Stefan de Konink wrote:
4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future. How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build
Chris Lalancette schreef: libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself?
Yeah, it's not a bad plan at all. Someone just needs to work with upstream open-iscsi tools to split their stuff out into a library. I'm totally for this type of implementation; not only will we not have to fork and exec for some of this stuff, we should be able to get better error messages as well.
The I have looked at there Makefile before, and build this. They already mark there 'libraries'. So it would be only one update...
That being said, until this sort of change makes it upstream, we have to work with what we've got at the moment.
True, but also: it will only work with new versions of open-iscsi, so the sooner we get the 'fix/enhancement' the more chance our new implementation will have. Stefan
On Mon, Jun 16, 2008 at 04:10:42PM +0200, Stefan de Konink wrote:
Chris Lalancette schreef:
Stefan de Konink wrote:
4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future. How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build
Chris Lalancette schreef: libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself?
Yeah, it's not a bad plan at all. Someone just needs to work with upstream open-iscsi tools to split their stuff out into a library. I'm totally for this type of implementation; not only will we not have to fork and exec for some of this stuff, we should be able to get better error messages as well.
The I have looked at there Makefile before, and build this. They already mark there 'libraries'. So it would be only one update...
As I've said before, while this is useful in the long term, this doesn't make the existing code go away. We need to be able to spport iSCSI on RHEL-5 vintage which has no such library. Daniel. -- |: 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 :|
Daniel P. Berrange schreef:
On Mon, Jun 16, 2008 at 04:10:42PM +0200, Stefan de Konink wrote:
Chris Lalancette schreef:
4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future. How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build
Chris Lalancette schreef: libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself? Yeah, it's not a bad plan at all. Someone just needs to work with upstream open-iscsi tools to split their stuff out into a library. I'm totally for
Stefan de Konink wrote: this type of implementation; not only will we not have to fork and exec for some of this stuff, we should be able to get better error messages as well. The I have looked at there Makefile before, and build this. They already mark there 'libraries'. So it would be only one update...
As I've said before, while this is useful in the long term, this doesn't make the existing code go away. We need to be able to spport iSCSI on RHEL-5 vintage which has no such library.
Does RHEL-5 vintage have libvirt? But I acknowledge the issue. Stefan
On Mon, Jun 16, 2008 at 04:17:04PM +0200, Stefan de Konink wrote:
Does RHEL-5 vintage have libvirt?
yes, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (4)
-
Chris Lalancette -
Daniel P. Berrange -
Daniel Veillard -
Stefan de Konink