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
|
Home