On 2011-04-15,at 11:24:44, Lucas Meneghel Rodrigues wrote: >发送日期：2011-04-15 11:24:44 >收件人：wuyu8242 >抄送： >主题：Re: Re: [Autotest] About the mac addr and ip addr >> >2011/4/15 Lucas Meneghel Rodrigues <[email protected]>: >> 2011/4/15 wuyu8242 <[email protected]>: >>> On 2011-04-14,at 20:11:09, Lucas Meneghel Rodrigues wrote: >>> >>>>发送日期：2011-04-14 20:11:09 >>>>收件人：wuyu8242 >>>>抄送： >>>>主题：Re: [Autotest] About the mac addr and ip addr >>>>> >>>>2011/4/13 wuyu8242 <[email protected]>: >>>>> hi Lucas, Amos, >>>>> >>>>> Disturbing you！There are some issues about network test. About the mac >>>>> addr >>>>> and ip addr, the result of ifconfig include eth0 and eth1, the eth0 has no >>>>> ip address, the eth1 has a ip: 10.0.2.25, but the conf file of eth1 is not >>>>> in the folder of network-scripts. When i login to OS via vncvier and >>>>> modify >>>>> the eth0 conf file to which adding a static ip address, but after reboot >>>>> system by autotest, the static ip did not work. So, I want to know how the >>>>> mac and ip work? It seems that the mac and ip is random generated in code. >>>> >>>>MAC is fixed per VM instance, so as soon as a given object is >>>>destroyed (say, if you run kvm autotest with the same installed VM >>>>more than once), it'll generate another MAC. >>>> >>>>When the guest OS sees another MAC, it thinks there's a new network >>>>card attached to the system, so it'll leave eth0 configured (in case >>>>the user 'plugs' the 'old' network card again) and then auto >>>>configures a new eth1, eth2, ... so on and so forth for each new VM >>>>instance. >>> yes, this truth is indeed as you said, but why the ip is always 10.0.2.15? >>> and the ip cannot connect other ip such as my host ip？ >>> and how to set the ip to connect other ip? now, I want the guest can >>> connect other host. >> >> So, let's set the record straight - You *have* to setup tap mode. >> >> 1) Go to tests_base.cfg. locate this part: >> >> # NIC parameters >> nic_mode = user >> #nic_mode = tap >> nic_script = scripts/qemu-ifup >> #nic_script = scripts/qemu-ifup-ipv6 >> run_tcpdump = yes >> >> And make sure nic_mode = tap, uncommenting the line that says nic_mode >> = user and uncommenting nic_mode = tap. >> >> 2) Make sure you have a working bridge that allows access to your >> lab's DHCP server. The scripts/qemu-ifup will list the first bridge >> brctl can find and use it. >> *If you need to use another bridge, please change the script, which is >> under client/tests/kvm/scripts.* >> >> And that's that. No more 10.0.2.15, ever. >> >>>>With userspace networking this should not be a problem, as there is a >>>>built in DHCP server in qemu. Why do you want to use a fixed IP >>>>address? >>> I only want the guest can connect other host, so I don't want to use a >>> fixed IP address. Beacause the userspace networking only get the 10.0.2.15, >>> I try to use a fixed IP. >>> my command line as following: >>> /usr/bin/qemu-kvm -name 'vm1' -monitor >>> unix:'/tmp/monitor-humanmonitor1-20110411-062101-hWQJ',server,nowait >>> -serial unix:'/tmp/serial-20110411-062101-hWQJ',server,nowait -drive >>> file='/tmp/kvm_autotest_root/images/f11-64.qcow2',index=0,if=ide,cache=none >>> -net nic,vlan=0,model=rtl8139,macaddr='9a:a3:23:b0:e0:d0',id='idsLxMpu' >>> -net user,vlan=0 -m 512 -smp 2 -redir tcp:5000::22 -vnc :0 >>> >>> Is there a problem or not? >>> >>>>If you are using TAP mode, then you need to ensure there is a DHCP >>>>server ready to serve the VM, and that is it. This is how we work on >>>>our laboratory, the lab has a DHCP server. >>> yes, my lab has a dhcp server, and the same img started by virt-manager >>> tool can get a ip from the dhcp, but when start this imag by autotest, the >>> ip is 10.0.2.15 not a ifrom dhcp server. Why? >> >> 10.0.2.15 is an IP provided by the built in DHCP server on qemu, so it >> *is* from a DHCP server, just not the one you want. If you are using >> TAP, this IP should not be assigned at all. See instructions below. > >^ Ops, where it reads 'below' it should be 'above'. > Admire your careful !!
Thanks Lucas! >> >>>>About VNC, sometimes the port 5900 is occupied when autotest checks, >>>>so it'll use 5901, 5902 and so on and so forth. You need to check >>>>which vnc port is being used here. >>> sorry, I did not make it clear that the problem, my means is that I found >>> the desktop of guest cannot be start after the code were updated. My >>> operation as following: >>> 1. update code via command of "git pull" after your patch mail. >>> 2. run the new code to setup a new img of guest >>> 3. boot the guest >>> 4. start vnc to login the guest >>> by far, the desktop of guest don not start, only start a text terminal. >> >> Well, the Fedora guests kickstart files are fairly minimum installs, >> with no X and gnome and whatever. So that's exactly the way it should >> be. If you had graphical interface on your previous Fedora guests, >> then either of one: >> >> 1) You have installed it via yum *after* install by kvm autotest >> 2) You have a a guest you installed manually >> >> The only things that do boot in full graphical mode are obviously >> windows, and OpenSUSE. So what you are seeing is not a result of the >> upgrade, it's the way it's been working for the last couple of years. >> If you want gnome and all that stuff you can just add the right >> packages at the appropriate kickstart file. >> >> >> -- >> Lucas >> > > > >-- >Lucas > ------------------ wuyu8242 2011-04-15 _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
