For reference to the source material (and proper credit) I used these as guides to getting this working: <a href="http://www.linuxdynasty.org/how-to-automate-the-install-of-vmware-tools-after-any-kernel-update.html">http://www.linuxdynasty.org/how-to-automate-the-install-of-vmware-tools-after-any-kernel-update.html</a> <a href="http://drcs.ca/blog/?p=181">http://drcs.ca/blog/?p=181</a> <div class="gmail_quote">2009/12/18 James Hogarth <<a href="mailto:james.hogarth@gmail.com">james.hogarth@gmail.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">After a little head scratching and hiccups I managed to get my vmware guests kickstarting and including the vmware tools install and config as part of the kickstart process... using the vmxnet driver. Testing in our environments has shown the vmxnet driver to be superior and we wanted to use it on our guests but of course since it isn't part of the kernel source the guests had to be built with e1000 emulated NICs and then changed over afterwards.... Seeing that there are probably others in the same situation I thought that popping the steps I took onto the mailing list would be good for others - and when I have to do it in 6 months for Centos 5.5 again (or 6) I can search this list for the instructions ;) This should work in any rpm based kickstartable distrobution but was tested on Centos 5.4 x86_64. First you will need a reference system with VMwareTools already installed onto in order to get the kernel module and check the PCI IDs your modules are. From the PXE or kickstart ISO you are using unpack your initrd to a work directory.... <pre><code>mkdir /tmp/work cd /tmp/work cp /mnt/dvd/images/pxeboot/initrd.img . mkdir initrd </code><code>cd initrd zcat ../initrd.img | cpio -id </code> </pre>On the reference PC check the PCI ID for your modules.... <pre><code> lspci | grep -i -E 'vmware.*ethernet|ethernet.*vmware'</code></pre> It will look something like: <pre><code> 00:11.0 Ethernet controller: VMware VMXNET Ethernet Controller (rev 10)</code> </pre> Next get the full vendor/product ID for the driver where the PCI ID is 00:11.0 in the example above. <pre><code> lspci -n | grep -i '15ad'</code></pre> Look for the line matching the PCI ID found above and make a note of the product ID... The example from my case is: <pre><code>lspci -n00:11.0 0200: 15ad:0720 (rev 10) | grep -i '15ad'</code></pre> Where the vendor ID can be seen as 15ad and the product ID to make a note of is above is 0720 Next we need to expand the modules cpio archive to add our vmware module to it. <pre><code>mkdir /tmp/work/modules cd /tmp/work/modules zcat ../initrd/modules/modules.cgz | cpio -id</code><code> cd /tmp/work/modules/2.6.*/x86_64 cp /lib/modules/`uname -r`/misc/vmxnet*.ko . chmod 744 vmxnet* </code> </pre>Depending on the version of VMwareToosl you have you may have separate vmxnet.o and vmxnet.ko modules in /lib/modules/`uname -r`/misc - and you may also jave vmxnet and vmxnet3 modules.... For the 2.6 kernel you will need the vmxnet*.ko modules. If your module is symlinked to the .o version (as in my case) make sure you grab the actual file ;) Next pack back up the modules cpio archive.... <pre><code>cd /tmp/work/modules find . | cpio -o -H crc | gzip -9 > /tmp/work/initrd/modules/modules.cgz </code></pre> Note that the type is crc here.... Next we need to tell our kernel/initrd about our new modules.... <pre><code>cd /tmp/work/initrd/modules vi pci.ids </code></pre> Look for the section with the vmware vendor ID of 15ad and add your ethernet modules to this... for reference here is my part of that file after the addition: <pre><code>15ad VMware 0405 SVGA II Adapter 0710 SVGA Adapter 0720 VMware VMXNET Ethernet Controller (rev 10) </code></pre> Note that you might need the vmxnet3 driver added too depending on your version of VMwareTools.... Next append to the initrd modules-info alias info.... <pre><code>vmxnet eth "VMware VMXNET Ethernet Controller (rev 10)" </code></pre> Remember to add a vmxnet3 section if required... On the reference system get the entries required for the modules.alias file.... <pre><code>grep vmxnet /lib/modules/2.6.18-164.6.1.el5/modules.alias alias pci:v000015ADd00000720sv*sd*bc*sc*i* vmxnet alias pci:v00001022d00002000sv*sd*bc*sc*i* vmxnet</code> </pre> Append these to the modules.alias file in /tmp/work/initrd/modules Next pack all this back up.... <pre><code>cd /tmp/work/initrd find . | cpio -o -H newc | gzip -9 > /tmp/work/initrd.img.vmxnet </code></pre> Copy this initrd.img file to your PXE tree or ISO or however you want to use this (renaming it if need be)... That's the hard work done and that will allow a kickstart of the system using the vmxnet network driver instead of the e1000 driver. But that is only good for the kickstart itself this next final bit is to allow the system to still have a network interface after the kickstart is over.... On the spacewalk server create a post script for your kickstart containing something like the following: <pre><code>/usr/bin/yum install -y --nogpgcheck VMwareTools sed -i -e '/^\#.*$/d' -e '/^HWADDR=.*$/d' /etc/sysconfig/network-scripts/ifcfg-eth0 echo "rkernel=`uname -r` if [ -e /etc/vmware-tools/not_configured ]; then echo "vmware-tools not configured for running kernel $rkernel" echo "running <a href="http://vmware-config-tools.pl" target="_blank">vmware-config-tools.pl</a>" /usr/bin/<a href="http://vmware-config-tools.pl" target="_blank">vmware-config-tools.pl</a> -d echo "vmware-tools now compiled for running kernel $rkernel" echo "restarting system" reboot fi" >> /etc/rc.local </code></pre> This assumes that the VMwareToosl rpm is somewhere in your channels. It removes any comments from the ifcfg-eth0 file and removes the HWADDR restriction so that the system doesn't rename it to ifcfg-eth0.bak or somesuch on changes to network interface - this was valid for Centos 5.4 YMMV.... The rc.local addition is important as <a href="http://vmware-tools-config.pl" target="_blank">vmware-tools-config.pl</a> detects module to install based on the running kernel - this is of course different in the kickstart. This will also allow a kernel upgrade and if need be the system will auto-configure on next boot. The reboot is there to ensure that any network services etc or any dependencies on network/vmware running during start up are met. Hope this is helpful to someone apart from me next distro update ;) James </blockquote></div>