Red Hat Bugzilla – Bug 836656
[RFE] Option to set MAC address while provisioning system profile from Satellite webui.
Last modified: 2012-11-01 12:17:37 EDT
+++ This bug was initially created as a clone of Bug #835791 +++
1. Proposed title of this feature request
Option to set MAC address while provisioning system profile from
3. What is the nature and description of the request?
Customer want to specify MAC address while provisioning system profile
from satellite webui on provisioning page.
4. Why does the customer need this? (List the business requirements here)
1) In our environment to perform a kickstart of a machine we must enter a
reservation into our windows AD DHCP infrastructure and configure the
DHCP reservation to boot from our satellite server. To perform this task
we must know the MAC address prior to performing the kickstart. At the
moment in satellite there is no way of knowing this.
2) There is a vanishingly small but finite probability that virtualised
guests built on different servers will select the same random MAC
address to use - this will increase with the number of VM host machines
and guests. By having a method of satellite controlling the MAC address
allocation then we can ensure that MAC addresses are unique across all
the VM hosts under control of the satellite servers. A MAC address
collision has subtle effects and is very difficult to troubleshoot,
anything that can prevent this happening is worthwhile.
3) Satellite gives the appearance of being able to build a fully virtualised
guest automatically but appears to be missing some things that would make
this work. Satellite should note the fact that a fully virtualised guest
is being built and automatically associate a kickstart profile with a MAC
address in cobbler (this ties in with satellite managing MAC addresses in
1&2 above). Doing this would mean that we can deploy a fully virtualised
guest in a similar manner to a para-virtualised guest instead of doing
what we do at the moment which is manually create the fully virtualised
guest using virt-install, since this is a manual process it is prone to
errors and requires more time and effort which is something that
satellite is supposed to alleviate.
Finally, not being able to build fully virtualised guests from within satellite automatically violates the principle of least astonishment. The interface gives all the appearances of being capable of performing the task and, indeed, satellite attempts to do what it is asked but, in reality, it will only function for a very narrow and specific set of circumstances which appears to be that you have a dhcp server set up that is configured to pxe boot any client from the satellite server and that cobbler is configured to have a default kickstart profile that will be applied. In an ideal world of homogenous red hat clients this would be fine but in a heterogenous network it is not acceptable to default install red hat linux on a machine attempting a pxe boot.
Committed to Spacewalk master: 8a0662ebdac23e411c8ba138fb0df489084eef92
Needed to add new column to initial table creation too (as opposed to just the upgrade script): 07e310a4bce0db22914fef7757c36f26853acb4d
No functional changes, removes MAC Address column from Kickstart Profile list.
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18