On Jan 24, 2008, at 1:41 AM, Mark Perry wrote:
Did you try adding the MAC address to the NICDEF statement for each
guest?
I was aware of this when we were first deploying DHCP on the VSWITCH,
but I specifically chose not to make use of MACID. I can no longer
remember why.
ok
bear
---
On Thursday, 01/24/2008 at 02:22 EST, Susan Zimmerman
<[EMAIL PROTECTED]> wrote:
> IBM followed up with the following:
>
> "I have been reviewing your query with defect support level2 and am not
> sure how your setup is but if you have multipath EDEVs configured, that
> should be able to handle the
Hi Listers,
IBM followed up with the following:
"I have been reviewing your query with defect support level2 and am not
sure how your setup is but if you have multipath EDEVs configured, that
should be able to handle the error condition in question without being
taken offline. The system will dis
"Much Sooner than Previously Said". Still can't be much more specific in
public.
> Just before I go to bed, I must ask: David what news/status on Open
> Solaris for z?
--
For LINUX-390 subscribe / signoff / archive access instru
Just before I go to bed, I must ask: David what news/status on Open
Solaris for z?
mark
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visi
David Boyes wrote:
Yes Ok :-)
That and its 11:45pm and I need sleep ;-)
Mark
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://
On Jan 24, 2008, at 10:18 AM, Mark Perry wrote:
Anyway, tcpdump-qeth works on my SLES10-SP1 system.
AUGH!
I didn't remember that tcpdump-qeth existed.
Adam
--
For LINUX-390 subscribe / signoff / archive access instructions,
> You are correct in what you say David, but not fixing the symptom
> amounts to "everybody dies until the server is fixed".
No one said that you don't fix the immediate situation when there's a
problem. What you then do is figure out how to fix the root problem so
the symptom *can't* happen again
Adam Thornton wrote:
Could either IBM or one of the major distributors *please* work with
the upstream maintainers there to get this fix for QDIO (if that
doesn't break other implementations--or a fix that DOES play nice with
other interfaces) into the standard pcap source tree? I was
embarrassed
On Jan 24, 2008, at 9:56 AM, Alan Altmark wrote:
I think as long as you don't define the layer 3 VSWITCH as
PRIROUTER, you
can run a VM or Linux DHCP server on the VSWITCH. As was noted
elsewhere,
specify the MAC on the NICDEF. (You need to worry about MACPREFIX in
SYSTEM CONFIG as well.)
Bes
On Thursday, 01/24/2008 at 10:07 EST, David Boyes <[EMAIL PROTECTED]>
wrote:
> Probably a better approach would be for the vswitch to implement a DHCP
> helper feature that would allow catching and forwarding DHCP requests to
> an outside server for handling via layer 3, a la the DHCP forwarding
>
David Boyes wrote:
But, that's fixing the symptom, not the problem. The root problem is
that nobody noticed that their primary DNS wasn't answering. Fixing that
is either insulating the guests from the problem (ie, ensuring that the
primary DNS seen by the guests always answers), or adding some
> > There is a default TCP connect timeout in the TCP specs, usually 2
> > minutes. You can change it in the application, but IMHO, that's
fixing
> > the symptom, not the problem (no proactive monitoring of your DNS).
> >
> Um Really?
>
> [snip]
>
> Wonderful things man pages
> RTFM
See above: "
> But using a DHCP server to get "random" free IP address may not be
> handy for servers. It makes the server very hard to find for the
> users.
Unless you implement dynamic DNS, but that has it's own set of problems.
Layer 2 switching is much easier, and then everything Just Works the way
it's su
Hi Susan...
> Whichever way the path is
> taken offline, if I lose access to the device because a path is taken
> offline (either with CUIR or manual), I have a problem. I think I'll go
> force a path off to my EDEVs and see if it recovers.
I agree with you that the multipathing of the EDEVs is
On Thursday, 01/24/2008 at 08:26 EST, Susan Zimmerman
<[EMAIL PROTECTED]> wrote:
> I agree with your [Pieter's] statement that z/VM EDEVs should handle a
failing
> path...providing they are defined with multiple pathssince as you so
> eloquently put it "that is the whole point of multipath".
I have no sage suggestions, other than to be sure you're using the SLES 10
SP 1 disk(s) (I prefer the DVD myself), but I can say that the install does
(or will) work, and that we have several guests running SLES 10 SP 1 at this
point.
--
.~.Robert P. Nix Mayo Foundation
/V\
--snip--
In my opinion that should *not* be that.
=20
CUIR only makes the live of the device ERP's easier by quiescing instead =
of failing a path. But FCP multipathing native with Linux multipath or =
with z/VM EDEV should be able (when set up correctly) to live with =
pathes going down. That is t
Many years ago, when I allocated cyl 0 as "page"
(on a real paging "drum" with fixed heads)
it caused an I/O error but no problems
(CP just saved the page to another slot)
but at the next IPL the VTOC & dummy DSCB
were lost and the pack had to be reformatted
at each IPL before it would mount.
---
Dovetailed Technologies announces today that the Co:Z Co-Processing
Toolkit for z/OS is now free for use under the terms of the Apache V2
license. Client/target system RPMs for Linux on System z
(31 and 64 bit) are also available.
The Co:Z Co-Processing Toolkit allows a z/OS batch job to remotel
On Jan 24, 2008 10:21 AM, Mark Perry <[EMAIL PROTECTED]> wrote:
> > There is a default TCP connect timeout in the TCP specs, usually 2
> > minutes. You can change it in the application, but IMHO, that's fixing
> > the symptom, not the problem (no proactive monitoring of your DNS).
> >
> Um Really?
r.stricklin wrote:
ase, even though the server sends it.
2) We can't rely on the MAC address to identify a particular client.
Since we wanted static leases in order to avoid having to get lots of
cooperation from our Windows DDNS folks, we had to set up the SuSE
dhcp client config file to send
David Boyes wrote:
But my question is how does Linux handle this
situation? Does it have a timeout limit that must be
reached before trying the 2nd DNS or does it try x
times then die?
There is a default TCP connect timeout in the TCP specs, usually 2
minutes. You can change it in the applicat
On Jan 23, 2008 6:02 PM, David Boyes <[EMAIL PROTECTED]> wrote:
> > Are there any issues in using DHCP through a vSwitch? Are there any
> > configuration issues I need to be aware of?
>
> Must be a layer 2 VSWITCH. Other than that, should work fine.
I hear everyone say this, but I am pretty sure
24 matches
Mail list logo
