(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 <[email protected]> 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 <[email protected]<mailto:
>> [email protected]>> 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:
>>
>>    [mdeh...@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
>>
>>    [mdeh...@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
>>    [mdeh...@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
>>
>>
>>
>>
>>
>>
>>
>
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler

Reply via email to