Hello Mike,

I'm curious if the management node set to statically assign the public address.

Can you double check the settings for your management node? Select
Management node-> Edit management Node Information and select Edit.
Near the bottom.
With this feature you can define how VCL handles the node's IP
address, dynamic dhcp, manual dhcp, or static (statically assign an
address).

Aaron

On Tue, Jun 26, 2012 at 8:51 AM, Michael Jinks <mji...@uchicago.edu> 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> 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



-- 
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University

All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.

Reply via email to