Bill McGonigle wrote:
On Jun 1, 2007, at 12:34, Michael DeHaan wrote:
I'm also starting to understand the wisdom of setting up using MAC
addresses, even under Xen. Are there 'best practices' for this? I just
made up a prefix (BF:CC in my case, so we can remember that my company
set it up) and for the remainder I used the IP address, in hex, human
order. If there's a better way that might sync up later with
virt-factory I'd be happy to change over.
I'll try to not be too confusing here as there are a lot of different
ways one could manage a lot of Xen machines running in a datacenter
environment.
Since you asked about virt-factory, currently virtfactory allocates Xen
MAC addresses in the reserved space starting with 00:16:3E from
00:16:3E:00:00:00 upwards, one at a time, using the last three digits.
This is a MAC address space reserved for Xen that will not clash with
other NICs. So, if dealing with cobbler system objects, keeping track of
the MACs might make sense. We will presumably have a way to register
existing virtual machines to the collective, so that whatever you name
them now won't cause a problem.
Should you not want to manage MAC addresses, you can just provision by
profile, and you'll get random MAC addresses from koan in the
aforementioned range. However, this means you'll have to use DHCP
(because you have no way to feed in static IP info with just the profile
being specified) or you will not know the hostname until after you are
done installing. For this reason, if you do this, you should at least
assign a specific virtual system name:
koan --virt --server=bootserver.example.com --profile=foo-xen-86_64
--virtname=testconfig7
So, in the above, you at least know that in "xm", "virsh", and
"virt-manager", you can refer to the system as testconfig7. But yes, if
you're in a DHCP environment, the hostname is TBD, and you can't do the
"--profile" trick for static IP configurations. Does this mean making
cobbler "system" objects for your virtual machines makes sense?
Yes, it's a very good idea for a datacenter. If you just need a few
virtual machines for developer use, it's not that critical.
So, about MAC addresses ... In Cobbler 0.4.9 (already pushed to the
upstream git repo, not yet released), you can name systems arbitrarily.
It is still nice to specify a MAC address versus taking a random one, so
that things like DHCP (and in turn, DNS) can be better controlled. You
will be able to do things like:
cobbler system add --name=fido --mac=00:16:3E:00:00:01 --ip=192.168.1.50
--hostname=fido.example.com
In Cobbler 0.4.8, the best you can do is: cobbler system add
--name=00:16:3E:00:00:01 --pxe-address=192.168.1.50, and doesn't offer
the --hostname
If using the dnsmasq features (cobbler defaults to 'isc', and even then
'manage_dhcp' must be enabled) in 0.49, that would ensure that the new
Xen machine both recieved
the designed IP and the desired hostname. This means you know a lot
about the virtual machine even before you provision it.
If you're using Cobbler to manage ISC, you can leave off the hostname,
as it will be ignored.
cobbler system add --name=fido --mac=00:16:3E:00:00:01 --ip=192.168.1.50
If you are using 0.4.8, syntax must be: cobbler system add
--name=00:16:3E:00:00:01 --pxe-address=192.168.1.50, which is a bit
confusing
If you're not letting Cobbler manage your DNS (this is fine), it still
makes sense to set the MAC in the Cobbler config, so that you can
manually at least pick an IP for that MAC address. This way you'll be
able to SSH into the machine later.
Alternatively, you can do things like set up a static IP configuration,
using the kickstart templating features. You would, in the kickstart
file, set template variables such as $ip and $hostname, and do something
like this...
cobbler system add --name=fido --ksmeta="ip=192.168.1.50
hostname=fido.example.com"
So, anywhere in your kickstart, you could have a variable "$ip" that
would be substituted automatically with the IP.
Since it's a good idea, I'm also going to make all of the variables used
when constructing the system object automatically available to the
kickstart templates. This way it will be easier to deal with cobbler
with static IP configurations and will require less usage of the
"--ksmeta" option to feed arbitrary variables into the kickstart.
Hopefully I didn't get too offtrack, this probably warrants a new Wiki
article "DHCP, Static IPs, & how to keep track of your machines".
In conclusion, I'd say that keeping track of MAC addresses for virtual
systems now is a very very good idea, as it will open up other options
later even if you don't need them now. Either that, or go the static
route, ignore the DHCP options, and investigate kickstart templating to
feed in those additional parameters. Both options are equally good.
Thanks,
-Bill
-----
Bill McGonigle, Owner Work: 603.667.4000
BFC Computing, LLC Home: 603.448.1668
bill@xxxxxxxxxxxxxxxx Cell: 603.252.2606
http://www.bfccomputing.com/ Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
