The following are various notes I took somtime in 2006 while getting QEMU working with Windows 98 as the Guest OS and Linux has the Host OS. Its very old info and probably command lines don't fully apply any more. The page gets a surprising amount of hits related to the proxy arp information; so I'm leaving it around for reference. Time and DateTo get clock working correctly under windows be sure and specify the -localtime option when running QEMU. NetworkingBackgroundI occasionally need to use some VPN software and when I do I like to run it under a virtual machine dedicated to the VPN. That way I do not have to worry about changing web proxies and other program settings. I initially had some difficulty getting networking working under QEMU with VPN's but I finally did it. There are two ways I got it working. The first way is using a tunnel device bridged to the VLAN of QEMU. The second way is to use the user-mode stack and simulate a NAT environment. The nice thing about the first approach is that all machine on your network should be able to reach the the QEMU Guest OS (with some restrictions on broadcast packets). This section describes how I got that working. The ConceptQEMU creates a VLAN with an emulated interface under Windows 98 Guest OS and a tunnel interface (tap0) on Linux Host OS. Some sort of bridging is required to get internet traffic from a real Host OS interface on to this VLAN. I've seen some really complicated bridging examples that use Linux's bridge interfaces but I've found the following simplified setup to work for average use cases. First, what I did was tell Linux to act like a router instead of just an IP host. This is needed to prevent Linux from dropping packets that are not destined for a local IP address. Next, I added a route that says "forward all packets for the guest OS to the tunnel interface". And finally, I turned on the Proxy ARP feature of Linux and told it to responded to ARP requests for the Guest OS's IP address. That works for bridging traffic from your network to the Guest OS but not the other way around. Normally, you'll have a default route installed and that will solve that part of the problem. All packets received on the tunnel interface that are not for a local IP address will be forwarded to this gateway for real routing. This may not work as you'd expect unless you have Linux's default route pointing to a real router inside your local LAN (such as your broadband routers IP address). Usually, you'll want to set your broadband router's gateway to your ISP's gateway and then set all local computers gateway to your broadband router. This solution breaks down with broadcast and multicast packets (such as DHCP). What would be needed is to put your main ethernet interface and the tunnel interface in promiscuous mode and have a daemon listen to all packets and manually forward broadcast/multicast packets between the two. Or alternatively you could use Linux's bridge devices which are doing a similar job. SetupMy network consists of a broadband router with my Linux box hooked to it. This router has the typical default subnet of 192.168/16. An important point to remember is you will want to place the Windows 98 Guest OS in that same subnet to prevent having to install routes inside the broadband router. Since the broadband router's DHCP won't work with this approach, I used two IP addresses in the 192.168/16 subnet that I knew my router's DHCP server wouldn't hand out. I went into windows and provisioned the emulated ethernet interface with an IP address of 192.168.1.200; along with appropriate DNS settings and default gateway settings. I've also reserved the address 192.168.1.150 for use by the tunnel device. My /etc/qemu-ifup looks like this: #!/bin/sh Thats it... The bridging is done only for a single IP address by installing a proxy ARP. Run QEMU with -net nic -net tap to use this setup. WARNING: The above qemu-ifup requires you to run QEMU as root. Someone was nice enough to email a version that uses "sudo" to remove that restriction. I haven't tested it but I provide it for your reference. #!/bin/sh User Mode NetworkingI originally thought user mode networking would be to restrictive and so I got the tunnel device working first. Afterwards I decided to try it and was amazed that it work for most the cases I needed it to. I was even able to use a VPN client to connect through my broadband router! Thats 2 NAT's (QEMU does one and the broadband router does another) and it still worked! This mean the above directions may not be needed. Unless you need the Guest OS to be directly reachable (SMB browsing?) then I'd try this first. Simply run qemu with -net nic -net user and set up windows to obtain its IP address using DHCP. AudioI chose to emulate the ES1370. Since ts PCI it will be autodetected much easier. You'll have to download a driver for Windows 98 to use this device. I got a copy from the here. Add -soundhw es1370 to your command line to get sound working with the above drivers. CPU CyclesUnder QEMU, Windows 98 will normally consume lots of CPU cycles even when idle. You'll really want to install the suggested program to reduce your Idle CPU load. Mouse SupportUp until version 0.8.1 of QEMU, it was impossible to have the mouse leave the focus of the QEMU window. You would have to hold down CTRL+ALT to release the focus to use other windows. By upgrading to 0.8.1, there is an emulated USB mouse that allows letting focus automatically change between QEMU and other windows when the mouse reachs the edge of the QEMU window. Just add the command line options -usb -usbdevice tablet when running QEMU. NOTE: Enabling USB support causes a large preformance hit on my 800MHz ADM. QEMU went from consuming 5% CPU while idle to consuming 60%. |
Linux >