Tuesday, April 26, 2011

RHEL 6 Virtualization - Bridged Interface

With version 6, Red Hat has finally fixed the long standing problem of not being able to use the GUI to configure a Virtual Machine shared connection. Lets first review the types of VM network connections:
* RH=y  CX=y  VW=y Internal
* RH=y  CX=y  VW=y Dedicated or Slaved NIC
* RH=y  CX=y  VW=y Routed or VLAN'd
* RH=y  CX=y  VM=y Shared or Bridged
* RH=y  CX=n  VW=n Network Address Translation (NAT)
(Bold entries are the "default" config.)
An internal connection does not route traffic off the host system. A dedicated (also called slaved) connection, requires a separate NIC for each VM, which is very inefficient. A connection that is routed or VLAN'd requires the network be aware of the the specialized configuration. A shared or bridged connection (what we're after) extends the real world subnets in to the virtual machines. The last type, NAT, allows the VM's to communicate out, but does not permit inbound request, thus rendering it useless to servers.

Unfortunately, Red Hat uses NAT, by default, and their virtualization technology is principally used for server consolidation. As if this is a good idea. To make matters worse, their documentation still suggests manually configuring a shared connection, and does not explain that once you're done, you won't be able to see the connection in the GUI.

Here's how to do it right:

From virt-manager, connect to the host, click Edit, and select Host Details. On the Network Interfaces tab, click the plus sign (+) at the lower left. In the pop-up, select "Bridge" and Forward. Assign a name-- I recommend br followed by the eth number of the card you are sharing. In other words, if you are sharing eth1, name it br1.

On the same screen, set the start mode to "onboot", check "Activate now", and check the target NIC that you want the VMs to access. Take a deep breath, hold it, and click Finish. Scary things will happen, but after about a minute, the window should respond.

Notice that the eth item has disappeared from th elist and been replaced by the newly defined bridge. Now click the Virtual Networks tab, and notice nothing has changed. Why doesn't the new connection appear in the list? More evidence that Red Hat's interface is the least intuitive of all the vendors. This tab is a list of virtual networks, and a bridged connection is an extension of the physical network. (Yeah, while technically correct, it doesn't make sense to me either.)

When provisioning VMs, make sure to select expand Advanced options and choose the br device.

*** NOTE ***
An excellent discussion of the underlying technology is available on Dale Bewley's blog. You'll need this for kickstarting hosts.

Sunday, April 24, 2011

RHEL 6 Virtualization As Non-root User

Red Hat has always been overconfident about the use of the root account over SSH. By default they allow direct logon to the root account via SSH, because the first "S" stands for Secure. But that's not the point... You should never let anyone logon directly as root. Always access as a user, and escalate privileges.

With RHEL 6 virtualization, I ran into a problem with virt-manager, in that it refused access from a non-root account. If I logged in as myself, the app would start, but not allow connections, complaining:
Unable to open a connection to the libvirt management daemon.
Verify that:
- The 'libvirtd' daemon has been started
Further digging (clicking "Details") shows a couple Permission denied messages. Using sudo doesn't help, switching to root doesn't help, but SSH'ing in as root works. So, what's the fix?

Turns out there is security group that allows the identification of trusted users. Edit the /etc/libvirt/libvirtd.conf file and uncomment three lines:
unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"
auth_unix_rw = "none"
The third line bypasses the "polkit" security mechanism... since it doesn't work, anyway.

The natural reaction would now be to issue a service libvirtd reload command, but not so fast... that won't work. (But feel free to try it if you like-- I'll wait.)

List the /var/run/libvirt dir. You should see a libvirt-sock file owned by root.root with permissions of 700. Use service libvirtd stop, and file will disappear. Issue service libvirtd start and it should fail to start, claiming it can not load the configuration file, which is not true. The problem is that we told it to allow access to members of group "libvirt", which does not exist. Create it, add yourself:
groupadd -g 170 libvirt; usermod -a -G libvirt doug
Logoff, login, and verify with the id command.

Issue the start command again, and the service should start. List the /var/run/libvirt dir. This time, the file is owned by root.libvirt with permissions of 770. We can now access and control the server as a non-root user.

Thursday, April 21, 2011

RHEL 6 - Network Gotcha

Earlier, I had reported problems with my Atheros integrated NIC on my new mainboard. I finished the build on my RHEL 6 cloud node by adding an Intel Pro100 I had lying around as eth1. As expected, Anaconda recognized the card on install. To my surprise, the card was not active on first boot. But then the real surprise... I concurrently installed a RHEL 6 VM, and its virtual 8139 was also not energized on boot.

Something wicked is afoot, and it smells putridously similar to:
When we cat ifcfg-eth0, by default, the file includes DEVICE, HWADDR, ONBOOT equal "no" (the symptom), and NM_CONTROLLED equal "yes" (the disease). I've hated NetworkManger ever since it showed up on RHEL 5. (It uses that ridiculous mixed cap, no space, spelling because the Red Hat developer who "innovated" this solution wishes he worked at Apple instead, and that's the way Apple processes are named.) My traditional solution was to chkconfig NetworkManger off, hardcode the network params, and life was good.

There is a perplexing part to this story, however, that forces more review. On RHEL 6, if you select @Base, @Minimal, or @Server-Platform, NetworkManager is not installed. That's fine with me, but the cards are tagged as being controlled by a service that doesn't exist. So, I approached this from the point of view that just as we are going to have to learn to use postfix instead of sendmail, know how to configure static networking with NetworkManager. Preferably, without the GUI.

