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]m...@longsight.com (mailto:m...@longsight.com)> wrote: > > > > Ahh, I think you're running into this: > > > > [2]http://markmail.org/message/t2ajnaew5qe4jxul > > On Mon, Jun 25, 2012 at 5:55 PM, Michael Jinks <[3]mji...@uchicago.edu > > (mailto: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]mji...@uchicago.edu > > > (mailto: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]mji...@uchicago.edu (mailto:mji...@uchicago.edu) > > > > University of Chicago IT Services > > > > -- > > Michael Jinks :: [7]mji...@uchicago.edu (mailto:mji...@uchicago.edu) :: > > [8]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. tel:128.135.192.15 > > 5. mailto:mji...@uchicago.edu > > 6. mailto:mji...@uchicago.edu > > 7. mailto:mji...@uchicago.edu > > 8. tel:773-469-9688 > > > > > -- > Michael Jinks :: mji...@uchicago.edu (mailto:mji...@uchicago.edu) :: > 773-469-9688 > University of Chicago IT Services > >
