I got hit with a weird bug when I upgraded to VMWare 6.0.3. Before, my Debian Linux guest could happily browse the Internet with a NAT interface. After, I could resolve both internal and external IP addresses, but could not resolve any domain names using DNS.
I can only guess at why, but I believe the problem was not the configuration of my guest, but rather that the problem lays in how VMWare deals with the DNS queries. I use DHCP to obtain an address from the built-in DHCP server, and I was being assigned a DNS server along with my IP (as verified by checking /etc/resolv.conf), but it wouldn’t resolve any names for me.
My solution for now is to step around the assigned DNS address given by the DHCP server, and choose another one instead. I opted to use OpenDNS’s servers, and configuring Debian to use them is trivial - just open /etc/resolv.conf as root with your favorite editor, and change the ‘nameserver’ line to use OpenDNS’s DNS servers. Mine looks like this:
domain localdomain
search localdomain
nameserver 208.67.222.222
Restarting the network isn’t even necessary, the next named request you make should be resolved successfully and everything should be peachy!
If you want to make the change more permanent, you can assign a static IP and a static nameserver to the active interface of your guest operating system (hint, /etc/network/interfaces), which will circumvent the DHCP server. If you want to keep using the DHCP server, you’ll have to change the nameserver line every time you request a new address.
Hope this helps someone else!
In my last post I chronicled the time consuming process of converting an image produced using the Unix dd utility to a vmware VMDK virtual disk. The process does work, but VMWare will only load it if the image contains a master boot record that still contains the appropriate information when removed from the rest of the system. Additionally, I think it is appropriate to mention again how terribly slow it is. We can circumvent these problems with Live View for Windows, a program developed for forensic work by Carnegie Mellon University.
The process for creating the image with dd is the same as last time, IE, by doing something along the lines of:
dd if=/dev/hdc3 of=/mnt/external/diskImage/XPSP2.img bs=1024
Once that image is generated and you are back in Windows, simply launch the Live View utility and… the rest is pretty self explanatory. Once the dd image is generated, the Live View program takes only a couple minutes to create the new vmdk, configure the virtual machine, and launch it. Sweet, sweet efficiency!
[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 :)
