Re: VCL: public/private IP discrepency?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, June 26, 2012 8:27:07 AM Michael Jinks wrote: It looks like Aaron got it right when he directed me to the configuration settings for the management node, where public-side IP configuration is set to Static, that apparently means set the public IP to match the listed value for the private IP, clearly not what we want. My question now is what to do instead; how to get a static (or effectively static, i.e. predictable) IP address for deployed machines without using that setting. Michael, VCL always needs fixed DHCP on the private network. For the public network, static means that once sshd is up on a node on the private interface, VCL will connect to the node across the private network and set the public IP on the public interface to what is in the database at computer.IPaddress (the public address) for that node. It should not be setting the public address to what is in the database at computer.privateIPaddress. Prior to 2.3 (unreleased), you can only set the private address of a node when you initially add it, and only using the add multiple computers part of the site (hint: you can actually add a single computer using the add multiple pages). For any nodes you already have in the database, you will need to change the private IP address directly in the database if so desired. So, you should be able to obtain your goal using the static setting. Josh - -- - --- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu 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. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk/x7ZkACgkQV/LQcNdtPQONfwCfc/YYO1M/hb3gt6nd46xjplPj UakAn12OzufWWJ7A/VF10vPfYNoDdnwU =gzEk -END PGP SIGNATURE-
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: public/private IP discrepency?
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
Re: VCL: public/private IP discrepency?
Hi Aaron.
Ah, sure enough, it is set to Static. Silly me, when I first set this
up I read that to mean don't try to set the public IP, leave it to us
humans to configure.
...Okay, so how would we get that behvior? We'll want our deployed VM's
to come up with predictable IP addresses so that customers can reach
them, so dynamic DHCP isn't going to work. Our NOC runs DHCP on the
public wire, and can't do static assignments of IP addresses due to
limitations in their DHCP server. (In VCL's terms, what's the
difference between dynamic and manual DHCP?)
Are other sites using DynDNS, maybe? Does VCL have hooks for updating
the DynDNS service when it deploys a machine?
I think our only other option is going to be to deploy a DHCP server on
the public-facing segment with lots of precautions to make sure it
doesn't try to handle requests from anything other than VCL-deployed
systems. Technically easy, organizationally challenging, so I'd like to
avoid that if possible.
On Tue, Jun 26, 2012 at 09:03:32AM -0400, Aaron Peeler wrote:
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
Re: VCL: public/private IP discrepency?
Hi Dmitri.
DHCP on the backnet works as expected. eth0 is being configured
correctly (gets the expected MAC address, which matches the one in
dhcpd.conf). /etc/hosts is correct for both the private IP and the
(intended) public-side IP.
The problem is that the config file for eth1 is being rewritten. It
looks like Aaron got it right when he directed me to the configuration
settings for the management node, where public-side IP configuration is
set to Static, that apparently means set the public IP to match the
listed value for the private IP, clearly not what we want. My question
now is what to do instead; how to get a static (or effectively static,
i.e. predictable) IP address for deployed machines without using that
setting.
On Tue, Jun 26, 2012 at 09:07:51AM -0400, Dmitri Chebotarov wrote:
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][1]m...@longsight.com wrote:
Ahh, I think you're running into this:
[2][2]http://markmail.org/message/t2ajnaew5qe4jxul
On Mon, Jun 25, 2012 at 5:55 PM, Michael Jinks
[3][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
Re: VCL: public/private IP discrepency?
Thanks Aaron. Maybe this will be obvious when we get further into our testing, but how do you provide access to deployed hosts where the DHCP-assigned addresses are random? Are you using DynDNS? On Tue, Jun 26, 2012 at 09:36:52AM -0400, Aaron Peeler wrote: Set it to dynamic dhcp, this setting will work fine for either true dynamic dhcp or fixed dhcp assignments. The main differences from VCL's perspective: Dynamic dhcp setting - fetch the assigned address using ifconfig or ipconfig(depending on the provisioned OS) and update the public IP address in the computer table. Manual dhcp setting- return the address assigned in vcl database, this method assumes that the address is correctly defined in the vcl.computer table. This setting will likely go away since the dynamic dhcp option is doing the right thing in confirming an address got assigned to the machine. I would like to see the manual dhcp setting go away in the future, since it's not really doing anything. We have a mix here at NCSU, our campus networking group uses fixed dhcp on campus, in another off campus DC we use dynamic dhcp. We have it set to dynamic dhcp for all of our 8 management nodes. Aaron On Tue, Jun 26, 2012 at 9:19 AM, Michael Jinks mji...@uchicago.edu wrote: Hi Aaron. Ah, sure enough, it is set to Static. ?Silly me, when I first set this up I read that to mean don't try to set the public IP, leave it to us humans to configure. ...Okay, so how would we get that behvior? ?We'll want our deployed VM's to come up with predictable IP addresses so that customers can reach them, so dynamic DHCP isn't going to work. ?Our NOC runs DHCP on the public wire, and can't do static assignments of IP addresses due to limitations in their DHCP server. ?(In VCL's terms, what's the difference between dynamic and manual DHCP?) Are other sites using DynDNS, maybe? ?Does VCL have hooks for updating the DynDNS service when it deploys a machine? I think our only other option is going to be to deploy a DHCP server on the public-facing segment with lots of precautions to make sure it doesn't try to handle requests from anything other than VCL-deployed systems. ?Technically easy, organizationally challenging, so I'd like to avoid that if possible. On Tue, Jun 26, 2012 at 09:03:32AM -0400, Aaron Peeler wrote: 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
Re: VCL: public/private IP discrepency?
Yes, in the vcl code during the post_load tasks of the OS modules. There is a step to collect the network configuration of the loaded node(vm or bare-metal), figure out the publicly assigned address and then update the database which is then presented to the end-user. Aaron On Tue, Jun 26, 2012 at 9:50 AM, Michael Jinks mji...@uchicago.edu wrote: Thanks Aaron. Maybe this will be obvious when we get further into our testing, but how do you provide access to deployed hosts where the DHCP-assigned addresses are random? Are you using DynDNS? On Tue, Jun 26, 2012 at 09:36:52AM -0400, Aaron Peeler wrote: Set it to dynamic dhcp, this setting will work fine for either true dynamic dhcp or fixed dhcp assignments. The main differences from VCL's perspective: Dynamic dhcp setting - fetch the assigned address using ifconfig or ipconfig(depending on the provisioned OS) and update the public IP address in the computer table. Manual dhcp setting- return the address assigned in vcl database, this method assumes that the address is correctly defined in the vcl.computer table. This setting will likely go away since the dynamic dhcp option is doing the right thing in confirming an address got assigned to the machine. I would like to see the manual dhcp setting go away in the future, since it's not really doing anything. We have a mix here at NCSU, our campus networking group uses fixed dhcp on campus, in another off campus DC we use dynamic dhcp. We have it set to dynamic dhcp for all of our 8 management nodes. Aaron On Tue, Jun 26, 2012 at 9:19 AM, Michael Jinks mji...@uchicago.edu wrote: Hi Aaron. Ah, sure enough, it is set to Static. ?Silly me, when I first set this up I read that to mean don't try to set the public IP, leave it to us humans to configure. ...Okay, so how would we get that behvior? ?We'll want our deployed VM's to come up with predictable IP addresses so that customers can reach them, so dynamic DHCP isn't going to work. ?Our NOC runs DHCP on the public wire, and can't do static assignments of IP addresses due to limitations in their DHCP server. ?(In VCL's terms, what's the difference between dynamic and manual DHCP?) Are other sites using DynDNS, maybe? ?Does VCL have hooks for updating the DynDNS service when it deploys a machine? I think our only other option is going to be to deploy a DHCP server on the public-facing segment with lots of precautions to make sure it doesn't try to handle requests from anything other than VCL-deployed systems. ?Technically easy, organizationally challenging, so I'd like to avoid that if possible. On Tue, Jun 26, 2012 at 09:03:32AM -0400, Aaron Peeler wrote: 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
VCL: public/private IP discrepency?
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
Re: VCL: public/private IP discrepency?
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
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
