ESX Deployment Appliance (EDA) is a small and easy to use appliance
that makes deploying ESX servers a breeze. It has a very intuitive
web-interface that can configure and deploy dozens of ESX servers in
minutes. It has a script-builder that will allow any admin to create
%post-scripts that will do most anything one needs to get the ESX hosts
up and running! Even if deploying with RDP/Altiris or the UDA, this
script-builder can help setting those up very quickly.
I am on holdiay from 30-08-2008 until 15-09-2008 and will not have e-mail access during this period.
This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
i know, i should get a quick startup guide online soon. since all the requested features are built in more or less, i'll write that soon.
to get started, check out http://www.vmware.com/appliances/directory/1216. it tells you the rootpwd is root.
also, if you don't see an IP address in the console window it's probably due to the appliance finding a eth1 instead of a eth0. you might want to remove /etc/udev/rules.d/70-persistent-net.rules and reboot. i'll do that in the next release. still haven't found the setting where i can tell udev not to create a network device bound to a MAC address. annoying.
And since it was a beautiful day today to relax in the sun with a beer and a laptop, i finished a new version with some bugfixes and more features. the harddisk was rebuilt so it's less than half the size of the previous version and the interface got some work.
check out http://www.vmware.com/appliances/directory/1216 for the changes and a link to the download and quick setupguide page.
Great work with 0.81, this is coming along nicely. I am still having trouble getting this to work at all though.
I have the appliance running in my ESX environment. Its running on on a VLAN, the same as the service consoles use. I have my PXE nic set to use the same VLAN and I am getting a DHCP address when PXE booting and the menu screen from the EDA. However it still fails when trying to send the KS script over. From the ESX host I am trying to install I get the following log:
reverse name lookup failed
ks location: http://22.214.171.124/ks/ks.php?hostname=cphgvs04
transferring http://126.96.36.199/./ks/ks.php?hostname=cphgvs04 to a fd
failed to retrieve http://188.8.131.52///ks/ks.php?hostname=cphgvs04
trying to mount device hda
trying to mount device scd0
When tailing daemon.log on the EDA I get the following:
deployer dhcpd: DHCPDISCOVER from 00:1e:4f:2b:85:f0 via eth0
deployer dhcpd: DHCPOFFER on 184.108.40.206 to 00:1e:4f:2b:85:f0 via eth0
deployer dhcpd: DHCPREQUEST for 220.127.116.11 (18.104.22.168) from 00:1e:4f:2b:85:f0 via eth0
deployer dhcpd: DHCPACK on 22.214.171.124 to 00:1e:4f:2b:85:f0 via eth0
deployer in.tftpd: tftp: client does not accept options
I have tried this in a non VLAN environment and the result is exactly the same. Please help ?:|
some servers support PXE boot to be tagged.. but the 2nd stage of the ESX installer doesn't support vlans at all. you should untag all installer traffic at the physical switch. you can use trunkports if you set the native vlan to the installer traffic vlan.
the dhcp part of the daemon.log is not part of the second installer fase. the last entry reports a tftp message which is only used during the first pxe boot. not sure what's going on. you sure you dont have a second dhcp server in that segment?
As I said I tried the same setup on a closed switch setup with no VLANS with the same result. There are no other DHCP servers on the network. Strange this. Unfortunately this is on a customer site so only able to access it once a week.
what kind of host do you run the appliance on? can you describe your setup in a little more detail? i think we need more information to get an idea of what's going wrong.
Sorry for butting in here, but I am having the exact same problem, where it looks like the kickstart file is not kicking off. What logs can I get to help sort this out? Is there some data on the EDA server that would help? or would it be on the ESX host. I have 24/7 access to several servers that I'm having this problem on. The servers are on their own vlan, there's no other DHCP servers. and the ESX hosts to be installed and the vm are on the same vlan.
I am using the latest build of ESX 3.5 update 2
As an FYI- when I try to do the HTTP install to the EDA server it puts extra slashes in ie. - it gets stuck on this (probably the 1st file. I tried every which way of putting the path in and it always puts an extra slash in. - which may be a bug in the ESX build, but it may be a reason why the kickstart and other things aren't working correctly. I'm an avid linux user but I haven't had the chance to work with PXE boots before. The main reasons I've seen problems like this are when the linux build is a little screwed up. Let me know what you think.And if there's any info/logs I can get to help sort this out.
this is always a networking issue and it's actually not pxe, nor the appliance or apache, nor esx's fault. it's a redhat anaconda error that's been around for ages. most common cause in VI environments is a problem with VLAN's. pxe doesn't understand vlan's (although some vendors make it so it does) but expecially the second stage doesn't have a clue. so you in a VLAN env. you need to have native vlan's on the physical switches.
but that's not the case here. even in a flat env. the problem occurs. if you google for the error, it's all redhat and fedora message that mention all sorts of networking issues like arp, link, switch handshakes, stp, and what not. i have seen this problem resolved by using a simple hub between the pxe host and the switches where the installees were on. so there's plenty of stuff to check to get this resolved.
but thinking about this, i think it could also be a dns issue, or perhaps a missing gateway. if you have a totally closed environment, try putting the appliance's ip address as the gateway in dhcp. and while you're at it, set the nameserver to the appliance ip too. my guess is that just adding an ip address that responds for those services might help. i could add a dns server to the appliance but i think i'd rather not since that's a bit out of scope of what it's supposed to do. let me know if this helps..
I figured out the problem on my setup, and at this point I'm shelving EDA, sorry. It's not the appliance (it's actually great)
It's because of the networking issues, basically I have several c7000's each which have etherchannel trunks to them, which are passed to the blades. The blades will pxe boot to a vlan 80 which get's them to boot off of EDA, but then on "stage 2" which is the redhat install, I haven't figured out how to get it to connect to VLAN 80 to get access to the image, and kickstart files. I have a feeling this is what you were talking about Brugh. So unless there's a way to get that to work, I doubt I'll be using anything that uses a PXE boot. I can't change the networking on the c7000 as it get's complicated and adds time the idea here is to limit the time spent on doing this stuff.
It would be handy if the appliance would make a iso file you could download/burn and use as well. For when you have a machine in a secured environment or like me have problems with the network.
we use a setup like you describe in almost all our client environments. and eda works perfect on those there's one thing you have to do to get this to work and that's setting the native vlan on the trunkports to 80. this is best practice too and you should try to confince your network admins to change that. almost all switches support it and you can set this per port so you'll only have to do it for the esx servers. it's either that or reserve a hostport for the deployment. or you could patch one port into a hub and plug it into a trunkport after deployment.
but if you can't change network settings, your pxe deployments will fail. not just for eda but for all other similar systems too (like uda, rdp or altiris).
you can still use eda for creating a kickstart script, put it on a floppy (does anybody still have those things?) and use bouke's script to create a CD that strips the HBA drivers (). next boot the cd and add 'ks=floppy' or even 'ks=http://appliace.ip/ks/ks.php?hostname=esx01'. (ofcourse this works best with ilo or something similar).
ps; eda's next version will have an even more amenable scriptbuilder that's going to make creating scripts even more easy than it already was
I finally got the KS file to pass on to the esx server. took the switch which is supposed to be blank out of the equation and used a crossover cable between EDA and ESX host. Have to have a look at that switch, although no VLANs are configured there has to be something else. Can STP affect this?
looking forward to the script builder.
is there anyway of slipstreaming the KS file into the CD ?
a ks file is specific for each indivitual esx host. if you put it on a cd (which is probably possible somehow), you'd end up with a personal cd for each host. that's not something you'd normally want.
stp is a layer 2 protocol and should have nothting to do with ip traffic in that sence. what system does your eda run on? can you put it on another esx host and see what happens?
EDA runs as a vm on a poweredge 2950 running ESXi embedded. Have tried it on an R900 running installed 3.5 with same result. It has to be something in the switch though as it works fine when using the crossover cable and no switch.
Really nice appliance the EDA. Much easier to use than UDA, good work.
As an FYI
On Leo's Rambling blog () he found a neat way to have one kickstart file used for multiple servers, by using the serial# of the server which he gets from dmidecode command which is part of the ESX install. The other thought is to use a mac address as the distinguisher to configure each server. As an fyi, I am getting the network guys to set the default vlan for me, were going to make the changes later today and then test before we do it to all of our c7000 chassis.