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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
