Saturday Mar 15, 2014

VirtualBox P2V

Clearing out an old computer in the basement, I wanted to save the system on it. The box was running RedHat and a Content Management System "CMS Made Simple" that I had used to build some websites. Of course this asks for P2V, in other words copy the content of the disk in the server to a virtual image that can then be run on a hypervisor, in my case VirtualBox.

I thought that this would be a tough thing to do, but it ended up being pretty simple. To start, take out the disk, fit it in an external disk enclosure and contact that by USB to the system with VirtualBox. Use "fdisk -l" to find the device name. You don't care about the partitions on the drive, because you want to copy the whole thing.

Now copy the content of the disk to a file with a command like "dd if=/dev/sda of=~/RH-CMS.img". Next convert it to a VirtualBox compatible image with "cat ~/RH-CMS.img | VBoxManage convertfromraw stdin ~/.VirtualBox/HardDisks/RH-CMS.vdi 4327464960". The last number is the size of the image as given by "fdisk -l /dev/sda". Again it is not the size of the partition(s) but the size of the device.

If you (also) run VMware, convert this VDI file to a VMware VMDK format with "VBoxManage clonehd ~/RH-CMS.vdi ~/RH-CMS.vmdk --format VMDK".

Final step is to create the VM. Start VirtualBox, create a new VM and when it asks for "Virtual Hard Disk", click "Existing" and select the RH-CMS.vdi file you just created. And that's all there is to it. You can now increase your disk space, snapshot the image, create backups and your server can continue life without taking up a physical box in the basement.

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
        mount -n -t usbfs /proc/bus/usb /proc/bus/usb -o devgid=501,devmode=664

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.

Saturday Jul 26, 2008

VirtualBox on Solaris

To implement a SunRay demo with a Windows Terminal Server back-end, normally we use two separate servers. But now, with virtualization all around us, why not put those two components on a single box. Of course, there are many ways to skin the cat. I decided to take the X4100 that I had in the lab, put Solaris 10u4 on it, then install Sun Ray Server Software (SRSS) and finally install VirtualBox with a Windows 2003 Enterprise Edition guest server for the backend.

However, this entry is not about Sun Ray or Windows, but about VirtualBox. When selecting the correct download, it was a bit unclear if there were separate versions for Open Solaris versus normal Solaris, or that it was all "one and the same". To jump couple of steps ahead, there is only one version, but it is clear that the developers of VirtualBox are doing their work with OpenSolaris and then expect it to work with regular Solaris as well.

Well, as I discovered, and with me many others, that doesn't always work out. The pkgadd is straight forward and without problems. At the end you will have VirtualBox in your path and you're ready to fire it up. But then I got the following error

bash-3.00# VirtualBox
ld.so.1: VirtualBox: fatal: libGL.so: open failed: No such file or directory

Things like this have happened before, and my usual solution is "let's Google". In this case that was the wrong thing to do, :) because I got soooo many wrong suggestions. In some forum I read that something is wrong with the service "svc:/application/opengl/ogl-select:default" or that you have to install the package "sunwcslr". In my case, none of this was true.

I'm sure that most of the problem is related to the difference between 32 and 64 bit systems. Not only the CPU, but also the OS and therefore the libraries must be matching. With my X4100, I was running a 64 bit AMD Opteron. I had installed Solaris running in 64 bit mode and I hadn't made the mistake of downloading the 32 bit version of VirtualBox.

Here's some commands you can use to verify your own configuration regarding these issues.

bash-3.00# uname -a
SunOS java3 5.10 Generic_120012-14 i86pc i386 i86pc

bash-3.00# ls VirtualBox*

bash-3.00# isainfo -k

bash-3.00# which VirtualBox

This looks good, 64 bits all where it matters. But why are things still going wrong when you start VirtualBox. No matter what all the other forum messages are saying, in my case it was in the end simply a matter of not finding the 64 bit version of libGL.so. I tried many other things first, but what solved it was setting LD_LIBRARY_PATH to include "/usr/X11/lib/mesa/64".

bash-3.00# VirtualBox
ld.so.1: VirtualBox: fatal: libGL.so: open failed: No such file or directory
bash-3.00# echo $LD_LIBRARY_PATH

bash-3.00# export LD_LIBRARY_PATH=/lib:/usr/lib/64:/usr/X11/lib/mesa/64
bash-3.00# echo $LD_LIBRARY_PATH

bash-3.00# VirtualBox

Which shows what went wrong and how it can be fixed.

Friday Apr 28, 2006

Zones Top Ten

For quite a while I've played with Solaris 10 Zones. Even made very good use of them for isolating development projects in a sandbox environment. And so far, all I needed could be done with a simple 'zonecfg', 'zoneadm install', 'zoneadm boot' and then 'zlogin'. Recently I started to dig a little deeper and ran into problems with networking between local zones. And I had issues with that, partly by not enough RTFM :-) and partly by real issues. The real problems were mainly caused by trying this on a system running Nevada with BFU-ed on top of that the BrandZ stuff. Some piece in ZFS broke a dependency in my SMF.

This article is about where I went "off the right track" while setting up my zones. What was obvious and what wasn't. Often because somewhere I read something that was dead wrong (yes, also on blogs :-) or at least incomplete. Because I'm a Letterman fan, I've decided to do this in a Top Ten format. Similar to the Late-Show, don't pay too much attention to the ranking.


This is important: during the install of a zone, never-ever start to "peek 'n poke" around in your local zone's directory to see how far things have come. Don't even think about it!! I know, it is especially tempting when the install takes a little longer, which happens on a slower system. Just by doing a 'cd' in to your zones directory tree, you will prevent nfs mounts to be unmounted and the install will mess up hopelessly. Underwater, what is happening during install is a combination of nfs mounting and hard links (not symbolic links).


There are full and sparse zones. The thing that matters here is whether you specify a "-b" at your "create" in zonecfg. The man-page says about this "Use the -b to create a blank configuration. Without arguments, create applies the Sun default settings." Now you would expect that the default is to inherit nothing and therefore create a full zone. But it is the other way round. With the default come automatic inherits for /lib, /platform, /sbin and /usr. Because /bin is linked to /usr/bin, that one is also inherited from the global zone. Now by adding the "-b" when you create a zone, you don't have these inherits and therefore you'll get a full zone, which takes roughly two gigs per zone. I always end my zonecfg with the sequence "verify", "commit" and "info". The latter shows you clearly what your inherited packages are, even when you use the default.


Many READMEs and HOWTOs on Zones only mention 'zonecfg', 'zoneadm install', 'zoneadm boot' and then 'zlogin'. What is missing there is that the first time you do a 'zoneadm boot' all the services get initialized and the system needs to be network configured. So, before booting the zone for the first time, open another window and enter 'zlogin -C thezone'. This will open a console for that zone (close it with '~.'). When you now boot, you will see that first the services get initialized and then you have to answer the typical questions about network, naming service, locale, etc. At the end the zone will reboot and now you can straight away 'zlogin' into your zone.


Instead of doing 'zoneadm -z thezone reboot' from the global zone, you can just as well do a normal Solaris 'reboot' command from within the local zone. This makes even more sense when you are connected to the zones console ('zlogin -C').


If you failed to have a console open when the zone was booted for the first time, you can do the following: use 'zlogin -C' to open a console into your zone and login as root. Execute 'sys-unconfig', this will halt the zone. Now, in another window, boot the zone again with 'zoneadm -z thezone boot'. In the console window you will now see the same questions asked as during the first boot.


The forums are full of people having trouble with not being able to ssh into their zones. For a while I had the same issues. Many places recommend that you manually create your ssh keys (when missing) with "/lib/svc/method/sshd -c". Which will create the keys, but doesn't solve the underlying problem. Which is that you didn't go trough a proper configuration process after installing the zone. See at [3].


If you've configured DNS as your naming service and you get after reboot that typical message from sendmail with "unable to qualify my own domain name", the solution is to edit your /etc/hosts file from           localhost        thezone        loghost
into           localhost        thezone        thezone.thedomain.the        loghost

IMHO it doesn't make sense, but it fixes the problem.


I discovered that hacking the zoneconfigs is pretty straightforward and fun. You know the slew of disclaimers that should follow here of course . In your global zone, go to /etc/zones. There is an 'index' and for each zone an XML file that has the zone's configuration. In the file 'index' you can change the zone directory, but I wouldn't start messing with that GUID. Also, I think the zone status field is better left alone. If you start editing the index or the XML file, keep the two consistent. This hacking is of course dangerous stuff, but I used it successfully when I couldn't delete a corrupted zone.


To change the behaviour of what happens with a 'create' and 'create -b' in zonecfg, the /etc/zones directory contains two xml files: SUNWdefault.xml and SUNWblank.xml. At least have a look at these to determine what the difference is between the two.


Somewhere along the way in Nevada, I guess around build #30, an option was added to move or clone a zone. Very cool!!

That's it for now. Happy hacking and have fun with your zones ...