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

[Michael DeHaan]

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.
>
> Thanks,
>
>  - Adam.
> ------------------------------------------------------------------------
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools