Hi Dmitri. DHCP on the backnet works as expected. eth0 is being configured correctly (gets the expected MAC address, which matches the one in dhcpd.conf). /etc/hosts is correct for both the private IP and the (intended) public-side IP.
The problem is that the config file for eth1 is being rewritten. It looks like Aaron got it right when he directed me to the configuration settings for the management node, where public-side IP configuration is set to "Static", that apparently means "set the public IP to match the listed value for the private IP", clearly not what we want. My question now is what to do instead; how to get a static (or effectively static, i.e. predictable) IP address for deployed machines without using that setting. On Tue, Jun 26, 2012 at 09:07:51AM -0400, Dmitri Chebotarov wrote: > Michael > > Could you please check that 'eth0macaddress', 'privateIPAddress' and > 'hostname' (in VCL DB) matches 'hardware ethernet', 'fixed address' and > 'host-name' options in dhcpd.conf for the host? Also, /etc/hosts should > have an entry 'privateIPAddress hostname' for captured computer. > > Can you also check that ifcfg-eth0 / 1 files don't have HWADDR option? > -- > Thank you, > Dmitri Chebotarov > Virtual Computing Lab Systems Engineer, TSD - Ent Servers & Messaging > 223 Aquia Building, Ffx, MSN: 1B5 > Phone: (703) 993-6175 > Fax: (703) 993-3404 > > On Tuesday, June 26, 2012 at 8:51 , Michael Jinks wrote: > > No, that's not the problem we're having. (We *did* have that problem, > and just deleting the offending rule file no lnoger works in RHEL 6, > but we fixed it by creating > /etc/udev/rules.d/75-persistent-net-generator.rules as a symlink to > /dev/null). At this point, Linux is doing the right thing with its > network devices when the image deploys to new virtual hardware. > The problem is that something -- and I can't think of any suspects > other > than something in VCL -- rewrites > /etc/sysconfig/network-scripts/ifcfg-eth1 during the capture process, > so > that it comes up with what should be eth0's IP address. > eth0, meanwhile, stays set to use DHCP, and gets the address we've > assigned there, so both interfaces come up with the same IP. > Okay, if VCL wants to write the config for the public-side IP, I > thought > I'd try changing the "IP Address" field in the database to the correct > one for this machine's public interface. But when I do that, vcld tries > to ssh to that address to initiate capture, and of course that fails > because the sshd listening on that interface doesn't trust vcld's key. > So it seems like we're in a catch 22 with our address naming, and I > don't know what I've done wrong. > On Mon, Jun 25, 2012 at 06:23:54PM -0400, Mike Haudenschild wrote: > > To clarify: Linux is probably creating an eth2 because it's holding out > that its OLD eth0 (which was in your image) might someday come back. > On Mon, Jun 25, 2012 at 6:22 PM, Mike Haudenschild > <[1][1]m...@longsight.com> wrote: > Ahh, I think you're running into this: > [2][2]http://markmail.org/message/t2ajnaew5qe4jxul > On Mon, Jun 25, 2012 at 5:55 PM, Michael Jinks > <[3][3]mji...@uchicago.edu> > wrote: > That's more or less what we're doing. Here are some details: > The source VM I'm capturing from is not represented in DNS at all. > On my management node in /etc/hosts I have: > 10.50.84.15 vcl-linux-template-2-bak > [4]128.135.192.15 vcl-linux-template-2 > (The second line is for my reference; it shouldn't be used by > anything > as far as I know.) > In dhcpd.conf I have: > host vcl-linux-template-2-bak { > option host-name "vcl-linux-template-2"; > hardware ethernet 00:50:56:01:99:0f; > fixed-address 10.50.84.15; > filename "/tftpboot/pxelinux.0"; > option dhcp-server-identifier 10.50.84.2; > next-server 10.50.84.2; > } > In the VCL database, the IP address for this host is 10.50.84.15 and > the > hostname is "vcl-linux-template-2-bak". > During capture, when prompted for the hostname or IP address of the > image to capture, I enter the IP address. > That all works fine for starting the capture. But for some reason, > when > the VM image is captured and then immediately redeployed, it comes > up > with its public-facing interface set to 10.50.84.15, and it appears > that > something in the capture process is rewriting the ifcfg-eth1 config > file > to match that address. > That's why I tried changing the IP in the database to the public > one, > which led to the ssh failure. > On Mon, Jun 25, 2012 at 03:51:19PM -0400, Mike Haudenschild wrote: > > Hi Mike, > > > > I handle this by running DHCP on the private VCL network, assigning > MAC addresses to specific VMs so as to make them predictable. Then add > each hosts PRIVATE IP to the management node's /etc/hosts file. This > will force the management node to resolve the compute name to the > private IP, instead of the public IP (which is probably coming from > your DNS server). > > > > Regards, > > Mike > > > > Sent via iPhone > > > > On Jun 25, 2012, at 15:45, Michael Jinks <[5][4]mji...@uchicago.edu> > wrote: > > > > > Hi List. Still trying to get a successful capture and deploy to > run; > > > here's my latest glitch. > > > > > > In the VCL web interface, under "Manage Computers" -> "Edit > Computer > > > Information", there's a single field for "IP address". I've been > > > entering the private-side IP address for VM's I'm trying to > capture. > > > > > > ...But, a few minutes ago I realized that VCL is using that field > to > > > rewrite my VM's public-facing address configuration during the > capture > > > process. Needless to say, that causes a failure when the captured > VM > > > boots. > > > > > > So, I tried filling the "IP Address" field with the public-side > address, > > > but that causes a failure when we try to capture the image, because > vcld > > > tries to ssh to that address, which is obviously wrong, as the VCL > ssh > > > key is trusted on the private-side sshd instance. > > > > > > What should I be doing instead? Is there any way to get the > correct > > > address set for the public and private interfaces? Do I have to do > this > > > by hand in the database? > > > > > > -- > > > Michael Jinks :: [6][5]mji...@uchicago.edu > > > University of Chicago IT Services > -- > Michael Jinks :: [7][6]mji...@uchicago.edu :: [8]773-469-9688 > University of Chicago IT Services > References > 1. [7]mailto:m...@longsight.com > 2. [8]http://markmail.org/message/t2ajnaew5qe4jxul > 3. [9]mailto:mji...@uchicago.edu > 4. tel:128.135.192.15 > 5. [10]mailto:mji...@uchicago.edu > 6. [11]mailto:mji...@uchicago.edu > 7. [12]mailto:mji...@uchicago.edu > 8. tel:773-469-9688 > > -- > Michael Jinks :: [13]mji...@uchicago.edu :: 773-469-9688 > University of Chicago IT Services > > References > > 1. mailto:m...@longsight.com > 2. http://markmail.org/message/t2ajnaew5qe4jxul > 3. mailto:mji...@uchicago.edu > 4. mailto:mji...@uchicago.edu > 5. mailto:mji...@uchicago.edu > 6. mailto:mji...@uchicago.edu > 7. mailto:m...@longsight.com > 8. http://markmail.org/message/t2ajnaew5qe4jxul > 9. mailto:mji...@uchicago.edu > 10. mailto:mji...@uchicago.edu > 11. mailto:mji...@uchicago.edu > 12. mailto:mji...@uchicago.edu > 13. mailto:mji...@uchicago.edu -- Michael Jinks :: mji...@uchicago.edu :: 773-469-9688 University of Chicago IT Services
