Bug 768070 - RFE: Virtualized guest provisioning and static IP
Summary: RFE: Virtualized guest provisioning and static IP
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 1.5
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: spacewalk-rfe
TreeView+ depends on / blocked
 
Reported: 2011-12-15 17:06 UTC by npradelles
Modified: 2020-03-23 12:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-23 12:22:16 UTC
Embargoed:


Attachments (Terms of Use)

Description npradelles 2011-12-15 17:06:19 UTC
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):


How reproducible:


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

  
Actual results:
eth0 configured in DHCP

Expected results:
eth0 configured with static IP

Additional info:

I can force a static IP for the installation boot by entering following parameters in "kernel options" of the kickstart profile:
-----8<-----
ip=WWW.WWW.WWW.WWW netmask=XXX.XXX.XXX.XXX dns=YYY.YYY.YYY.YYY gateway=ZZZ.ZZZ.ZZZ.ZZZ
-----8<-----

... but after rebooting the final VM is booting in DHCP instead static IP as defined in kickstart file (Kickstart Details => Advanced Options => Network).
-----8<-----
--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
-----8<-----


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:
-----8<-----
%pre
...
# 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 ...

%post
...
mkdir /etc/sysconfig/network-scripts/cobbler
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 ...
-----8<-----

It seems Cobbler overwrite my own IP configuration with a DHCP config.

Comment 1 Milan Zázrivec 2012-01-02 16:55:34 UTC
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
comment), because:

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
a bug.

Comment 2 npradelles 2012-02-22 15:29:14 UTC
(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.

Comment 5 Michael Mráka 2020-03-23 12:22:16 UTC
Spacewalk project as an upstream for Red Hat Satellite 5 product is going to be End Of Life on May 31 2020.

Spacewalk 2.10 has been released as the last release of this project.
https://github.com/spacewalkproject/spacewalk/wiki/ReleaseNotes210

Any new feature will not be included therefore closing remaining RFEs to set expectations properly.


Note You need to log in before you can comment on or make changes to this bug.