[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.