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 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 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 >> >> 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
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 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 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 detai
Re: VCL: public/private IP discrepency?
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 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 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-lin
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 n
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 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.
>
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
> > > >
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 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
>
Re: VCL image capture dies, "failed to prepare vmx file"
Hello Will, You will want to disable the auto-assigned mac addresses from ESX/ESXi. Part of the requirement is to run a dhcp server on the management node, at a minimum for the private management network. With that when you add new computers you define your mac addresses upfront in the add computers interface. When you add multiples you can add many at a time. Also the add computers tool, will generate dhcpd.conf entries for each node, so you can cut-n-paste to your dhcpd.conf file. Please see the Adding Virtual Machines section in this link for the detailed steps, https://cwiki.apache.org/VCL/vcl-221-further-steps-if-using-vmware.html Hope this helps. Aaron On Mon, Jun 25, 2012 at 9:13 AM, William Robinson wrote: > hi all, > > new to this list. i have started setting up vcl here and clemson university > and this thread has touched on one of the questions i had in trying to do > so. do i assign mac addresses based on what esxi generates? if not, how do > i map those correctly? thanks. > > will > > > > On 06/20/2012 10:16 AM, Josh Thompson wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael, >> >> Unfortunately, yes, in 2.2.1, you can only set MAC addresses via the add >> multiple computers page. You'll need to set them in the database. This >> is >> fixed in 2.3. >> >> Josh >> >> On Wednesday, June 20, 2012 9:12:52 AM Michael Jinks wrote: >>> >>> Thanks Aaron. >>> >>> Ah, yes. It didn't occur to me that we'd have to have MAC addresses >>> defined for a machine we're capturing *from*. I figured, well, it's >>> running and has IP addresses... >>> >>> At any rate, I'm looking around the UI and I can't find any page that >>> will let me enter a MAC address for an existing computer record. Is >>> this something I have to do by hand in the database? >>> >>> On Wed, Jun 20, 2012 at 08:46:40AM -0400, Aaron Peeler wrote: Hello Michael, One thing that stands out in the log is that your MAC addresses are not defined. computer eth0 MAC address: computer eth1 MAC address: This will be needed to correctly create the vmx file and thus get an address from the private dhcp server that is should be running on your management node. Secondly also make sure you have the dhcp server setup on your management node for the private network. Aaron On Tue, Jun 19, 2012 at 5:53 PM, Michael Jinks >> >> wrote: > > Hi, all. > > Trying to resurrect a thread I started on Friday, subject 'Image > capture > succeeds, then "fails"'. ?Mike Haudenschild helped me narrow down the > problem but so far I haven't been able to find a cause or a fix. > > I'm trying to capture my first Linux VM. ?Things go along okay through > the capture stage, but (thanks Mike) we fail when VCL tries to reserve > and deploy the new image. > > The critical message from the log appears to be: > > ?|17491|19:19|reload| WARNING > ?|17491|19:19|reload| 2012-06-19 > ?14:10:22|17491|19:19|reload|VMware.pm:load(395)|failed to prepare vmx > file for vcl-linux-template-2-bak on VM host: vcl0001 > ?|17491|19:19|reload| ( 0) VMware.pm, load (line: 395) > ?|17491|19:19|reload| (-1) new.pm, reload_image (line: 618) > ?|17491|19:19|reload| (-2) new.pm, process (line: 248) > ?|17491|19:19|reload| (-3) vcld, make_new_child (line: 568) > ?|17491|19:19|reload| (-4) vcld, main (line: 346) > > > Further down, I'll paste in a complete copy of the log mail I got from > this attempt. > > Our VM storage settings for this VM host are: > > ?Repository Path: ? ? ? /vmfs/volumes/nfs-vcl-templates > ?Data Store Path: ? ? ? /vmfs/volumes/T2_6045_dev_VCL_ds01 > ?VM Path: ? ? ? /vmfs/volumes/T2_6045_dev_VCL_ds01 > > (Note Data Store and VM are explicitly the same; we've also had VM Path > set to "(empty)" with no apparent difference in behavior.) > > Both of those paths are writable on the hypervisor. ?During capture, a > VM directory appears in both locations. ?In the directory under the > Repository path, we have many vmdk files, sizes ranging from 842M to > 1.5k, with names like: > > ?vmwarelinux-linuxtemplate2v1226-v0-s001.vmdk > ?vmwarelinux-linuxtemplate2v1226-v0-s002.vmdk > ?vmwarelinux-linuxtemplate2v1226-v0-s003.vmdk > ?[...] > ?vmwarelinux-linuxtemplate2v1226-v0-s016.vmdk > ?vmwarelinux-linuxtemplate2v1226-v0.vmdk > > My first guess is that we have one vmdk file for each attempted > capture, > and this is a series of xdiffs on the original? > > In the Data Store/VM directory, we have: > > ?# pwd > ?/vmfs/volumes/T2_6045_dev_VCL_ds01/vmwarelinux-linuxtemplate2v1226-v0 > ?# ls -lh > ?-rw--- ? ?1 root ?root ? 30.0G Jun 19 20:12 > vmwarelinux-linuxtemplate2v1226-v0-flat.vmdk ?-rw--- ? ?1 root > ?root ? ? 527 J
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 inte
