Skip navigation.

Frits Hoogland

Syndicate content
Linux, oracle and other technical stuff...
Updated: 6 years 19 weeks ago

PXE boot in VMWare Fusion using host-only adapter

Thu, 2009-12-17 04:48

Recently I’ve done some investigation on how to PXE-boot a system and do automatic installation. To get familiar with the techniques involved, and the software, I decided to try it on my laptop on a VM in VMWare Fusion (yes, it’s on a MAC).

How does PXE-boot work? Put really simple: if PXE-booting is used (it’s in the boot-list in the BIOS of most physical systems, and also the VMWare VM BIOS), it broadcasts it wants to use PXE on the network. A DCHP server can be configured to honour this request and send a PXE image to the machine.

Using the PXE image you can do all kinds of cool stuff, like start an attended or an unintended installation. Yes! This lets you install a linux system without using physical CD’s/DVD and going to the machine. Or even install a linux system without any involvement at all (!!!!), you just need to configure some things in advance.

Back to the MAC. This didn’t work using the host-ony adapter.

Host only adapters are setup using DHCP
This means VMWare setups a DHCP server, and you can use that by selecting the ‘host only’ adapter in the VM settings, and need to set it to DHCP in your VM.

This means that in order to setup PXE booting, we need to alter the VMWare Fusion DHCP Host Only DHCP server.

Where is the host-only vmware fusion dhcp server configuration located?
/Library/Application Support/VMware Fusion/vmnet1/dhcpd.conf

What do we need to add?
We need to add two things:
next-server: the ‘next-server’ directive needs to be pointed to the tftp server serving the PXE image.
filename: the ‘filename’ directive needs to be pointed to the PXE image file.

This is how it looks in my case:

# Configuration file for ISC 2.0b6pl1 vmnet-dhcpd operating on vmnet1.
# This file was automatically generated by the VMware configuration program.
# If you modify it, it will be backed up the next time you run the
# configuration program.
# We set domain-name-servers to make some DHCP clients happy
# (dhclient as configued in SuSE, TurboLinux, etc.).
# We also supply a domain name to make pump (Red Hat 6.x) happy.
allow unknown-clients;
default-lease-time 1800; # 30 minutes
max-lease-time 7200; # 2 hours

subnet netmask {
filename “pxelinux.0″;
option broadcast-address;
option domain-name-servers;
option domain-name “localdomain”;

Do not forget the ‘;’ which is needed after every line!

Do you crash your database on machine shutdown?

Thu, 2009-11-05 09:49

Most DBA’s would say ‘NO’ without hesitation. I dare you to take another look.

What is this blog about?
This blog is about DBA’s who run databases on linux. Linux sysadmins are target audience too; this blog is about the stop/start system on linux, and to be more precise: about the specific implementation of the stop/start system on redhat and it’s derivatives (Oracle’s enterprise linux for example, but also centos)

What about it?
The redhat stop/start system looks and feels like the traditional unix system V stop/start system found on most unixes. Correct usage of the redhat stop/start system is in fact quite different from that.

The traditional unix system V stop/start uses an executable script in the init.d directory (often /etc/init.d or /etc/rc.d/init.d) and uses a symbolic link in the runlevel directories (rc1.d, rc2.d, rc3.d, etc.) from the script in init.d, but prefixing the name it with ‘S’ (for start) or ‘K’ (for kill, thus stop) and a two digit number to indicate the order for starting or stopping.

The redhat stop/start system works with an executable script in the init.d directory (/etc/rc.d/init.d). The correct way to enable stop/start is using the chkconfig command:
chkconfig --add yourscript
This command check if the script yourscript is present in /etc/rc.d/init.d, then reads a line looking like this in the stop/start script:
#chkconfig: 2345 80 05
This tells chkconfig that the script should run in runlevels 2,3,4 and 5 with order number 80 and stopped (killed) with order number 05.
To check if chkconfig did understand your script, use:
chkconfig --list
Further reading about chkconfig:
man chkconfig

Alright, but what about crashing the database?
A lesser known fact is that the redhat stop/start system uses a file with the same name as the stop/start script in /var/lock/subsys to determine if the script is already started (so it doesn’t get started if it’s already started in a previous runlevel) and needs to be created in the start part, but more importantly it determines if the script needs to execute the stop procedure by checking the existence of this file in /var/lock/subsys. As part of the stop procedure the file needs to be removed, so the stop procedure isn’t run again in another runlevel.

In many custom made scripts this file doesn’t get created in /var/lock/subsys in the start procedure, so the stop procedure actually is never executed, because the script is already stopped from the perspective of the stop/start system. This typically means that the oracle stop/start script does a perfect job starting the database, but actually never stops the database, which means that during a shutdown or a reboot, the database actually crashes.

Sadly, I see very much scripts forgetting this (even ones from respectable sources, like redhat; see: Redhat summit beginner’s guide to running oracle on RHEL, for example, there are much more). Check your stop/start script today!