Thursday Jul 03, 2008

VirtualBox with a promiscuous floozy...

Everything was working just fine on my laptop machine, my VirtualBox VMs could see each other, Jumpstart and JET were just fine, and all of the VMs could see the outside world. When I moved my configs into my ridiculously over-configured desktop machine (see blahg entries from about 18 months ago), networking stopped functioning. Weird. In fact, my Windows host machine stopped communicating to the outside world as well. Ouch.

VirtualBox uses a "TAP" interface driver to bridge or NAT the VM networks through the WIndows host. On the Windows side, in order for this "TAP" adapter to talk to the outside world, it must use the "Network Bridge" or "MAC Miniport Adapter". If you select the TAP adapter, CTRL-click your network adapter that talks to the outside world, right mouse click and select "Add to Bridge", the two adapters are linked together into a single logical interface. Packets from one side can magically appear on the other side. In fact, you should be able to "snoop" from a Solaris virtual machine and see packets flying around on your external network. The final Windows XP Network Connections window should look something like this:

Yeah, that's how it is supposed to work. Mine didn't. I checked the Firewall settings, and even disabled it temporarily to make sure that it wasn't the problem. I Googled (and yes, that is a verb), and found nothing apropos. After several hours of head scratching, reading blogs, reading through the Microsoft technical docs, and banging my head against the keyboard, I stumbled on the answer. My adapters were not in "promiscuous mode". Promiscuous mode allows adapters to pass through all of the packets that they see, rather than just the packets that are addressed to this host. That sounds like what I need.

The magic mojo to make my bridged adapters go into promiscuous mode was fairly painless. Click on [Start] -> [Run] and type "cmd" to get a shell window on the XP host. In the shell window, I was able to run the netsh commands necessary to make the adapters go promiscuous, and to check that the changes were in place. This changes registry entries, so you should be able to just jump through these hoops once, and the settings should remain through reboots:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\\Documents and Settings\\Bill Walker>netsh bridge show adapter

 ID AdapterFriendlyName         ForceCompatibilityMode

E:\\>netsh bridge show adapter

 ID AdapterFriendlyName         ForceCompatibilityMode
  1 VirtualBox Host Interface 1 unknown
  2 Local Area Connection 2     unknown

E:\\>netsh bridge set adapter 1 forcecompatmode=enable

E:\\>netsh bridge set adapter 2 forcecompatmode=enable

E:\\>netsh bridge show adapter

 ID AdapterFriendlyName         ForceCompatibilityMode
  1 VirtualBox Host Interface 1 enabled
  2 Local Area Connection 2     enabled

Voila! My Windows network is back to a sane mode. My VPN connections to the office are alive and well. My VirtualBox VMs can now see the outside world. I now have my Frankenstein super-desktop (TBs of disk, 8G of memory, 4x Opteron cores) back in a happy state. As always, your mileage may vary, objects in mirror may be closer than they appear, no warranty expressed or implied, but I hope this helps someone save hours of head banging on fragile keyboards at some point.


Saturday Jun 28, 2008

VirtualBox meets JET...

So first, the why. I was working on a project (described in detail in earlier blahg entries) that used JET/Jumpstart to maintain "golden images" of systems for provisioning in the application and web tiers. First reason for doing this was just to have a JET configuration that I could play with in my hotel room while waiting for room service. Sitting around the office behind the firewalls just to get access to the boxes can be a bummer after about 8pm.

Second reason for this, I'm a geek. Once I had the idea in my head, I just had to get it to work. Third reason, it is a really handy way to set up machine variances within VMs on your desktop or laptop for demos and testing software. Yeah, you can "clone" VMs, and copy the disk images and configs around. But you never know when you are going to "fat finger" a VM, or forget some important step when munging things by hand. Using a JET server allows you to save a config, re-use it, and always start with a fresh "machine" to work on, in a known state. You can even save off your favorite VMs as "flar" images to restore on demand, using compressed images can save \*tons\* of space, especially important when you are on a disk-limited road warrior laptop system.

Step one, download Sun xVM VirtualBox and read all of the assorted docs and technical info. Join the community, read the Wikis, read some blogs.

Step two, install the downloaded package on your system of choice. In my case, I am running it on my laptop and desktop machines, both under Windows XP. There are lots of folks running other host systems, read the info, read the blogs.

