I assume you are talking about on the host here -- role env vars and RECIPE_MEMBERS should always be set correctly on the guests. On the host you will get None for the guest FQDNs. That's because Beaker doesn't actually know them in advance.
This changed in Beaker 0.10 for bug 655009. Previously Beaker did know the FQDNs in advance, and they were set in RECIPE_MEMBERS and the role env vars. The problem was if the host was on a different VLAN than the allocated guest address it would fail. That was the original point of bug 655009. So Beaker no longer allocates the guest addresses in advance.

The host can fetch the guest FQDNs from Beaker, but the API is not very nice and it doesn't go through beaker-proxy, so consider this a temporary workaround only. Python script pasted below. Bear in mind this only works once the guests have finished installing and have checked in to the Beaker server -- before that, Beaker doesn't know what their FQDNs will be.
Ultimately we need some new multi-host synchronisation mechanisms for guest recipes, which will allow the host to find its guests and vice versa.
----
#!/usr/bin/python
import os
import xmlrpclib
import xml.dom.minidom
s = xmlrpclib.ServerProxy('%sRPC2' % os.environ['BEAKER'])
recipe_xml = s.recipes.to_xml(os.environ['RECIPEID'])
doc = xml.dom.minidom.parseString(recipe_xml)
guests = []
for recipe in doc.getElementsByTagName('recipe'):
if recipe.getAttribute('id') == os.environ['RECIPEID']:
for guestrecipe in doc.getElementsByTagName('guestrecipe'):
guests.append(guestrecipe.getAttribute('system'))
print ' '.join(guests)