|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] save and migrate fail
Hello Tom! First of all thanks for your help. Save, restore and migrate does work now! I think, I have found a bug in Version 2.0.6 Explanations: I have set up a domU, named xgps with the parameter memory = 1000 The result was that save and migrate did not work: The routine 'xc_linux_save' in file tools/libxc/xc_linux_save.c claimed: >> xc_linux_save start 2 >> Frame # in pfn-to-mfn frame list is not in pseudophys >> Frame # in pfn-to-mfn frame list is not in pseudophys and stopped When changing memory to 800 for this domU (memory=800) it worked. The OS of domU is debian sarge with standard kernel 2.6.8 During startup it claimed: only 8xx MByte will be used as there is no HIGHMEM configured in. Regards Reiner On Thu, 10 Nov 2005, Reiner Dassing wrote: >> Hi, Tom! >> >> Thanks for answering. >> Tom Brown wrote: >> >>>> > the trace isn't going to be of any help, as all the xm command does is >>> > send the save command to the daemon on port 8000, which sent back the >>> > message: >>> > >>> > errors: transfer daemon (xfrd) error: 1 >>> >>>> > tracing the daemon listening on port 8000 (may or may not be xfrd) might >>> > be more informative. > >> >> the strace to xfrd results in no suitable information: >> a child is forked, that's it. that is easily fixed by adding a -f to the strace command line... >> >> But in /var/log/xfrd.log I found: >> >> [DEBUG] Conn_sxpr> >> (xfr.hello 1 0)[DEBUG] Conn_sxpr< err=0 >> [DEBUG] Conn_sxpr> >> (xfr.save 2 "(domain (id 2) (name xgps) (memory 831) (maxmem 1000) >> (state -b---) (cpu 3) (cpu_time 1.127879316) (up_time 20.1359410286) >> (start_time 1131609926.52) (console (status listening) (id 15) (domain >> 2) (local_port 15) (remote_port 1) (console_port 9602)) (devices (vif >> (idx 0) (vif 0) (mac aa:00:00:19:ac:a7) (vifname vif2.0) (bridge >> xen-br0) (evtchn 17 4) (index 0)) (vif (idx 1) (vif 1) (mac >> aa:00:00:19:ac:a7) (vifname vif2.1) (bridge xen-br1) (evtchn 18 5) >> (index 1)) (vbd (idx 0) (vdev 2049) (device 2081) (mode w) (dev sda1) >> (uname phy:/dev/sdc1) (node /dev/sdc1) (index 0)) (vbd (idx 1) (vdev >> 2050) (device 2082) (mode w) (dev sda2) (uname phy:/dev/sdc2) (node >> /dev/sdc2) (index 1)) (vbd (idx 2) (vdev 2051) (device 2083) (mode w) >> (dev sda3) (uname phy:/dev/sdc3) (node /dev/sdc3) (index 2)) (vbd (idx >> 3) (vdev 2052) (device 2084) (mode w) (dev sda4) (uname phy:/dev/sdc4) >> (node /dev/sdc4) (index 3)) (vbd (idx 4) (vdev 2065) (device 2097) (mode >> w) (dev sdb1) (uname phy:/dev/sdd1) (node /dev/sdd1) (index 4)) (vbd >> (idx 5) (vdev 2066) (device 2145) (mode w) (dev sdb2) (uname >> phy:/dev/sdg1) (node /dev/sdg1) (index 5))) (config (vm (name xgps) >> (memory 1000) (image (linux (kernel /boot/vmlinuz-2.6.11-xenU) (root >> '/dev/sda1 ro'))) (device (vbd (uname phy:/dev/sdc1) (dev sda1) (mode >> w))) (device (vbd (uname phy:/dev/sdc2) (dev sda2) (mode w))) (device >> (vbd (uname phy:/dev/sdc3) (dev sda3) (mode w))) (device (vbd (uname >> phy:/dev/sdc4) (dev sda4) (mode w))) (device (vbd (uname phy:/dev/sdd1) >> (dev sdb1) (mode w))) (device (vbd (uname phy:/dev/sdg1) (dev sdb2) >> (mode w))) (device (vif (mac aa:00:00:19:ac:a7) (bridge xen-br0))) >> (device (vif (mac aa:00:00:19:ac:a7) (bridge xen-br1))))))" >> /tmp/xgps.save)[DEBUG] Conn_sxpr< err=0 >> [1131609946.667909] xc_linux_save start 2 >> >> xc_linux_save start 2 >> Frame # in pfn-to-mfn frame list is not in pseudophys >> Frame # in pfn-to-mfn frame list is not in pseudophys >> 2979 [INF] XFRD> Xfr service err=0 >> >> From the source xc_linux_save.c I found that this means: >> "a given machine frame number has no unique mapping in the guests >> pseudophysical map" that doesn't mean anything to me either... sorry. Is this XEN 2.0 or -unstable? >> As I am new to XEN I have no real idea what this could mean. >> The physical devices are mapped; there are on a SAN. >> >> >> Thanks for any help >> >> Reiner >> >> >> >> >> >> >> Reiner Dassing wrote: Hi, Tom! Thanks for answering. Tom Brown wrote:the trace isn't going to be of any help, as all the xm command does is send the save command to the daemon on port 8000, which sent back the message: errors: transfer daemon (xfrd) error: 1 tracing the daemon listening on port 8000 (may or may not be xfrd) might be more informative.the strace to xfrd results in no suitable information: a child is forked, that's it. But in /var/log/xfrd.log I found: [DEBUG] Conn_sxpr> (xfr.hello 1 0)[DEBUG] Conn_sxpr< err=0 [DEBUG] Conn_sxpr> (xfr.save 2 "(domain (id 2) (name xgps) (memory 831) (maxmem 1000) (state -b---) (cpu 3) (cpu_time 1.127879316) (up_time 20.1359410286) (start_time 1131609926.52) (console (status listening) (id 15) (domain 2) (local_port 15) (remote_port 1) (console_port 9602)) (devices (vif (idx 0) (vif 0) (mac aa:00:00:19:ac:a7) (vifname vif2.0) (bridge xen-br0) (evtchn 17 4) (index 0)) (vif (idx 1) (vif 1) (mac aa:00:00:19:ac:a7) (vifname vif2.1) (bridge xen-br1) (evtchn 18 5) (index 1)) (vbd (idx 0) (vdev 2049) (device 2081) (mode w) (dev sda1) (uname phy:/dev/sdc1) (node /dev/sdc1) (index 0)) (vbd (idx 1) (vdev 2050) (device 2082) (mode w) (dev sda2) (uname phy:/dev/sdc2) (node /dev/sdc2) (index 1)) (vbd (idx 2) (vdev 2051) (device 2083) (mode w) (dev sda3) (uname phy:/dev/sdc3) (node /dev/sdc3) (index 2)) (vbd (idx 3) (vdev 2052) (device 2084) (mode w) (dev sda4) (uname phy:/dev/sdc4) (node /dev/sdc4) (index 3)) (vbd (idx 4) (vdev 2065) (device 2097) (mode w) (dev sdb1) (uname phy:/dev/sdd1) (node /dev/sdd1) (index 4)) (vbd (idx 5) (vdev 2066) (device 2145) (mode w) (dev sdb2) (uname phy:/dev/sdg1) (node /dev/sdg1) (index 5))) (config (vm (name xgps) (memory 1000) (image (linux (kernel /boot/vmlinuz-2.6.11-xenU) (root '/dev/sda1 ro'))) (device (vbd (uname phy:/dev/sdc1) (dev sda1) (mode w))) (device (vbd (uname phy:/dev/sdc2) (dev sda2) (mode w))) (device (vbd (uname phy:/dev/sdc3) (dev sda3) (mode w))) (device (vbd (uname phy:/dev/sdc4) (dev sda4) (mode w))) (device (vbd (uname phy:/dev/sdd1) (dev sdb1) (mode w))) (device (vbd (uname phy:/dev/sdg1) (dev sdb2) (mode w))) (device (vif (mac aa:00:00:19:ac:a7) (bridge xen-br0))) (device (vif (mac aa:00:00:19:ac:a7) (bridge xen-br1))))))" /tmp/xgps.save)[DEBUG] Conn_sxpr< err=0 [1131609946.667909] xc_linux_save start 2 xc_linux_save start 2 Frame # in pfn-to-mfn frame list is not in pseudophys Frame # in pfn-to-mfn frame list is not in pseudophys 2979 [INF] XFRD> Xfr service err=0 From the source xc_linux_save.c I found that this means: "a given machine frame number has no unique mapping in the guests pseudophysical map" As I am new to XEN I have no real idea what this could mean. The physical devices are mapped; there are on a SAN. Thanks for any help Reiner _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |