One of the relatively recent additions to KDE/Gnome has been the ‘network-manager’ tool. It attempts to make the life of its users easier by automagically managing your interfaces. I can’t comment on its effectiveness during a normal user’s session, but my experiences were frustrating.
I guess it isn’t fair to say network-manager’s operation was frustrating, but rather that it was running without my knowledge, causing weird behavior. I’m setting up dhcpd in a virtual machine to provide addresses for an isolated network. Normally this requires that you only set up the interface, grab the package, set up the subnets you want to assign addresses to in /etc/dhcp/dhcpd.conf, and start up the daemon. However, this time around, I ran into some problems.
First, I attempted to set up my primary interface to use a static IP. I edited /etc/network/interfaces to set eth0 to use a static IP, set it and its netmask, and then brought the interface back up. The output from ifconfig showed no IP assignment. What!? Thinking it was something I was doing wrong, I brought the interface back down and ignored it while I configured dhcpd.
The dhcpd.conf file isn’t difficult to set up. The subnets to service were declared, as were the address ranges to use when assigning addresses dynamically. When the configuration was done, I attempted to bring up the daemon. /etc/init.d/dhcp3-server start… and… errors. “Not configured to listen on any interfaces?” Ugh. Further digging revealed that dhcpd was looking to serve addresses on a 10.10.1.0 network that I had configured, but the only active interface was listening on a 169.0.0.0 network.
Wait – an interface is up? I took it down! I again checked the syslogs, and sure enough, something is initiating dhclient to find an IP address, and upon failing, is assigning a private IP from the 169.0.0.0 range to my interface. The root cause of it ended up being network manager trying to maintain a connection on the interface utilizing its own configuration. Stopping the network-manager service immediately fixed the problem – bringing up the eth0 interface resulted in it being assigned the static IP I wanted, dhcpd ran without a problem, and I was happy.
I have some gripes with network-manager from this experience.
First, I edited /etc/network/interfaces to make the changes to eth0’s configuration. That is the way changes have been made to interfaces since before I started using Linux. I understand what network manager was trying to do, but two things perplex me. Why did it block my static IP assignment when I tried to bring the interface up? It wasn’t even immediately overridden, there was literally no address assigned to the interface. And also, why, WHY is it ignoring standard configuration files? /etc/network/interfaces should remain the be-all is-all configuration for network interfaces. Using another configuration file just makes things confusing.
Second, I believe the behavior of network-manager needs to be changed. I don’t know how this would be possible, so it may be an unreasonable thought – but if I bring down an interface manually, I don’t want it back up until I manually bring it up. Network-manager bringing up that interface after I had manually taken it down was confusing as all hell, and I certainly don’t use Linux to have my machine work against me.
I have disabled network manager permanently on my system. For a standard user (are there any ’standard’ Linux users?) it may function well, but for anyone that wants control of their machine, I suggest they do the same.
[Update: there is an alternative method here. It has better success and is more reliable for partitions that reside in the second or later primary partition positions. It is also a more user friendly.]
I have a Windows XP SP2 installation that I use for work, while my current personal OS of choice is Windows Vista. I only work weekends, so rebooting wasn’t too bothersome initially. Over time it has become more and more of a chore, as I can’t easily switch from one development environment to another without rebooting. I decided it was time to make my work installation a virtual machine.
I had some additional complications that made the process a little non-standard. I originally tried using VMWare’s converter tool, but it would fail at 97% of the creation of the disk. I then tried using a Windows port of the Unix utility ‘dd’ to create a raw image of the disk, but because the Windows volume manager was accessing the disk, dd would give me access errors. Additionally, the VMWare converter doesn’t support converting from a raw image (…grr…), so Qemu’s qemu-img tool would have to be used to convert the raw image to a disk in VMWare’s vmdk format.
The steps to reach our goal aren’t too complicated, and can be replicated by others easily. To do it, I used:
- VMWare Workstation
- A Linux installation or LiveCD (I used my existing Debian installation, but something like Knoppix would work fine)
- Qemu
- NTFS-3G (if you plan on writing out to an NTFS partition from Linux, as I did)
I started by booting into my Linux install. Linux only mounts the disks it uses (hint hint, Microsoft) so we can access all sectors of the partition to make a dump of the disk with dd. I first had to mount the partition where I wanted the output file to reside, which uses NTFS:
ntfs-3g /dev/sdb1 /mnt/external
Next, create the image. I did this with the following (substitute your device/partition and output file):
dd if=/dev/hdc3 of=/mnt/external/diskImage/XPSP2.img bs=1024
When that finishes, the file specified with the ‘of’ option in dd will contain a block-by-block exact copy of your partition. However, it is in a raw format – we need it in a format VMWare can read. This is where Qemu comes in. Qemu is distributed with qemu-img, a tool used for creating, manipulating, and converting images. Specifically, our goal is to use qemu-img’s convert functionality to convert from a raw image format to the vmdk format. This is accomplished with:
qemu-img convert -f raw /mnt/external/diskImage/XPSP2.img -O vmdk /mnt/external/diskImage/XPSP2.vmdk
Be prepared to wait. For a 40gb image, this process took roughly 12 hours. Since qemu-img provides no status as to how far it has come, I kept tabs on it just by monitoring the filesize of the output image. This is entirely unnecessary, but if you want to do the same, just open a new terminal and type the following:
while [1 -gt 0 ]; do du -hs /mnt/external/diskImage/XPSP2.vmdk; sleep 10; clear; done
This will just print out the size of the file on your screen so you can watch it grow. Alternatively, Roberte provided a tip in the comments that suggested using the “watch” command. Either will work:
watch ‘ls -lh /mnt/external/diskImage/XPSP.vmdk’
When the process is completed, boot back into Windows (or if you are using Linux as the host, stay put) and create a virtual machine around your new disk image. Don’t forget to remove the original img created with dd, it is a huge waste of disk space :)
[Notes]
- This process is really only feasible if you have a lot of disk space. At worst, the disk requirements are greater than 2*P, where P is the partition size of the virtual machine you wish to create. However, qemu-img only writes out actual data, not empty sectors, so your output image will be the size of the used space in the input image. For my conversion, I used over 40gb (input)+15gb (output) of disk space, which was reclaimed with the deletion of the output of dd, and resizing another partition to use the old physical installation’s space.
- qemu-img doesn’t support stream input, which is why we can’t pipe dd’s output directly into qemu-img convert. This would have reduced the disk requirements to only the size of the vmdk image, and sped up the process substantially. Bug the Qemu developers to implement this feature :)
This really shouldn’t have taken me as long as it did to figure this out, but it was a big enough of an annoyance that I decided to share it.
How to convert a relative path to an absolute path in linux/unix/bash script:
#!/bin/bash
# Assume parameter passed in is a relative path to a directory.
# For brevity, we won't do argument type or length checking.
echo "Absolute path: `cd $1; pwd`"
For those unaware, you don’t have to ‘cd -’ because the backticks perform command substitution and don’t modify the working directory of the script.
EDIT: Anonymous poster ‘foo’ left a comment mentioning that this only works if the path destination already exists, which is indeed the case. This isn’t at all elegant, but it is the ‘two minute hack’ version I could immediately come up with. The result only works if you have permission to write where the path should go, meaning *yes,* there will be a version three of this script when I have more time:
#!/bin/bash
# Alright, this time we'll do parameter checking.
if [ $# -eq 0 ]; then
echo "Usage: $0 "
exit 1
fi
if [ -d $1 ]; then
# Paramater is an existing directory. Print it using the method in the script above.
echo "Absolute path: `cd $1; pwd`"
elif [[ -e $1 && ! -d $1 ]]; then
# File already exists and isn't a directory. Be more safe with the conversion.
mkdir $1$$ 2> /dev/null
if[ $? -ne 0 ]; then
echo "We cannot conver this path without write permissions to the path's destination."
exit 1
fi
# I don't want to escape the quotes. This is already ugly, anyway.
dirName=`cd $1$$; pwd | awk -F"$$" {'print $1'}`
echo "Absolute path: $dirName"
rm -r $1$$
else
# File doesn't exist, begin unelegant conversion
mkdir $1 2> /dev/null
if [ $? -ne 0 ]; then
echo "We cannot convert this path without write permissions to the path's destination."
exit 1
fi
echo "Absolute path: `cd $1; pwd`"
rm -r $1
fi
Secondary notes: I really wrote this on the spot in a couple minutes, directly into this blog post. It is untested, and very ugly. I promise to post something better soon!
