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> 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>
>    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>
>    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
>    > > University of Chicago IT Services
> 
>      --
>      Michael Jinks :: [7]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 :: 773-469-9688
University of Chicago IT Services

Reply via email to