Thank's David :) It is as you say, don't configure inside the Linux servers if you don't have to. That is our main goal, as little unique config as possible inside the Linux servers, and the values you have to setup should be moved outside the Linux servers if possible. We did some tries with DHCP as well at first, but it did not work due to we only had IP-packets sent via vswitches, and not ethernet packages. And that is what is needed we finally learned. We also run into some problems when we mixed code MACaddresss and autogenerated, it can collide and the fact that we sometimes move servers from z10 box A to z10 box B we also learned that it is required to know your MACaddresses and IPnrs. So we now have autogenerated only, you can't mix them, it will be conflicts.
We also tried to have it in CMS-files (that you now can read), it worked quite ok, but it was to many error sources, it was not rock-solid stable. By define the ipconfig in vm PFkeys we are safe and also not depending on a DHCP server. And we also by that got it documented in a central place, this is in fact really good. Cordialement / Vriendelijke Groeten / Best Regards / Med Vänliga Hälsningar Tore Agblad Volvo Information Technology Infrastructure Mainframe Design & Development SE-405 08, Gothenburg Sweden E-mail: [email protected] http://www.volvo.com/volvoit/global/en-gb/ ________________________________________ From: Linux on 390 Port [[email protected]] On Behalf Of David Boyes [[email protected]] Sent: Thursday, July 02, 2009 15:39 To: [email protected] Subject: Re: Updated paper available - "Sharing and maintaining SLES 10 SP2 Linux under z/VM" > > About creating clones, we have made another approach. > > Every server configures the network/ip itself at every boot, > Configures the network at *every* boot? Why not just at first boot? Do > you > never put the real IP address, host name and other values in /etc? Pretty much DHCP, without the DHCP process. Let me pose the question differently: As long as the server has some immutable identity (in this case, the VM userid) and some reliable way to configure itself based on that immutable ID, why *would* you hardcode all that stuff inside the guest? Given the intense dependence of Linux on Z on the network, short of widespread integration of the IUCV console driver, you *want* that stuff outside the Linux system where you can easily fix it if it gets horked somehow or you need to change it. There are arguments for moving fstabs and other such goodies outside too. Personally (as I said yesterday at Marist), this is what DHCP is for, but Aglad's system works equally well, and is probably a good example of why a hypervisor is so handy. You *can* get this stuff outside the guests and use a highly developed hypervisor as part of the control infrastructure. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
