Re: [vcl-team] Re: VCL: public/private IP discrepency?
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
Re: [vcl-team] Re: VCL: public/private IP discrepency?
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
Re: [vcl-team] Re: VCL: public/private IP discrepency?
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
Re: [vcl-team] Re: VCL: public/private IP discrepency?
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
Re: [vcl-team] Re: VCL: public/private IP discrepency?
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.comwrote:
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.eduwrote:
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
