> Thank's David :) > It is as you say, don't configure inside the Linux servers if you don't > have to.
You're welcome. It sounds like a pretty cool system. > 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. Layer 2 VSWITCHes fix that problem nicely, especially now that VM TCPIP can cope with being connected to one. There's also some neat tricks you can do with TFTP and DHCP options to pass in configuration files -- I've been playing with the idea of having a VM-based TFTP server manage the configuration files with Ken Chamberlain's LIB (an awesomely useful bit of VM-based file management software) and have the Linux guest get a number of things that way. There's lots of user-definable DHCP option space available to designate where to get stuff. > 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. Yes, that is always a problem with user-managed MAC space. In recent versions of the dhcpd code, you can specify wildcards to respond to, but as you say, for manageability you really need to pick either autogenerated or all-user-specified. The addition in recent DHCP server code of the ability to have a database of user-specified MACs (a real SQL one, not the internal Berkeley db kind) helps with that (and helps keep the addresses unique as well). ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
