(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


On Wed, Apr 22, 2009 at 13:48, Michael DeHaan <mdehaan@redhat.com> wrote:
Mykel Alvis wrote:
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.

When you say "not started" what happens?



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 using --nogfx with Xen, virt-manager won't have a screen.  
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