On 11/14/2011 07:47 AM, Wizard wrote: > 2011/11/7 Lucas Meneghel Rodrigues<[email protected]>: >> On 11/07/2011 10:00 AM, Wizard wrote: >>> >>> 2011/11/7 Lucas Meneghel Rodrigues<[email protected]>: >>>> >>>> On 11/05/2011 12:54 PM, Wizard wrote: >>>>> >>>>> 2011/11/5 Lucas Meneghel Rodrigues<[email protected]>: >>>>>> >>>>>> On 11/05/2011 06:57 AM, Wizard wrote: >>>>>>> >>>>>>> 2011/11/4 Lucas Meneghel Rodrigues<[email protected]>: >>>>>>>> >>>>>>>> On 11/04/2011 12:49 PM, Wizard wrote: >>>>>>>>> >>>>>>>>> Lucas >>>>>>>>> >>>>>>>>> I read the tips for create a uptime test case for autotest. >>>>>>>>> >>>>>>>>> But I faced an error message. >>>>>>>>> >>>>>>>>> The config is : >>>>>>>>> ../../common_lib/cartesian_config.py tests.cfg >>>>>>>>> dict 1: smp2.CustomGuestLinux.uptime >>>>>>>>> >>>>>>>>> >>>>>>>>> The command of qemu is : >>>>>>>>> /usr/bin/qemu -name 'vm1' -nodefaults -vga std -monitor >>>>>>>>> unix:'/tmp/monitor-humanmonitor1-20111104-223259-kgX2',server,nowait >>>>>>>>> -serial unix:'/tmp/serial-20111104-223259-kgX2',server,nowait -drive >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> file='/home/richard/kvm/image/custom_image_linux',index=0,if=ide,cache=none >>>>>>>>> -device >>>>>>>>> rtl8139,netdev=idLRqDTg,mac='9a:64:5d:40:fb:fa',id='idsYMlt4' >>>>>>>>> -netdev tap,id=idLRqDTg,fd=22 -m 1024 -smp 2 -vnc :0 >>>>>>>>> >>>>>>>>> The error is: >>>>>>>>> MissingError: Cannot find IP address for MAC address >>>>>>>>> 9a:64:5d:40:fb:fa >>>>>>>>> [context: logging into 'vm1'] >>>>>>>> >>>>>>>> You probably want to connect on your vm's vnc session. This means >>>>>>>> your >>>>>>>> linux >>>>>>>> guest did not even try to get an IP from the DHCP server. >>>>>>>> >>>>>>>> vncviewer localhost:0 >>>>>>>> >>>>>>> I tried vncviewer :0 , and can see the guest starts up and logged in >>>>>>> successfully. >>>>>>> >>>>>>>> Also, kvm autotest produces screenshots, that go into >>>>>>>> client/results/default/[your test name]screendumps_vm1. As this is a >>>>>>>> custom >>>>>>>> image, it's very hard to tell what is going wrong, but usually means >>>>>>>> the >>>>>>>> boot got stuck somewhere and your linux guest did not bring up a >>>>>>>> newtork >>>>>>>> interface. >>>>>>>> >>>>>>> >>>>>>> But the autotest finally failed with the message above. >>>>>>> I guess this error is printed when autotest client try to connect >>>>>>> guest through ssh >>>>>>> session. >>>>>> >>>>>> Well, just to cover all bases - is the guest configured to pick an IP >>>>>> address from a DHCP server, or it's configured with static IP and DNS? >>>>>> When >>>>>> you say logged in, you probably mean "I can see a getty login prompt", >>>>>> which >>>>>> doesn't mean much for KVM autotest remote session. >>>>>> >>>>> You are right. The guest use static ip address. >>>>> >>>>> But, one curious thing is after I change the sysconfig file. >>>>> I use "qemu rhel.img" to bootup, log in, I can see the ip address of >>>>> 10.0.2.15. >>>>> While I use autotest, I use vnc to view the guest, I don't see the >>>>> interface is up. >>>> >>>> Because KVM autotest uses TAP, and your command, qemu rhel.img, makes >>>> qemu >>>> use userspace networing. Userspace (also known as slirp) means qemu will >>>> provide an internal network for the guest, with a built in DHCP server. >>>> 10.0.2.1 is the DHCP server, and your guest will be assigned a DHCP >>>> address >>>> on this range. Therefore, by default with KVM autotest you will not see >>>> this >>>> interface up. >>>> >>>> Slirp suffers from bugs that can potentially crash qemu, so it's not a >>>> supported and/or reliable option, and that is why KVM autotest provides >>>> TAP >>>> by default. >>>> >>> Ok, it use two different network mode. While, how could I make the >>> guest in the KVM autotest to have an ip address? >>> >>> What should I config? >>> >>> The libvirt is running and virbr0 is up. >>> The guest is configured with dhcp enabled. >> >> Then you just have to make sure the password is the same as the password KVM >> autotest expects, which is 123456, as stated on the config file >> guest-os.cfg. Also, another thing that would be reasonable to expect is that >> sshd is up and listening on port 22 and firewall allow access to that >> service. >> >> It seems you are using RHEL, so SELinux might play some pranks on you, >> although it is hard to anticipate all things that could go wrong. but well, >> if you check the things I stated on the first sentence, I believe it will >> work. >> > Hmm... After the client strat up, I log in the guest and see the sshd > is running and I stop the iptables. > Still get the same error message. > > I should disable the iptables at boot?
That's a good idea. > BTW, I log in the guest, but see no ip address for eth0. So try again with firewall disabled. _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
