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