[et-mgmt-tools] "Could not communicate with" error

Michael DeHaan mdehaan at redhat.com
Fri Jun 1 21:49:53 UTC 2007

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 

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 

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= 
In Cobbler 0.4.8, the best you can do is: cobbler system add 
--name=00:16:3E:00:00:01 --pxe-address=, 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=
If you are using 0.4.8, syntax must be: cobbler system add 
--name=00:16:3E:00:00:01 --pxe-address=, which is a bit 

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= 

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

More information about the et-mgmt-tools mailing list