i-am.ws


Saturday May 23, 2009

VirtualBox USB Ports

Running CentOS as my host OS and using VirtualBox to run "everything else", it didn't take long before I was running into USB problems. In my case I had a Windows 2000 guest on a CentOS 5 host (same for RedHat EL) and I wanted to use ActiveSync to connect to my WM5 Windows Mobile device.

I'm diverting for a sec, but this is the big reason why I like VirtualBox so much. I do software development for the Windows Mobile platform (http://www.locatea.net/) which requires a lot of software installation for Visual Studio and then even more for the various Windows Mobile SDKs. It is quite a job to get it all installed correctly. Previously that whole install could (and would) easily be screwed up because some completely unrelated application would mess up the registry, forcing you to reinstall the server and start from scratch.

Now, by virtualizing my desktop, I have an instance that I solely use for Windows Mobile software development. If I need Microsoft Office I do it in another Windows guest. And if I want to tryout a new software package that I don't really trust, I simply clone my base image and install it in there. If the app doesn't work out or behaves badly, I can simply blow the whole image.

So, where many people think that desktop virtualization is just great for running different types of OSes on a single host, IMHO it is even more important because it allows you to create multiple environments, that have very dissimilar functionality, but can have the same platform requirements. Of course I also use it to run OpenSolaris on my Mac. :-)

Back to USB in Windows guests. Out of the box it doesn't work, at least not on my platform. A little googling provides a lot of recommendations to add an entry to /etc/fstab (none /proc/bus/usb usbfs devgid=501,devmode=0664 0 0). It seems that for Ubuntu this fixes the problem, but not for RedHat / CentOS. It took me a lot of searching, but finally I found in an obscure corner of some forum a solution. You have to modify your /etc/rc.d/rc/sysinit file.

if [ ! -d /proc/bus/usb ]; then
        modprobe usbcore >/dev/null 2>&1 && mount -n -t usbfs \
                        /proc/bus/usb /proc/bus/usb -o devgid=501,devmode=664
else
        mount -n -t usbfs /proc/bus/usb /proc/bus/usb -o devgid=501,devmode=664
fi

This piece is mainly already there, but you need to add the "-o" parameters. In here "501" is the GID you have specified in your /etc/group for the vboxusers group.

After having done this, the Windows guest recognizes USB sticks, external hard drives and nicely connects to my mobile phone.


Friday May 11, 2007

Network Speed with Zones

A little time back I was preparing for a big benchmark project where our customer wanted to compare a single large system using many zones with a more horizontally scaled infrastructure, consisting of a number of smaller servers, like V490 and V890. I immediately thought that replacing a number of servers, being chatty over the network, with a single server, carved up into zones, would give a big benefit in network performance. Zone-to-zone network traffic should be faster than server-to-server. So I fired off some emails to people that I thought would give me the final answer, but the responses were very mixed.

Therefore it was time to do some of my own experiments. Doing a big benchmark in one of the Sun Solution Centers, I had the availability of some serious hardware for these tests. On the other hand, as is usual with these types of projects, there was a lot going on at the same time, therefore in the end time was limited for this little exercise.

This was my test platform:

  • A few 8 CPU / 16 core domains (1800 MHz US-IV+) on E25K.
  • Couple of quad Gigabit Ethernet cards, connected to a SMC switch.
  • We had to use the 'ce' network drivers, because there were incompatibilities with other ones.

This is the environment I built:

  • domain A, zone 1, IP 10.1.1.131, interface ce2:1 - used for sending files
  • domain A, zone 2, IP 10.1.1.132, interface ce2:2 - receiver, using the same physical interface, but with its own virtual interface
  • domain A, zone 3, IP 10.1.1.133, interface ce3:1 - receiver, having its own network interface, but different from the one used by the sender
  • domain B, zone 1, IP 10.1.1.101, interface ce4:1 - receiver, now a completely different domain, so will only communicate with sender over the copper wire

This provided us with three test scenario's: a) network traffic from one virtual interface to another, both on the same physical interface, b) two zones talking with each other, each with their own physical interface and c) two independent servers, or in this case domains.

I used ftp to send files of three different sizes: 1M, 3M and 1G bytes. All files were created in /tmp and sent to /tmp. I repeated each test three times. Here are the results (all times in secs):

  zone-to-zone
same interface
zone-to-zone
other interface
server-to-server
other interface
1 MB 0.0072
0.0056
0.0058
0.0083
0.0077
0.0080
0.012
0.012
0.013
3 MB 0.27
0.16
0.15
0.23
0.21
0.21
0.35
0.33
0.34
1 GB 6.7
5.0
4.9
6.1
5.4
5.4
11.0
11.0
12.0

So, from this we can see clearly that zone-to-zone traffic doesn't "hit the copper" and probably gets shortcutted somewhere in the IP layer of the TCP/IP stack. I would think that with slower interfaces, like 100 mbps, the speed advantage will be even higher than the 1.5-2x we see here.


Calendar

Entries

Search

Links

Navigation