Fixing Slow Fedora PXE installations under KVM

I have been doing a lot of work with KVM, and bumped into an odd issue when PXE booting a Fedora 10 KVM guest. The installer (anaconda) would progress to the point where it would try to locate and configure the network interface, but would spit out the following error and wait for operator input:

                      +--------+ Network Error +---------+
                      |                                  |
                      | There was an error configuring   |
                      | your network interface.          |                      
                      |                                  |                      
                      |            +-------+             |                      
                      |            | Retry |             |                      
                      |            +-------+             |                      
                      |                                  |
                      |                                  |

After doing a bit of profiling, I noticed that the guest was having issues initializing the Realtek interface (this is the default interface type presented to KVM guests by QEMU). To see if a different interface type cured my problems, I changed the NIC model to an e1000 by adding the “model” tag to the KVM guest XML file:

<interface type='bridge'>
   <mac address='54:52:00:53:20:02'/>
   <source bridge='br0'/>
      <target dev='vnet2'/>
      <model type='e1000'/>

Once I made this simple change, the PXE install worked flawlessly. This was a fun problem to debug, and I learned a TON about QEMU, Anaconda, libvirt and several Linux profiling tools in the process. Viva la problem resolution!

Zoning Brocade switches: Creating configurations

I’ve previously talked about creating Brocade aliases and zones, and wanted to discuss zone configurations in this post. Brocade zone configurations allow you to group one or more zones into an administrative unit, which you can then apply to a switch. Brocade has a number of commands that can be used to manage configurations, and they start with the string “cfg”:

cfgadd – Add a member to the configuration
cfgcopy – Copy a zone configuration
cfgcreate – Create a zone configuration
cfgdelete – Delete a zone configuration
cfgremove – Remove a member from a zone configuration
cfgrename – Rename a zone configuration
cfgshow – Print zone configuration

To create a new configuration, you can run the cfgcreate command with the name of the configuration to create, and an initial zone to place in the configuration:

Fabric1Switch1:admin>cfgcreate “SANFabricOne”, “CentOSNode1Zone1”

Once the configuration is created, you can add additional zones using the cfgadd command:

Fabric1Switch1:admin> cfgadd “SANFabricOne”, “CentOSNode1Zone2”

To ensure that your changes persistent through switch reboots, you can run cfgsave to write the configuration to flash memory:

Fabric1Switch1:admin> cfgsave

Starting the Commit operation...
0x102572c0 (tRcs): May  8 08:51:37
    INFO ZONE-MSGSAVE, 4, cfgSave completes successfully.

cfgSave successfully completed

To view a configuration, you can run the cfgshow command:

Fabric1Switch1:admin> cfgshow

Defined configuration:
 cfg:	SANFabricOne	
		CentOSNode1Zone1; CentOSNode1Zone2; CentOSNode2Zone1; 
 zone:	CentOSNode1Zone1	
		CentOSNode1Port1; NevadaPort1
 zone:	CentOSNode1Zone2	
		CentOSNode1Port2; NevadaPort2
 zone:	CentOSNode2Zone1	
		NevadaPort1; CentosNode2Port1
 zone:	CentOSNode2Zone2	
		NevadaPort2; CentosNode2Port2
 alias:	CentOSNode1Port1	
 alias:	CentOSNode1Port2	
 alias:	CentosNode2Port1	
 alias:	CentosNode2Port2	
 alias:	NevadaPort1	
 alias:	NevadaPort2	

Effective configuration:
 cfg:	SANFabricOne	
 zone:	CentOSNode1Zone1	
 zone:	CentOSNode1Zone2	
 zone:	CentOSNode2Zone1	
 zone:	CentOSNode2Zone2	

Now you may notice in the output that there is a defined and effective configuration. The effective configuration contains the configuration that is currently running on the switch, and the defined configuration contains the configuration that is saved in flash. To make the configuration in flash effective, the cfgenable command needs to be run (this should be run after you make alias/switch/configuration changes and issue a cfgsave):

Fabric1Switch1:admin> cfgenable “SANFabricOne”
Starting the Commit operation…
0x1024f980 (tRcs): Apr 29 20:44:39
INFO ZONE-MSGSAVE, 4, cfgSave completes successfully.

cfgEnable successfully completed

Once the cfgenable runs, the effective configuration will be updated to match the configuration you have defined and saved. This completes this part of the Brocade series, and the final installation will cover switch backups and putting all the pieces together.

The Fedora 10 qemu-kvm binary doesn’t support the -curses option

I have been playing with the serial console capabilities that are part of qemu, and noticed the following error when I ran qemu-kvm with the “-curses” option on a Fedora 10 host:

$ qemu-kvm -curses
qemu-kvm: invalid option — ‘-curses’

The manual page indicates this should be a valid option:

     Normally, QEMU uses SDL to display the VGA output.  With this option, QEMU can
     display the VGA output when in text mode using a curses/ncurses interface.
     Nothing is displayed in graphical mode.

But closer inspection of the qemu-kvm binary proves otherwise:

$ qemu-kvm -help | grep curses

$ ldd /usr/bin/qemu-kvm | grep curses

I filed Fedora bug 504226 to get this option added.

Too many option ROMS bug

I created a new KVM host last night, and was greeted with the error “Too many option ROMS” during initialization:

$ /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name kvmnode1 -boot n -drive file=/bits/vms/kvmnode1,if=ide,index=0,boot=on -net nic,macaddr=54:52:00:53:20:00 -net tap,script=/bits/bin/qemu-ifup -serial pty -monitor pty
Setting the tunnel interface to up
Adding the tunnel interface to br0
char device redirected to /dev/pts/1
Too many option ROMS

It turns out this is Redhat bug 473137, which is fixed in the latest etherboot package. If you are running Fedora, you can install this from the testing repository.

Installing and using facter on Solaris and Linux hosts

I have been playing around with puppet, which is an awesome configuration management tool. Puppet allows you to apply configurations to nodes based on one or more facts (a fact is a specific piece of information, such as a list of network interfaces), which includes everything from operating system information to the network configuration. To gather this information, puppet uses facter, which provides a consistent way to locate information about a machine in a machine independent way. To install facter, you can use your favorite package manager, or run the following to install from source:

$ tar xfvz facter-1.5.tgz

$ cd facter-1.5

$ ruby install.rb

Once facter is installed, you can use the facter program to list all of the available facts on your system:

$ facter | head -5
architecture => x86_64
domain =>
facterversion => 1.5.4
fqdn =>
hardwareisa => x86_64

To retrieve the value of a fact, you can run facter with the name of the facts you want to display:

$ facter hostname interfaces macaddress
hostname => kvmnode1
interfaces =>
macaddress => 54:52:00:53:20:00

I’m hoping to start writing about puppet, and my experiences using it to manage my lab. It’s an addictive piece of software, and can save admins lots and lots of time!