[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [et-mgmt-tools] Question regarding api.sync and the necessity of using MAC addresses as system.name in dhcp templating

IRC discussions today (thanks, Adam) made me realize I hadn't replied to this yet...

Adam Rosenwald wrote:
Is the requirement of using MAC addresses as system.name <http://system.name> as a prerequisite for DHCP templating necessary? I'm trying to understand the reason for the decision to enforce this policy. Hardware addresses should all be considered 'unique', so the problem lies with duplicate virtual MAC addresses (at least those attached to the systems provisioned with cobbler), no? If this is the reason, I would recommend a resolution as follows:

It's a weird requirement that comes from needing to support PXE in a couple of different ways. "Normal" systems can PXE by IP or MAC address, Itanium boxes only do IP. Therefore to support the PXE piece (which is really not relevant for virt) cobbler system objects need to be named after an IP, MAC, or resolvable hostname (that maps to an IP). Now, this may seem overly complex, but fortunately it doesn't have to be. When provisioning virt, it's sufficient to just create a cobbler _profile_ and not create the cobbler system record. The system records are only really needed when a particular piece of hardware needs a PXE record (virt doesn't do PXE in our case), or when it requires specific kernel parameters for it's hardware.

So you can just do:

koan --virt --profile=nameofprofile --server=bootserver.example.com

And you'll get a random MAC address.

If you have a requirement to explicitly set the MAC address, however, you can provision using the system object.

koan --virt --system=AA:BB:CC:DD:EE:FF  --server=bootserver.example.com

And the provisioned system will get "AA:BB:CC:DD:EE:FF".

By default make virtual MAC addresses randomly assigned. The script from http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Virtualization-en-US/ch19s21.html <http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Virtualization-en-US/ch19s21.html> does the job. Maintain an array of cobbler-provisioned MACs and check against the array before assigning a new, random MAC address to a provisioned virtual system. The default behavior can be overridden by the use of another (optional) command line argument to 'cobbler system (add|edit)'. This frees up system.name <http://system.name> to be any valid hostname and mirrors the behavior of 'xm create'. A more robust solution would be to have a /var/lib/cobbler/macs file (bound to the array) which would allow users to manually provision virtual servers and add the noncobbler-provisioned MACs to the list if they so desired.
Something like this (making sure there is a record of systems that cobbler provisioned systems in the cobbler database) is an interesting idea. Currently we're doing things like that in higher level software (http://virt-factory.et.redhat.com) and cobbler is in charge of getting the bits out there, but not keeping track of where they live. There's a lot of different approaches about how that might work, so I've taken the approach to /not/ keep inventory and allow people to deploy by more flexible ways (PXE menus, koan with --profile) in many cases, without requiring the system record. Still, if a higher level app (say a Web app using the cobbler API) wants to create a database and have cobbler system records for every virtual machine, it can do so... in fact, that's what virt-factory does...

If there is another reason for depriving dhcp templating (and tied-in arguments; e.g. xen domU names) of anything other than MAC addresses, I would be curious to understand why.
Yeah, the above legacy PXE requirements are pretty much why the Cobbler system object works like it does.

However if you want to name virtual machines after something other than their MAC's (something descriptive), you can do so...

koan --virt --profile=... --server=... --virt-name=insertnamehere

and the virtual machine will appear as something more logical than just the MAC address.


 - Adam.

et-mgmt-tools mailing list
et-mgmt-tools redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]