Question
Question: Choose system> Administration> System
Go to the resource manager in the monitor menu and view the network in the resource bar.
The stored Ed and sent in history all transmit data at hundreds of megabytes, And the dom0 crashes. The MAC address and IP address of the eth0 Nic suddenly disappear.
An eth1 Nic is displayed. The newly started Virtual Machine Communication Interface vif1.0 is not displayed.
The above is the performance on my computer. My computer is centos5.2, runlevel 5, xen3.1 installed from centos5.5 ISO, IP
10.60.56.90. No information is seen in xend. Log, xend-debug.log, XM dmesg.
Same
When a VM is started on 10.60.56.220 in the LAN, it is found that the whole LAN cannot access the Internet. The eth0 Nic information of 10.60.56.220 disappears, and an additional IP address is displayed.
Eth1 Nic. What I learned from 10.60.56.220 is that vif0.0 has ed packet with own address.
As source address error message.
The problem occurred about two or three days ago (). Before the problem occurred, the VM was started.
This is a problem. The environment has been self-configured and has not been changed. The LAN environment, and other laboratories in the grid computing direction do not have such an environment. Other laboratories generally use Windows, most of which are students.
It is not likely to be a virus when used by the instructor.
Get the error message "vif0.0 already ed packet with own address
As source
Address "go to Google, find some web pages, and find a patch sent by xen, but the error still persists after the patch. These web pages basically say this is
Network configuration problems are not xen problems.
It was also good to start the virtual machine for a long time before the problem occurred. In addition, I had to reinstall xen of other versions after the problem occurred on my computer. The xen of 10.60.56.220 was installed
The xen in the OS CD also has problems when starting the virtual machine. It can be confirmed that this is indeed not a problem with xen.
Remove the NIC of the VM. Nic is not configured. The problem is still the same, but it will not cause the dom0 to crash. During the VM startup process, you can see:
Xenbus: Device with no driver: device/vbd/51712
Xenbus: Device with no driver: device/vbd/51729
Xenbus: Device with no driver: device/vbd/51731
Xenbus: Device with no driver: device/vbd/51730
Xenbus: Device with no driver: device/VIF/0
Xenbus: Device with no driver: device/VIF/1
Information.
Looking at/var/log/xen/xend. Log, we found that 51729 is config. IMG and 51712 is EVC. IMG,
When XM des 3 shuts down the virtual machine, the resource manager can see that the network is normal. Therefore, make sure this is caused by the virtual machine configuration when the virtual machine is started.
From the virtual machine configuration file ~ Remove all virtual network cards from the test/VM. xen. conf file. In the vmconfig file of config. IMG, also remove the network card information used by EVC.
And then start the VM. The resource manager always works normally. It seems that it is a problem caused by Virtual Machine network configuration.
So in the virtual machine configuration file ~ Only one virtual network card is configured in test/VM. xen. conf:
VIF = ["bridge = xenbr0"]
Restart the VM.
There is no problem with one network card, and there should be no problem with multiple such network cards, so add a parameter to this network card:
VIF = ["bridge = xenbr0, vifname = eth0"]
Start again, and the problem occurs again.
The performance should be caused by the vifname parameter.
Therefore, the configuration file is restored to the configuration created in the initial EVC, and vmconfig in config. IMG is also restored to the configuration at the time when the initial EVC was created. And delete
All vifname parameters in VM. xen. conf are restarted.
Now let's see why vifname causes such a serious problem.
XM -- help_config
The command lists available configuration parameters. The VIF configuration format is as follows:
VIF = type, MAC = Mac, bridge = bridge, IP = ipaddr, script = script, backend = Dom, vifname = Name
Add a network interface with the given MAC address
And Bridge.
The VIF is configured by calling the given
Configuration script.
If type is not specified, default is netfront not
Ioemu device.
If Mac is not specified a random MAC address is used.
If not specified then the network backend chooses
It's own MAC address.
If bridge is not specified the first bridge found is
Used.
If script is not specified the default script is
Used.
If backend is not specified the default backend
Driver domain is used.
If vifname is not specified the backend virtual
Interface will have name vifd. n
Where D is the domain ID and N is the interface ID.
This option may be repeated to add more than one VIF.
Specifying vifs will increase the number
Interfaces as needed.
The IP address is just like this. To set the Virtual Machine IP address, You need to log on to the virtual machine and use the specific operating system interface to set the IP address. If vifname is specified, the format should be vifd. n.
.
Lessons learned:
1)
Make sure that the server is not cut by mistake. The cause of the above problem is that the xen document is not carefully read. In this case, you can write the code. The result is that you write the code based on your understanding, enable generation
The error configuration file generated by the Code takes two or three days to solve the problem. You must be accurate and correct. Simply seeking for speed will lead to a lot of similar issues.
The above problems are very difficult to find out after these problems arise. Such projects will become more and more frustrated.
2) Do not "start from scratch" in case of problems ". "Start from scratch" was once regarded as a magic weapon to solve the problem.
3) rational analysis should not rely on feelings to determine whether the problem is complicated. If it is really difficult, it is really difficult to prove the problem with rational evidence.