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.
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?
Thanks again for all your help, M
On Wed, Apr 22, 2009 at 09:57, Michael DeHaan 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
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
(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.commailto: 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
Sorry, didn't answer your questions in the previous message:
On Wed, Apr 22, 2009 at 13:48, Michael DeHaan mdehaan@redhat.com wrote:
Mykel Alvis wrote:
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?
Nothing. An "Open" in virt-manager appears as a blank black screen with no activity.
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
I always have in the past, but not this time.
(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.
Everything appeared to be normal (as far as I can tell) int he koan log. It informed me of the new machine being created, etc. Nothing erroneous.
cobbler@lists.fedorahosted.org