[Spacewalk-list] Kickstarting KVM nodes fail with "Unable to download the kickstart file"

[Ian Forde]

On Fri, 2010-07-02 at 17:35 -0400, Justin Sherrill wrote:
> On 7/2/10 4:30 PM, Ian Forde wrote: 
> > So I've got Spacewalk 1.0 setup on a box running CentOS 5.4.  My testing
> > KVM server is setup with CentOS 5.4 also.  I attempt to use Spacewalk's
> > provisioning facility to do a kickstart of a test KVM node.  And it's a
> > bear.  Right now, I've gotten the VM to boot and start the kickstart,
> > only to get stuck at the "Unable to download the kickstart file" message
> > within Anaconda.  Upon examining the VM using virt-manager, it appears
> > that *something* (Spacewalk? Cobbler? Cosmic Rays?) caused the VM to be
> > created without a network interface.
> > 
> > Some background info:  So far, I've run into the "koan instance has no
> > attribute 'virt_auto_boot'", which was resolved by downgrading koan from
> > 2.0.3.1 to 1.6.6 on the KVM host.
> > 
> > Then I realized that by default, the KVM host only has a NAT interface.
> > So I setup br0 on the box as follows:
> > 
> > Contents of /etc/sysconfig/network-scripts/ifcfg-eth0:
> > 	DEVICE=eth0
> > 	HWADDR=XX:XX:XX:XX:XX:XX
> > 	ONBOOT=yes
> > 	BRIDGE=br0
> > 	ETHTOOL_OPTS="autoneg off speed 100 duplex full"
> > 
> > Contents of /etc/sysconfig/network-scripts/ifcfg-br0:
> > 	DEVICE=br0
> > 	BOOTPROTO=static
> > 	ONBOOT=yes
> > 	IPADDR=X.X.X.X
> > 	NETMASK=255.255.255.0
> > 	GATEWAY=X.X.X.1
> > 	TYPE=Bridge
> > 	DELAY=0
> > 
> > I've also added the following to /etc/sysctl.conf (and subsequently run
> > 'sysctl -p':
> > 	net.bridge.bridge-nf-call-ip6tables = 0
> > 	net.bridge.bridge-nf-call-iptables = 0
> > 	net.bridge.bridge-nf-call-arptables = 0
> > 
> > In Spacewalk, the profile is defined to use the Virtual Bridge 'br0'.
> > 
> > Can anyone see what I've missed here?  I've managed to replicate this on
> > an entirely different set of servers in another location (different
> > Spacewalk, different KVM server), so whatever I'm missing, I've missed
> > it twice...
> > 
> > Thanks,
> > 
> > 	-I
> > 
> > _______________________________________________
> > Spacewalk-list mailing list
> > Spacewalk-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> >   
> Hi Ian,
> 
> We've fixed the virt_auto_boot bug, and it should be fixed in the next
> release.  
> 
> As for the networking interface issue.  It sounds like you are hitting
> this bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=608811
> 
> I'm not sure what introduced the issue, i'm guessing it was a change
> in cobbler, but I will need to do some test to verify.  In the
> meantime, you should be able to do something like this:
> 
> cobbler system edit --name=COBBLER_SYSTEM_NAME --virt-bridge=br0
> 
> Immediately after you provision in the UI, to add the virt bridge to
> your guest.  

Yep - looks like that did the trick.  Sort of.  I had to turn off osad
for this to work, and run rhn_check manually.  But I'd done that anyway
just so I could do 'rhn_check -vv' to see any other errors.  So now the
order of operations is:

1. Provision VM in Spacewalk UI
2. On the Spacewalk server cli run 'cobbler system edit...'
3. On the KVM host, run 'rhn_check'

and it seems to work.  (Now I have to go through and tweak the KS
profile, but that's on me...)

Here's the thing though... it looks like this solved that immediate
problem, but then the kickstart ran, I walked away, came back, and the
VM was powered off.  And now Spacewalk reports that the KS failed, even
though I was able to power on the VM.  And rhn_check is still stuck
displaying "install is still running" messages...  I'm hoping that
that's something in the KS profile that I can fix...

A couple of questions/observations though...
1. Having to turn off osad is a serious bummer in this regard...
2. The bug you referred me to is related to Xen, so it looks like it's
also applicable to KVM (at least in my case).  Regarding versions, I'm
using the same versions of spacewalk-base and spacewalk-oracle, but I'm
using cobbler-2.0.4-2 (from EPEL-testing).  
3. Since I've run into this issue on 2 separate instances of
Spacewalk/KVM, it looks like I'm in a good position to submit info on
this bug.  How can I help further in debugging it?  Let me know if you
need any debug info or logs...

Oh - and thanks for the quick turnaround!

	-I