On 07/02/2010 08:02 AM, miles kuo wrote:
> Hi Michael Goldish,
>
> I want to use bridge in the VMs and create the bridge on the host
> machine. Add "nic_mode = tap" to the tests.cfg
>
> - qemu_kvm_windows_s1:
> qemu_binary = /usr/bin/qemu-kvm
> only qcow2
> only rtl8139
> nic_mode = tap
> only virtio_blk
> only smp2
> only no_pci_assignable
> only smallpages
> only Win2008.r2
> only unattended_install.cdrom boot shutdown
>
> /usr/bin/qemu-kvm -name 'vm1' -monitor
> unix:'/tmp/monitor-humanmonitor1-20100630-221510-YkyC',server,nowait
> -serial unix:'/tmp/serial-20100630-221510-YkyC',server,nowait -drive
> file='/tmp/kvm_autotest_root/images/win2008-r2.qcow2',if=virtio,boot=on
> -net nic,vlan=0,netdev=idVZT9YT,model=rtl8139,macaddr='52:54:00:12:34:56'
> -netdev
> tap,id=idVZT9YT,script='/home/kvm/0701/autotest/client/tests/kvm/scripts/qemu-ifup',downscript='no'
> -m 512 -smp 2 -drive
> file='/tmp/kvm_autotest_root/isos/windows/en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_x64_dvd_x15-59754.iso',index=2,media=cdrom
> -drive
> file='/tmp/kvm_autotest_root/isos/windows/winutils.iso',index=3,media=cdrom
> -fda
> '/home/kvm/0701/autotest/client/tests/kvm/images/win2008-r2-64/floppy.img'
> -redir tcp:5000::22 -redir tcp:5001::12323 -vnc :3 -boot d
> 00:46:51 DEBUG| VM appears to be alive with PID 17020
> 00:46:51 DEBUG| Starting screendump thread
> 00:46:51 INFO | Starting unattended install watch process. Timeout set
> to 7200s (120 min)
> 00:53:24 DEBUG| Could not verify MAC-IP address mapping:
> 52:54:00:12:34:56 ---> 192.168.0.175
> 00:53:29 DEBUG| Could not verify MAC-IP address mapping:
> 52:54:00:12:34:56 ---> 192.168.0.175
> 00:53:31 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:53:31 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:53:31 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:53:31 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:53:32 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:53:32 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:54:19 DEBUG| Could not verify MAC-IP address mapping:
> 52:54:00:12:34:56 ---> 192.168.0.175
> 00:54:23 DEBUG| Could not verify MAC-IP address mapping:
> 52:54:00:12:34:56 ---> 192.168.0.175
> 00:54:25 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:54:25 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:54:27 DEBUG| Could not verify MAC-IP address mapping:
> 52:54:00:12:34:56 ---> 192.168.0.175
> 00:54:27 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
> 00:54:27 DEBUG| (address cache) Adding cache entry: 52:54:00:12:34:56
> ---> 192.168.0.175
>
> Failed in rss.exe in Windows. See the snapshot rss.PNG
1. The "could not verify ..." messages, following the "adding cache
entry" messages, indicate that the guest did not respond to arp requests.
- Make sure you have /sbin/arping. If you don't have it, please see if
you have arping anywhere else (maybe /usr/bin/arping?). If you do, then
the autotest code should be fixed. Currently it assumes that arping is
always under /sbin.
- If you have /sbin/arping, could there be another guest with the same
MAC address in the network? Try using another MAC address: change
address_range_base_mac_r1 for your hostname in address_pools.cfg. If
your hostname isn't defined there, default_host is used.
- If that doesn't help, please run 'tcpdump -ni any' in the background
while running the test, and send the part of the log corresponding to
the time when "could not verify ..." messages appeared. There should be
arp requests in the log (e.g. "arp who-has ... tell ...").
2. rss.exe couldn't bind a port, which means something in the guest was
using port 22. Does this error occur consistently? If it does, you can
change the port used by rss.exe by editing setuprss.bat inside
winutils.iso. Before doing that you might want to make sure it's worth
the effort: manually run rss.exe inside the guest with a different port
('c:\rss.exe 10022') and see if rss.exe still complains.
(I assume you're using the standard winutils.iso and rss.exe. If you
happen to be using the new rss.exe that I posted a few days ago, the
error is expected because port 23 is used by telnet.)
_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