So, I installed a slew of RPMs from DVD to get the NetworkManager service running. I read man pages, researched in the web, played with the tools, and found the solution. The solution is to hard code the static IP in a script under /etc/NetworkManager/dispatcher.d. But wait a second... If we have to hard code the data in a script, why not put it in /etc/sysconfig/network-scripts as we have been for over ten years. Good idea: Let's uninstall all this piece of crap.

The workarounds:
* Kickstart the server with a static address
* Set the address using firstboot
* Manually edit the interface files
* Use system-config-network-tui to set the address. (Don't try to use the TUI to set it to DHCP, it won't work)

Sunday, April 17, 2011

MSI 880GM MainBoard... Oops: E41

I bought a box of computer guts from Newegg, to upgrade my Linux virtualization host. This box has not been doing anything recently, because it was still running Fedora 8. I know F8 is soooo old, but the machine is only a PIII with 512Mb. Since it didn't have VMX or SVM, old school Xen was all it could run.

That board was an Asus, and it had served me well, as have several other Asus boards. My Citrix XenServer machine is running on a Foxconn mainboard and my VMware ESX is running on HP board (because VMware will not lower themselves to run on anything but name brand hardware.) This time around I selected an MSI 880GM-E41.

My plan was to run RHEL 6 for a few weeks to look at the changes to their virtualization stack, then move to either SL60, Citrix XenServer, or VMware. To determine my options, I attempted an install of each. Of course VMware threw up all over the box, but I expected that.

What happened next scared me: Citrix XenServer refused to load, since the machine had no network port. No need to panic. I tried Red Hat 6, which installed, but didn't recognize the onboard port.

Uh oh... Bad board? That means pulling out all the guts and spending more money to send the thing in for a replacement. Maybe I should check the Google Interwebs to see if this is a known issue.

And it is. The 880GM-E41 has an Atheros AR8131M, which is not "fully" supported by Linux. If I had gone $5 more to the 880GM-E43, I would have gotten a Realtek 8111DL, but I didn't check the drivers first. The really fun part is that if I'd gone $5 less to the 760GM-E51, I would have only lost the ability to overclock the memory. For some reason Newegg's site only displays the 760GM-E51 when you specifically search for MSI boards. (It must be a special order.)
So what do we do? Turns out, Red Hat's Anaconda installer does not recognize the Atheros NIC, but the Red Hat kernel does. Once the install was finished, I was able to manually configure the interface. At the first boot, udev had seen the card, and installed the driver, but was not able to active it without an ifcfg-eth0 file.

I've got a couple hours left, tonight. I'll either try to hack Citrix Xenserver to recognize the NIC, or mess around on I Can Has Cheeseburger.

Monday, April 11, 2011

Scientific Linux (SL-6.0) Pt 2

For the record, SL-60 will not boot with 128Mb of memory, it reports "Out of memory". Works with 196Mb. I generally run my VMs on the ragged edge, so I may try to chew that a little lower.

*** Update ***
Nope, 196Mb is as low as I'm willing to try to go.

Sunday, April 10, 2011

Scientific Linux

With the introduction of Red Hat Enterprise Linux 6, I've had to renew my certification. A couple Friday's ago, I got my RHCSA, and in a couple more weeks I do the RHCE. In preparing for the test, I've come across a distribution called Scientific Linux

Scientific Linux is a recompiled version of RHEL, similar in concept to CentOS, with one very important difference: CentOS sucks and is for posers. Scientific Linux, or SL, however, is the output of Fermilab and CERN. Where as CentOS is a disorganized, bickering bunch of dot.com wannabee's, who have created a product for people that are too cheap to run Red Hat, but too scared to run Fedora, SL is put together by people who need raw computing horsepower, and lots of it.

I've played with it, and thus far, am impressed with what they've done. Here are some observations:
* I was a little surprised when I used the boot.iso to launch a installed only to find that it automatically does a minimal install without asking.
* It defaults to postfix instead of sendmail, but I guess its about time to let sendmail die.
* At install time, you can select several well respected third party repos.
* They've got a lean, mean, minimal install.
* The GUI installer would not run in 640Mb of RAM, but would at 768Mb. (But that might be a RH thing.) Once it was installed, I dropped the memory down to 256Mb and everything run spiffily.
* They've got the install DVD's laid out wrong-- You can't do a base install using only DVD1. For me, that meant I had to actually extract the DVD's to create an intall repo rather than mount just DVD1.

I'm running this in a VM under Citrix XenServer and am having some problems with the vmtools utility, but that does not surprise me. Once I've got the base VM tweaked, my first project will be an OpenLDAP server, followed by a Kerberos.

Saturday, April 09, 2011

Wente Sauvignon Blanc

And what do we all know about sauvignon blanc? That's right, it grows in New Zealand. This one is from California.

I actually looked for this wine, since one of the wine magazines pointed out that I shouldn't be snobby about CA wine, as long as the CA wine has a 90 point score. My wine shops don't usually carry 90 pointers, but I keep looking anyway. I could try going to swankier stores, but we both know I'm not going to pay the swanky price.

When I found this San Francisco Bay wine for about $17, I grabbed it as if I'd found a real bargain. One taste, and I knew I could have bought a Chilean white and saved myself $10. Way too much vinegar and citric acid. Why, you could almost taste the exhaust from the 101.

Scary to say this, but I'd rate this 90 point wine a 4 out of 10.

Casa Santorsola Barbera

It is very unusual to find a Piedmont Barbera for under $25. To my astonishment, this one was $7. Since these northern Italian reds are usually out of my price range, I don't have much to compare it to; so, I'll compare it to other $7 reds.

Bueno! It was not too heavy, a little dry. The Barbera is a close cousin to the Sangiovese of Chianti fame, but did not have the same taste. Oddly, I'd compare it more to a Pinot than a Chianti.

Definitely a stron 6 out of 10, maybe even a 7, because of the price.