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
