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> >> >> >> ? ?wrote: >> >> >> >> >> >> ? ? ?That's more or less what we're doing. ?Here are some details: >> >> >> ? ? ?The source VM I'm capturing from is not represented in DNS at all. >> >> >> ? ? ?On my management node in /etc/hosts I have: >> >> >> ? ? ? 10.50.84.15 ? ? vcl-linux-template-2-bak >> >> >> ? ? ? [4]128.135.192.15 ?vcl-linux-template-2 >> >> >> ? ? ?(The second line is for my reference; it shouldn't be used by >> >> >> ? ? ?anything >> >> >> ? ? ?as far as I know.) >> >> >> ? ? ?In dhcpd.conf I have: >> >> >> ? ? ? host vcl-linux-template-2-bak { >> >> >> ? ? ? ? ? ? option host-name "vcl-linux-template-2"; >> >> >> ? ? ? ? ? ? hardware ethernet 00:50:56:01:99:0f; >> >> >> ? ? ? ? ? ? fixed-address 10.50.84.15; >> >> >> ? ? ? ? ? ? filename "/tftpboot/pxelinux.0"; >> >> >> ? ? ? ? ? ? option dhcp-server-identifier 10.50.84.2; >> >> >> ? ? ? ? ? ? next-server 10.50.84.2; >> >> >> ? ? ? } >> >> >> ? ? ?In the VCL database, the IP address for this host is 10.50.84.15 >> >> >> and >> >> >> ? ? ?the >> >> >> ? ? ?hostname is "vcl-linux-template-2-bak". >> >> >> ? ? ?During capture, when prompted for the hostname or IP address of >> >> >> the >> >> >> ? ? ?image to capture, I enter the IP address. >> >> >> ? ? ?That all works fine for starting the capture. ?But for some >> >> >> reason, >> >> >> ? ? ?when >> >> >> ? ? ?the VM image is captured and then immediately redeployed, it comes >> >> >> ? ? ?up >> >> >> ? ? ?with its public-facing interface set to 10.50.84.15, and it >> >> >> appears >> >> >> ? ? ?that >> >> >> ? ? ?something in the capture process is rewriting the ifcfg-eth1 >> >> >> config >> >> >> ? ? ?file >> >> >> ? ? ?to match that address. >> >> >> ? ? ?That's why I tried changing the IP in the database to the public >> >> >> ? ? ?one, >> >> >> ? ? ?which led to the ssh failure. >> >> >> >> >> >> ? ?On Mon, Jun 25, 2012 at 03:51:19PM -0400, Mike Haudenschild wrote: >> >> >> ? ?> Hi Mike, >> >> >> ? ?> >> >> >> ? ?> I handle this by running DHCP on the private VCL network, >> >> >> assigning >> >> >> ? ?MAC addresses to specific VMs so as to make them predictable. Then >> >> >> add >> >> >> ? ?each hosts PRIVATE IP to the management node's /etc/hosts file. This >> >> >> ? ?will force the management node to resolve the compute name to the >> >> >> ? ?private IP, instead of the public IP (which is probably coming from >> >> >> ? ?your DNS server). >> >> >> ? ?> >> >> >> ? ?> Regards, >> >> >> ? ?> Mike >> >> >> ? ?> >> >> >> ? ?> Sent via iPhone >> >> >> ? ?> >> >> >> ? ?> On Jun 25, 2012, at 15:45, Michael Jinks <[5]mji...@uchicago.edu> >> >> >> ? ?wrote: >> >> >> ? ?> >> >> >> ? ?> > Hi List. ?Still trying to get a successful capture and deploy to >> >> >> ? ?run; >> >> >> ? ?> > here's my latest glitch. >> >> >> ? ?> > >> >> >> ? ?> > In the VCL web interface, under "Manage Computers" -> "Edit >> >> >> ? ?Computer >> >> >> ? ?> > Information", there's a single field for "IP address". ?I've >> >> >> been >> >> >> ? ?> > entering the private-side IP address for VM's I'm trying to >> >> >> ? ?capture. >> >> >> ? ?> > >> >> >> ? ?> > ...But, a few minutes ago I realized that VCL is using that >> >> >> field >> >> >> ? ?to >> >> >> ? ?> > rewrite my VM's public-facing address configuration during the >> >> >> ? ?capture >> >> >> ? ?> > process. ?Needless to say, that causes a failure when the >> >> >> captured >> >> >> ? ?VM >> >> >> ? ?> > boots. >> >> >> ? ?> > >> >> >> ? ?> > So, I tried filling the "IP Address" field with the public-side >> >> >> ? ?address, >> >> >> ? ?> > but that causes a failure when we try to capture the image, >> >> >> because >> >> >> ? ?vcld >> >> >> ? ?> > tries to ssh to that address, which is obviously wrong, as the >> >> >> VCL >> >> >> ? ?ssh >> >> >> ? ?> > key is trusted on the private-side sshd instance. >> >> >> ? ?> > >> >> >> ? ?> > What should I be doing instead? ?Is there any way to get the >> >> >> ? ?correct >> >> >> ? ?> > address set for the public and private interfaces? ?Do I have >> >> >> to do >> >> >> ? ?this >> >> >> ? ?> > by hand in the database? >> >> >> ? ?> > >> >> >> ? ?> > -- >> >> >> ? ?> > Michael Jinks :: [6]mji...@uchicago.edu >> >> >> ? ?> > University of Chicago IT Services >> >> >> >> >> >> ? ? ?-- >> >> >> ? ? ?Michael Jinks :: [7]mji...@uchicago.edu :: [8]773-469-9688 >> >> >> >> >> >> ? ?University of Chicago IT Services >> >> >> >> >> >> References >> >> >> >> >> >> ? ?1. mailto:m...@longsight.com >> >> >> ? ?2. http://markmail.org/message/t2ajnaew5qe4jxul >> >> >> ? ?3. mailto:mji...@uchicago.edu >> >> >> ? ?4. tel:128.135.192.15 >> >> >> ? ?5. mailto:mji...@uchicago.edu >> >> >> ? ?6. mailto:mji...@uchicago.edu >> >> >> ? ?7. mailto:mji...@uchicago.edu >> >> >> ? ?8. tel:773-469-9688 >> >> > >> >> > -- >> >> > Michael Jinks :: mji...@uchicago.edu :: 773-469-9688 >> >> > University of Chicago IT Services >> >> >> >> >> >> >> >> -- >> >> Aaron Peeler >> >> Program Manager >> >> Virtual Computing Lab >> >> NC State University >> >> >> >> All electronic mail messages in connection with State business which >> >> are sent to or received by this account are subject to the NC Public >> >> Records Law and may be disclosed to third parties. >> > >> > -- >> > Michael Jinks :: mji...@uchicago.edu :: 773-469-9688 >> > University of Chicago IT Services >> >> >> >> -- >> Aaron Peeler >> Program Manager >> Virtual Computing Lab >> NC State University >> >> All electronic mail messages in connection with State business which >> are sent to or received by this account are subject to the NC Public >> Records Law and may be disclosed to third parties. > > -- > Michael Jinks :: mji...@uchicago.edu :: 773-469-9688 > University of Chicago IT Services -- Aaron Peeler Program Manager Virtual Computing Lab NC State University All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.
