(Probable) Success!
I was confused because I though my kickstart template had already been modified to do a console install. Once I switched from 'text' to 'console', I was able to see the console screen when I selected Open in virt-manager. It blew up with a kernel stack trace at kvm_main.c on the physical console of the qemu host OS, but at least I got to see it go through the motions.
I'll report actual success later (when I try this on another VM host).
Mykel
Mykel Alvis wrote:When you say "not started" what happens?
Oops. Didn't mean to reply off-list.
When I used the technique you described, I get the network alive and kicking but can't seem to get the VMs themselves started. I don't know if it's an issue with koan starting the vm or with my libvirtd dnsmasq config.
If using --nogfx with Xen, virt-manager won't have a screen.
I can't seem to see if the koan process is working correctly because the console output from virt-manager is a blank screen. When I use virsh to connect and try to reach the console, it hangs uninterruptedly. Do you (or anyone) know if this is because the network is still awry or if it is likely to be something else?
If not using it with Xen, virsh won't have a screen after Anaconda gets to a certain stage.
With KVM, you should always get just the virt-manager screen
(Unless you add console kernel parameters in Cobbler... which we need to do by default really).
Check your /var/log/koan for some log data that might be helpful.
Thanks again for all your help,
M
On Wed, Apr 22, 2009 at 09:57, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com>> wrote:
Mykel Alvis wrote:
Certainly.
::::::::::::::
/tmp/ifcfg-eth0
::::::::::::::
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
#BOOTPROTO=static
#IPADDR=10.151.37.241
#NETMASK=255.255.255.0
#DNS1=10.151.37.253
TYPE=Bridge
NM_MANAGED=No
::::::::::::::
/tmp/ifcfg-peth0
::::::::::::::
DEVICE=peth0
ONBOOT=yes
BRIDGE=eth0
HWADDR=00:1A:4B:45:65:69
NM_MANAGED=No
I think it's odd that I reboot the system with these configs
eth0 comes alive with a dhcp address, so ifconfig gives me a
listing with the eth0, lo and virbr0 devices, even though
there's an ifcfg-peth0. I don't know what order things get
initialized in, so I don't know if it's relevant.
A 'service network restart' gives me the same errors a I
previously posted.
This box is a somewhat minimal install, so if there's some
package that's essential for this to work I may not have
installed it.
Thanks!
Mykel
Hmm, that looks about right. I had some problems setting mine up
in F10 recently too, so I ended up just keeping eth0 as the actual
interface name and making a new file for the bridge... though I'm
not sure that will help you out.
Not sure if you meant to reply off-list, but here's mine:
[mdehaan@mdehaan cobbler]$ cat
/etc/sysconfig/network-scripts/ifcfg-eth0
# Intel Corporation 82567LM Gigabit Network Connection
NM_CONTROLLED=no
DEVICE=eth0
HWADDR=00:24:7e:10:f9:44
ONBOOT=yes
BRIDGE=london
[mdehaan@mdehaan cobbler]$ cat
/etc/sysconfig/network-scripts/ifcfg-eth1
# Intel Corporation 82567LM Gigabit Network Connection
DEVICE=london
NM_CONTROLLED=no
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
[mdehaan@mdehaan
The names of the files actually aren't that important, I named the
other one "eth1" just because "london" wasn't something the
service script could find. I was being silly in wanting to use
"london bridge" in my demos. I have Network Manager still on but
it's only managing my wireless card.
Apparenlty it's NM_CONTROLLED, not NM_MANAGED, which might play a
role. If you are running Fedora anyway, if it's not there, it's
not there.
--Michael