Step three, download your Solaris or OpenSolaris DVD image of choice. No need to burn the image on to DVD media, we'll just mount the ISO DVD image as a virtual DVD later. While you are cruising, join some discussions, cruise through the forums, read some documentation, join the movement. (Can you tell I really like OpenSolaris?)

Step four, (well, maybe after you play around with VirtualBox a bit and get comfortable with it) create your Jet Server virtual machine (VM). Double click on the desktop icon, and then click the "New" button. For my configuration, I went with an 32G root disk, added in 32G for /export (only allocated from your hard drive as you use the space), 512Meg of RAM (I have 8Gig on my desktop and 4Gig in my laptop), and defined the CD drive to be a virtual drive, mounting the ISO image that we just downloaded.

The networks here are the tricky part. I am using a "Back End Network" (BEN) for management. I will keep my JET/Jumpstart traffic on the BEN, and use a second interface as a "public network". My BEN network is defined as "internal network" or "intnet" (inter-VM traffic only). My external interface could be NAT or host bridge, either way, the Windows host can get to the VM, and the VM can see the outside world (Firefox can get to Google). I configure the VM through the GUI, but then ran into a little "issue".

There was a bug in the earlier (1.3.X) version of VirtualBox that broke "intnet" network connections. A couple packets would fly back and forth between VMs, and then the connections would just disappear. You could snoop and see packets going out, and sometimes being received, but answering packets never made it back to the originating host. I don't know if that is fixed in the current version (1.6), but there is a workaround. In the Windows host, click [Start] -> [Run], and then type in "cmd" to get a shell window. Use "cd" to go to the VirtualBox installation directory (C:\\Program Files\\Sun\\xVM VirtualBox in my case), and use the command line utility VBoxManage.exe. The magic mojo here is (for my VM named JETserver):

  "C:\\...xVM VirtualBox> VboxManage modifyvm JETserver -nic1 intnet

Note that the network interfaces are "nic1" (my BEN) and "nic2" (my public interface).

Now just click the "Start" button, followed quickly by pressing "F12" on your keyboard to choose the boot device. This option only appears during the splash screen of the virtual BIOS, so you have a second or two to hit the key. Choose CDROM for your boot device and away you go installing Solaris as usual. You can also juggle the boot devices under [General] -> [Advanced] -> [boot devices] in the configuration pane. Make sure that if you created a second drive for the JET stuff (as I did) that you set it up during the install, or fdisk/format/newfs it when the machine is booted. Make sure that you set your boot devices again, or unmount the virtual CDROM device, or hit F12 really quickly again to boot from disk after the install.

There we go, a Solaris VM. Yay! Now we need to make it into a JET server.

Step five (OK, so four was rather long), download the Jumpstart Enterprise Toolkit (JET) software from the JET home on BigAdmin. BigAdmin is your friend. Cruise around, read the JET Wiki, read docs, join communities, etc. as usual. Also take a cruise through Mike Ramchand's blog, and check out the Yahoo! JETJumpStart group.

Step six, follow the instructions for installing JET, using that ISO file again as a virtual CDROM device. Make sure you run:


to get the DHCP and PXE boot stuff in place, since we will be using those goodies to boot our client VMs.

The documentation for JET is included in the package in PDF format. Read it (at least give it a cursory pass through) before continuing. The simple stuff is really simple. The more complex and intricate operations can get tricky.

Step seven, create a new VM to be a JET client. This is simple, here is a screenshot of my JSclient machine to show the settings (don't forget to jump out to the command line again for VBoxManage.exe after you configure it through the GUI):

Take note of the ethernet address of your virtual adapter, and use that in your JET template. Make sure you assign the IP address of your JET client in the template file to be on the same network as your BEN "intnet" connection on the JET server VM. If you want to get fancy, you can add a public interface to the JET client configuration and add that to the JET template as well (DHCP or fixed IP with default router and DNS server info in the template).

Step eight, boot the sucker, hit "F12", and choose network boot (PXE) (or again, juggle your boot devices under the [General] -> [Advanced] -> [boot devices] configuration pane). If things don't work as planned, you can snoop your nic1 from the JETserver VM to debug things. That's it. Simple. I'll post some more screen shots and details of my template files as time permits.





« August 2016