Red Hat Bugzilla – Bug 768070
RFE: Virtualized guest provisioning and static IP
Last modified: 2014-12-04 11:46:27 EST
Description of problem:
I have some virtualization hosts managed by Spacewalk and trying to create VM provisioning with a VM static IP.
Instead the RH Satellite Deployement guide section 6.8.3, in the host page "Virtualization => Provisioning => Advanced Configuration", I can only
choose DHCP in Network Connection section ("Use DHCP from interface XXX" or "DHCP using first available interface").
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a kickstart profile with static IP configuration
2. on virtualization host, go to "Virtualization => Provisioning"
3. choose the static IP kickstart profile
4. launch the kickstart installation or click on "Advanced Configuration" before launching it
5. instead the kickstart file, the final VM is booting with DHCP interface
eth0 configured in DHCP
eth0 configured with static IP
I can force a static IP for the installation boot by entering following parameters in "kernel options" of the kickstart profile:
ip=WWW.WWW.WWW.WWW netmask=XXX.XXX.XXX.XXX dns=YYY.YYY.YYY.YYY gateway=ZZZ.ZZZ.ZZZ.ZZZ
... but after rebooting the final VM is booting in DHCP instead static IP as defined in kickstart file (Kickstart Details => Advanced Options => Network).
--noipv6 --bootproto=static --ip=X.X.X.X --netmask=Y.Y.Y.Y --gateway=Z.Z.Z.Z --nameserver=W.W.W.W --hostname=xxx.yyy.com
If I use the "virt-install" command on the hypervisor to install the VM, the VM use this parameter to configure its interface with static IP. But with the Spacewalk interface the interface is configured in DHCP :(
If I install the VM within Spacewalk, I can find in the resulting file "/root/anaconda.ks" the following two sections of code who are not present when I use the "virt-install" manual command:
# Start of code to match cobbler system interfaces to physical interfaces by their mac addresses # Start eth0 # Configuring eth0 (00:16:3e:45:6d:60) if ifconfig -a | grep -i 00:16:3e:45:6d:60 then
IFNAME=$(ifconfig -a | grep -i '00:16:3e:45:6d:60' | cut -d " " -f 1)
echo "network --device=$IFNAME --bootproto=dhcp" >> /tmp/pre_install_network_config fi # End pre_install_network_config generated code ...
cp /etc/sysconfig/network-scripts/ifcfg-lo /etc/sysconfig/network-scripts/cobbler/
# Start configuration for eth0
IFNAME=$(ifconfig -a | grep -i '00:16:3E:45:6D:60' | cut -d ' ' -f 1) if [ -f "/etc/modprobe.conf" ] && [ $IFNAME ]; then
grep $IFNAME /etc/modprobe.conf | sed "s/$IFNAME/eth0/" >> /etc/modprobe.conf.cobbler
grep -v $IFNAME /etc/modprobe.conf >> /etc/modprobe.conf.new
rm -f /etc/modprobe.conf
mv /etc/modprobe.conf.new /etc/modprobe.conf fi echo "DEVICE=eth0" > /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0
echo "HWADDR=00:16:3E:45:6D:60" >> /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0
echo "ONBOOT=yes" >> /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0
echo "BOOTPROTO=dhcp" >> /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0
# End configuration for eth0
rm -f /etc/sysconfig/network-scripts/ifcfg-*
mv /etc/sysconfig/network-scripts/cobbler/* /etc/sysconfig/network-scripts/ rm -r /etc/sysconfig/network-scripts/cobbler
if [ -f "/etc/modprobe.conf" ]; then
cat /etc/modprobe.conf.cobbler >> /etc/modprobe.conf rm -f /etc/modprobe.conf.cobbler fi ...
It seems Cobbler overwrite my own IP configuration with a DHCP config.
The problem described in this bug report is known not to work correctly.
Spacewalk can do reprovisioning of a guest / physical hw using static
address, but it cannot provision a new guest with a static IP address.
You may add the correct anaconda command line arguments for static
provisioning (ip= netmask= dns= gateway=) and have the same done in
the kickstart profile used, but all these settings will be overwritten
by post_install_network_config cobbler snippet (as described in the initial
1. when creating a new guest we also create a corresponding cobbler profile
(even before the new installation begins)
2. The networking part of this cobbler profile never says static
3. In the %post section, the cobbler snippet mentioned above overwrites
correct network settings created by anaconda.
This problem is fixable, though I see this more to be an RFE rather than
(In reply to comment #1)
> This problem is fixable, though I see this more to be an RFE rather than
> a bug.
I don't think we can see this more to be an RFE, it is not "logical" spacewalk can do a reprovisioning of an existing guest but not a new one. When creating the kickstart file, a simple test can check if a static IP address has been defined and don't insert the %post cobbler snippet.