Hi, For anyone who is interested; I created some basic scripts based on my current iSCSI block script. http://kinkrsoftware.nl/contrib/xen/block-netapp http://kinkrsoftware.nl/contrib/xen/netapp-lun.py Basically these two scripts allow you to start a vfiler with a qtree of customers. You log in the NetApp upon boot, and can use: netapp://customer1/disk1 It is work in progress... because I would prefer the vfiler IP to be in that line too, but it seems the iSCSI portal IP != the NetApp shell IP. Suggestions can be made on the list or as private reply. The helper script is for persons that (like me) are not yet able to add a key to the NetApp authorized_keys2 file. Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, For anyone who is interested; I created some basic scripts based on my current iSCSI block script. http://kinkrsoftware.nl/contrib/xen/block-netapp http://kinkrsoftware.nl/contrib/xen/netapp-lun.py Basically these two scripts allow you to start a vfiler with a qtree of customers. You log in the NetApp upon boot, and can use: netapp://customer1/disk1 It is work in progress... because I would prefer the vfiler IP to be in that line too, but it seems the iSCSI portal IP != the NetApp shell IP. Suggestions can be made on the list or as private reply. The helper script is for persons that (like me) are not yet able to add a key to the NetApp authorized_keys2 file. Stefan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Cool idea. Might be generally useful to people? Is anybody else using this with a NetApp? Any other features wanted in order to make this work? If it''s valuable it would be worth looking at adding it, or something like it, into the Xen tree as an additional block script. We''ve still not exploited the ability to transparently support crazy networked block devices as much as we could :-) Cheers, Mark On Monday 28 April 2008, Stefan de Konink wrote:> Hi, > > > For anyone who is interested; I created some basic scripts based on my > current iSCSI block script. > > http://kinkrsoftware.nl/contrib/xen/block-netapp > http://kinkrsoftware.nl/contrib/xen/netapp-lun.py > > Basically these two scripts allow you to start a vfiler with a qtree of > customers. You log in the NetApp upon boot, and can use: > > netapp://customer1/disk1 > > > It is work in progress... because I would prefer the vfiler IP to be in > that line too, but it seems the iSCSI portal IP != the NetApp shell IP. > Suggestions can be made on the list or as private reply. The helper > script is for persons that (like me) are not yet able to add a key to the > NetApp authorized_keys2 file. > > > Stefan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson schreef:> Might be generally useful to people? Is anybody else using this with a > NetApp? Any other features wanted in order to make this work?I have also created a patch for libvirt. http://kinkrsoftware.nl/contrib/libvirt/pool.patch Will most likely be included soon too. This allows to directly map the iscsi part: <pool type="iscsi"> <name>netapp</name> <source> <host name="172.16.103.200"/> <device path="iqn.1992-08.com.netapp:sn.118046347:vf.88fa4694-0ba6-11dd-b8a9-00a09807592f"/> </source> <target> <path>/dev/disk/by-path</path> </target> </pool> with: <domain type=''xen'' > <name>Gentoo</name> <os> <type>linux</type> <kernel>/usr/lib/xen/boot/linux-2.6.20-xen-r6</kernel> <cmdline> root=/dev/xvda ro ip=85.17.131.4:1.2.3.4:85.17.131.253:255.255.255.0::eth0:off</cmdline> </os> <memory>131072</memory> <vcpu>1</vcpu> <devices> <disk type=''pool''> <source pool=''netapp'' volume=''lun-3'' /> <target dev=''xvda''/> </disk> <interface type=''bridge''> <source bridge=''xenbr0''/> <mac address=''aa:00:00:00:00:11''/> <script path=''/etc/xen/scripts/vif-bridge''/> </interface> </devices> </domain> As you see this does not exploit the OnTap interface, but uses preknown lun numbers. More clean for Daniel and his crew. But about NetApp; within Citrix, which persons do you talk to? The reply about Xen/NetApp that reached me didn''t sound like exploiting the best of both worlds.> If it''s valuable it would be worth looking at adding it, or something like it, > into the Xen tree as an additional block script. We''ve still not exploited > the ability to transparently support crazy networked block devices as much as > we could :-)Please add my iscsi script too then, I have heard it is also in Suse ;) I''ve talked with the open-iscsi developer crew about making their code available in a shared library. This could eventually lead to a iscsi ''program'' instead of an iscsi script with heuristics. Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> As you see this does not exploit the OnTap interface, but uses preknown > lun numbers. More clean for Daniel and his crew.The OnTap interface is the SSH commandline interface you''re using, right? It does sound cleaner to avoid that; I wasn''t 100% convinced by the use of that in the Xen script as it seemed like an "unexpected" behaviour for a low lever block script... On the other hand, presumably it makes interacting with the filer a bit less friendly.> But about NetApp; within Citrix, which persons do you talk to? The reply > about Xen/NetApp that reached me didn''t sound like exploiting the best > of both worlds.I don''t know what the reply you''ve already seen is regarding but for the patch in question, it seems like it would be reasonable to just submit to the xen-devel list and request a merge. I wouldn''t be surprised if there''s someone within Citrix working on NetApp integration (speculation on my part, since I''m not strictly a Citrix/XenSource employee and generally lack inside information) but equally well, they''d not necessarily be concerned with the OSS version of Xen.> > If it''s valuable it would be worth looking at adding it, or something > > like it, into the Xen tree as an additional block script. We''ve still > > not exploited the ability to transparently support crazy networked block > > devices as much as we could :-) > > Please add my iscsi script too then, I have heard it is also in Suse ;) > I''ve talked with the open-iscsi developer crew about making their code > available in a shared library. This could eventually lead to a iscsi > ''program'' instead of an iscsi script with heuristics.Ah, I thought I''d seen an iSCSI patch whizz by on the mailing lists at some point - hadn''t realised it was also you! Have you done any further work on this or is the original patch posting on the 2007-11-25 the most recent state of the patch? Browsing the mailing archives I also see a script from Kurt Garloff mentioned. Do you know if it is yours that is in SuSE or Kurt''s? It certainly seems like it''d be desirable to have these scripts in upstream Xen where possible, especially if distros are shipping them and people want to use them! Cheers, Mark -- Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, May 19, 2008 at 12:29 PM, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> Cool idea. > > Might be generally useful to people? Is anybody else using this with a > NetApp? Any other features wanted in order to make this work? > > If it''s valuable it would be worth looking at adding it, or something like it, > into the Xen tree as an additional block script. We''ve still not exploited > the ability to transparently support crazy networked block devices as much as > we could :-)I''ve been playing with adding extensions to phy: to handle dynamic block devices. For iscsi, it''s something like. phy:iscsi:[static]/<targetid>/<lun>/[serverIpAddr] e.g. disk = [''phy:/dev/zvol/dsk/tank/guests/snv89,0,w'', ''phy:iscsi:static/iqn.1986-03.com.sun:02:17f34578-00a9-ef69-f3e9-b8a2896a4915/0/192.168.0.70,1,w''] when the block hotplug script see''s the phy:<ext>: it looks for something like a block-<ext> script and runs it if it can find it, else, defaults down normal path. The iscsi hotplug script verifies/sets up the disk, then adds a params-dynamic (equivalent to Stefan''s node?) entry in xenstore. A small change to the disk backend looks for a dynamic entry first, then defaults back to param if it can''t find it. I currently have a small change to xend to handle this for non boot disks. I still need to look at setting up the disks before pygrub runs so you can boot off of it.. def _parse_uname(uname): fn = taptype = None if uname.find(":") != -1: (typ, fn) = uname.split(":", 1) - if typ == "phy" and not fn.startswith("/"): - fn = "/dev/%s" %(fn,) - if typ == "tap": + if typ == "tap" or typ == "phy": (taptype, fn) = fn.split(":", 1) The nice thing about this, is it''s really easy to extend to other block devices, etc. e.g. phy:fc:... phy:npiv:... MRJ MRJ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefan de Konink
2008-May-19 20:27 UTC
[Xen-users] Re: [Xen-devel] NetApp vfiler example scripts
Mark Williamson schreef:>> As you see this does not exploit the OnTap interface, but uses preknown >> lun numbers. More clean for Daniel and his crew. > > The OnTap interface is the SSH commandline interface you''re using, right? It > does sound cleaner to avoid that; I wasn''t 100% convinced by the use of that > in the Xen script as it seemed like an "unexpected" behaviour for a low lever > block script... On the other hand, presumably it makes interacting with the > filer a bit less friendly.Exactly it was the same compromise I have made for libvirt. I like the prototyping and freedom of the Xen scripts directory very much. But sometimes strictness in required.>> But about NetApp; within Citrix, which persons do you talk to? The reply >> about Xen/NetApp that reached me didn''t sound like exploiting the best >> of both worlds. > > I don''t know what the reply you''ve already seen is regarding but for the patch > in question, it seems like it would be reasonable to just submit to the > xen-devel list and request a merge. I wouldn''t be surprised if there''s > someone within Citrix working on NetApp integration (speculation on my part, > since I''m not strictly a Citrix/XenSource employee and generally lack inside > information) but equally well, they''d not necessarily be concerned with the > OSS version of Xen.From what I understood of the forwarded mail was they ''implemented'' Xen+iSCSI on their filers as ''local storage'', in my opinion missing the point of the power of iSCSI in migration. Thus a Xen node gets one or two iSCSI disks, and thats it. Their limitation on LUNs (2048) is in my humble opinion a very bad thing, and a reason to advice something like OpenSolaris for the target job.>>> If it''s valuable it would be worth looking at adding it, or something >>> like it, into the Xen tree as an additional block script. We''ve still >>> not exploited the ability to transparently support crazy networked block >>> devices as much as we could :-) >> Please add my iscsi script too then, I have heard it is also in Suse ;) >> I''ve talked with the open-iscsi developer crew about making their code >> available in a shared library. This could eventually lead to a iscsi >> ''program'' instead of an iscsi script with heuristics. > > Ah, I thought I''d seen an iSCSI patch whizz by on the mailing lists at some > point - hadn''t realised it was also you!;)> Have you done any further work on this or is the original patch posting on the > 2007-11-25 the most recent state of the patch? Browsing the mailing archives > I also see a script from Kurt Garloff mentioned. Do you know if it is yours > that is in SuSE or Kurt''s?The Suse guy that mailed me took my script as basis again, and changed the path of iscsiadm, trivial changes. Think if we can do an /usr/bin/env on it, it is distro safe. http://kinkrsoftware.nl/contrib/xen/> It certainly seems like it''d be desirable to have these scripts in upstream > Xen where possible, especially if distros are shipping them and people want > to use them!I think stuff like iSCSI makes adoption more easy for people, but from my anti-xend feelings, I think it would be much better to invest time and resources to help Red Hat with their patches of Qemu+XEN, and only use libvirt as API. Mark Johnson schreef: > I''ve been playing with adding extensions to phy: to handle dynamic > block devices. For iscsi, it''s something like. > phy:iscsi:[static]/<targetid>/<lun>/[serverIpAddr] > > e.g. > disk = [''phy:/dev/zvol/dsk/tank/guests/snv89,0,w'', > ''phy:iscsi:static/iqn.1986-03.com.sun:02:17f34578-00a9-ef69-f3e9-b8a2896a4915/0/192.168.0.70,1,w''] > > when the block hotplug script see''s the phy:<ext>: it > looks for something like a block-<ext> script and runs > it if it can find it, else, defaults down normal path. Isn''t that what normally happens? Just type blabla: and it will go to block-blabla? > The iscsi hotplug script verifies/sets up the disk, then adds > a params-dynamic (equivalent to Stefan''s node?) entry in > xenstore. A small change to the disk backend looks for a > dynamic entry first, then defaults back to param if it can''t find it. I have based all my code on the shoulders of giants, the final code was one big mash up. Stefan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, May 19, 2008 at 4:27 PM, Stefan de Konink <skinkie@xs4all.nl> wrote:> Mark Williamson schreef: > Mark Johnson schreef: >> I''ve been playing with adding extensions to phy: to handle dynamic >> block devices. For iscsi, it''s something like. >> phy:iscsi:[static]/<targetid>/<lun>/[serverIpAddr] >> >> e.g. >> disk = [''phy:/dev/zvol/dsk/tank/guests/snv89,0,w'', >> >> ''phy:iscsi:static/iqn.1986-03.com.sun:02:17f34578-00a9-ef69-f3e9-b8a2896a4915/0/192.168.0.70,1,w''] >> >> when the block hotplug script see''s the phy:<ext>: it >> looks for something like a block-<ext> script and runs >> it if it can find it, else, defaults down normal path. > > Isn''t that what normally happens? Just type blabla: and it will go to > block-blabla?Not for Solaris.>> The iscsi hotplug script verifies/sets up the disk, then adds >> a params-dynamic (equivalent to Stefan''s node?) entry in >> xenstore. A small change to the disk backend looks for a >> dynamic entry first, then defaults back to param if it can''t find it. > > I have based all my code on the shoulders of giants, the final code was one > big mash up.I assume you aren''t using pygrub to boot off of a iscsi disk? Thanks, MRJ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 20 May 2008, Mark Johnson wrote:> On Mon, May 19, 2008 at 4:27 PM, Stefan de Konink <skinkie@xs4all.nl> wrote: > > Mark Williamson schreef: > > Mark Johnson schreef: > >> I''ve been playing with adding extensions to phy: to handle dynamic > >> block devices. For iscsi, it''s something like. > >> phy:iscsi:[static]/<targetid>/<lun>/[serverIpAddr] > >> > >> e.g. > >> disk = [''phy:/dev/zvol/dsk/tank/guests/snv89,0,w'', > >> > >> ''phy:iscsi:static/iqn.1986-03.com.sun:02:17f34578-00a9-ef69-f3e9-b8a2896a4915/0/192.168.0.70,1,w''] > >> > >> when the block hotplug script see''s the phy:<ext>: it > >> looks for something like a block-<ext> script and runs > >> it if it can find it, else, defaults down normal path. > > > > Isn''t that what normally happens? Just type blabla: and it will go to > > block-blabla? > > Not for Solaris.I guess the main problem is that the scripts are targeted for Linux with sysfs.> >> The iscsi hotplug script verifies/sets up the disk, then adds > >> a params-dynamic (equivalent to Stefan''s node?) entry in > >> xenstore. A small change to the disk backend looks for a > >> dynamic entry first, then defaults back to param if it can''t find it. > > > > I have based all my code on the shoulders of giants, the final code was one > > big mash up. > > I assume you aren''t using pygrub to boot off of a iscsi disk?Exactly. I never understood the need for pygrub in the first place. Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel