Chris Lalancette schreef:
Stefan de Konink wrote:
I think if you can get iscsi_sysfs.c; get_block_dev_from_lun you have the
code already to do this all. So basically get openiscsi into a lib with
helper functions.
OK. I took a look at this further, and I figured out what is going on here.
I
Daniel P. Berrange wrote:
> Can you provide a documentation patch describing the sysfs layout for the
> kernels the patch is intended to support, along with captured output from
> the isciadm tool running on each, for the various commands libvirt needs
> to run.
>
> The only way we are going t
On Wed, May 21, 2008 at 04:50:12PM +0200, Chris Lalancette wrote:
> Stefan de Konink wrote:
> > I think if you can get iscsi_sysfs.c; get_block_dev_from_lun you have the
> > code already to do this all. So basically get openiscsi into a lib with
> > helper functions.
>
> OK. I took a look at this
Stefan de Konink wrote:
> I think if you can get iscsi_sysfs.c; get_block_dev_from_lun you have the
> code already to do this all. So basically get openiscsi into a lib with
> helper functions.
OK. I took a look at this further, and I figured out what is going on here.
The original impetus for m
I think if you can get iscsi_sysfs.c; get_block_dev_from_lun you have the
code already to do this all. So basically get openiscsi into a lib with
helper functions.
ISCSI_LIB_SRCS = util.o io.o auth.o login.o log.o md5.o sha1.o iface.o
idbm.o iscsi_sysfs.o
To something like libopen-iscsi.so, and l
On Wed, 14 May 2008, Daniel P. Berrange wrote:
> So we have no choice but to make our current code work. If someone wants to
> pursue development of an iSCSI library as a long term solution that's a
> worthy goal, but for libvirt we need solutions that work today, for existing
> distros.
Why not
On Wed, May 14, 2008 at 03:19:58PM +0200, Chris Lalancette wrote:
> Stefan de Konink wrote:
> > Fix:
> > snprintf(sysfs_path, PATH_MAX,
> > "/sys/class/iscsi_session/session%s/device/"
> > "target%d:%d:%d/%d:%d:%d:%d",
> > session, target, channel, id, tar
On Wed, May 14, 2008 at 01:57:13PM +0200, Chris Lalancette wrote:
> Stefan de Konink wrote:
> >
> > snprintf(sysfs_path, PATH_MAX,
> > "/sys/class/iscsi_session/session%s/device/"
> > "target%d:%d:%d/%d:%d:%d:%d/block",
> > session, target, channel, id, t
On Wed, 14 May 2008, Chris Lalancette wrote:
> Yes, except the problem with your patch is that it will probably break the
> kernel I made the fixes for originally, which was either 2.6.23 or 2.6.24 (and
> which had the /sys/class/iscsi_session/session9/device/target9:0:0:0/
> 9:0:0:0/block/sdd typ
Stefan de Konink wrote:
> Fix:
> snprintf(sysfs_path, PATH_MAX,
> "/sys/class/iscsi_session/session%s/device/"
> "target%d:%d:%d/%d:%d:%d:%d",
> session, target, channel, id, target, channel, id, lun);
>
>
> (so remove /block)
>
>/* OK, no
On Wed, 14 May 2008, Chris Lalancette wrote:
> Ug. Yeah, that will do it. What kernel version are you running that your
> sysfs
> looks like that?
I already send a message to open-iscsi group. Fix is trivial and even more
simple. I'm running 2.6.21-xen (gentoo) with open-iscsi-2.0.869.2.
Fix:
Stefan de Konink wrote:
>
> snprintf(sysfs_path, PATH_MAX,
> "/sys/class/iscsi_session/session%s/device/"
> "target%d:%d:%d/%d:%d:%d:%d/block",
> session, target, channel, id, target, channel, id, lun);
>
>
> xen01 5:0:0:1 # pwd
> /sys/class/iscsi_sessi
On Wed, 14 May 2008, Stefan de Konink wrote:
> That doesn't make me happy.
I have currently solved it and made it work with the new version, I'll
send in a patch.
But there are more things that don't make me happy.
1) lun-0 is ignored
2)
Rescanning session [sid: 8, target:
iqn.1992-08.com.netap
On Wed, 14 May 2008, Stefan de Konink wrote:
> I consider my output interesting... it seems the -P option is ignored.
> (I'm running open-iscsi-2.0.868_rc1)
After upgrading to open-iscsi-2.0.869.2 i have a working output with -P
3... but...
xen01 skinkie # virsh pool-start netapp
libvir: Storage
On Wed, 14 May 2008, Stefan de Konink wrote:
> Something is present, thus the login was succesfull. How to get this to
> work with the libvirt storage pool?
>
> I have tried to change the target path. But it doesn't give me any output.
> I'll now look in the C code to see what you are giving as co
On Tue, 6 May 2008, Daniel P. Berrange wrote:
> As a simple example...
> - Create an XML definition for the iSCSI target you want to access,
I have created:
netapp
/dev/disk/by-path
> - Define the pool
>
> # virsh pool-define virt.xml
xen01 netapp # virsh pool-define virt.x
16 matches
Mail list logo