Follow up on this previous item:
On deck: zone detach and attach, upgrade on attach.
To be able to do the above requires that there be some kind of
preservation of the data on top of iscsi targets. I tried putting iscsi
targets into metasets which could be taken and released. Does not
You're assuming the packets sent on this UDP socket all have the same
destination and that routing does not change between transmissions.
I'm not assuming that, just pointing out that in general there will
not be a different source address in each packet, and that for a given
destination we
Peter Memishian writes:
You're assuming the packets sent on this UDP socket all have the same
destination and that routing does not change between transmissions.
I'm not assuming that, just pointing out that in general there will
not be a different source address in each packet, and
If you don't explicitly bind a preferred address to use (most
applications do not), then the kernel will choose an address for you.
With UDP, this happens on a packet-by-packet basis.
Really? I'd expect the first packet to a given destination to construct
an IRE cache entry, and then for
Ellard Roush writes:
James Carlson wrote:
That point in time is as soon as your application can start. It need
not have any dependencies at all.
Here is the other point that needs to be clarified.
This is not an application.
Applications do not start until much later.
We have to get
Hi James,
James Carlson wrote:
Ellard Roush writes:
James Carlson wrote:
That point in time is as soon as your application can start. It need
not have any dependencies at all.
Here is the other point that needs to be clarified.
This is not an application.
Applications do not start until
Ellard Roush writes:
Thanks for explaining about how the routing situation changes dynamically.
However, we have been aware of that for a long time.
Sun Cluster (SC) is a High Availability product.
We have customers that want recovery to occur in less than 2 seconds.
While we have not
Hi James,
It is already well known that routes come and go.
It is already well known that the way to determine
whether a destination is reachable is to attempt to
contact that destination.
That is NOT the issue that I am raising.
We have seen the following PROBLEM.
Our code has a dependency upon
Hi James,
James Carlson wrote:
Ellard Roush writes:
If we make the code sleep long enough for Solaris routing to
complete initialization, then after a failed attempt
to connect, then retries work whenever the route becomes
available. The problem is that Solaris routing goes into
an error
roush writes:
No, I have not encountered this problem. The targets mount just in time
for my zones. But it sounds to me like a dependency on
svc:/network/routing/route:default for cluster could help this along?
CT
Hi Christine,
We have dependencies upon routing.
However, this
roush wrote:
Sun Cluster plans to support an iSCSI disk as a quorum device.
Sun Cluster accesses the iSCSI disk early in the boot process.
When the iSCSI disk is on the same subnet as the cluster machines,
things work. When the iSCSI disk is on a different subnet
the system cannot find the
Christine Tran wrote:
roush wrote:
Sun Cluster plans to support an iSCSI disk as a quorum device.
Sun Cluster accesses the iSCSI disk early in the boot process.
When the iSCSI disk is on the same subnet as the cluster machines,
things work. When the iSCSI disk is on a different subnet
Hi Christine,
Interesting report.
We also will be supporting the use of iSCSI with Sun Cluster.
Here is one specific problem that we have encountered that may or may
not affect you.
Sun Cluster plans to support an iSCSI disk as a quorum device.
Sun Cluster accesses the iSCSI disk early in the
What is iSCSI?
SCSI over TCP/IP. iSCSI makes remote disks look local. The remote host
with storage resource presents iscsi targets. The client accessing the
storage is the initiator. iSCSI initiator was present in S10 3/05 and
up. iSCSI target went into S10 8/07.
Why zones on iSCSI?
iSCSI
14 matches
Mail list logo
