Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 158899 - Unable to 'xm restore' domU
Unable to 'xm restore' domU
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Rik van Riel
Depends On: 158895
  Show dependency treegraph
Reported: 2005-05-26 13:20 EDT by AJ Lewis
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-16 15:03:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix result check of xm_domain_create in xm_linux_restore (934 bytes, patch)
2005-06-21 04:17 EDT, Michael Paesold
no flags Details | Diff

  None (edit)
Description AJ Lewis 2005-05-26 13:20:21 EDT
Description of problem:
trying to 'xm restore' a domU fails

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Get a domain started
2. Make sure /var/lib/xen/xen-db/migrate exists (see bug #158895)
3. run 'xm save domainname filename'
4. run 'xm restore filename'
Actual results:
Error: errors: transfer daemon (xfrd) error: 1

Expected results:
Domain starts up again.

Additional info:

There is plenty of free memory.
# xm info
system                 : Linux
host                   : iridium.msp.redhat.com
release                : 2.6.11-1.1363_FC4xen0
version                : #1 SMP Wed May 25 20:05:47 EDT 2005
machine                : i686
cores                  : 1
hyperthreads_per_core  : 2
cpu_mhz                : 2994
memory                 : 1015
free_memory            : 734

from /var/log/xfrd.log:
(xfr.hello 1 0)[DEBUG] Conn_sxpr< err=0
[DEBUG] Conn_sxpr>
(xfr.restore /root/oxygen.xen)[DEBUG] Conn_sxpr< err=0
[1117127623.161189] xc_linux_restore start

xc_linux_restore start
Could not create domain. pfns=65536, 262144KB
Could not create domain. pfns=65536, 262144KB
3397 [INF] XFRD> Xfr service err=1

and from /var/log/xend.log:
[2005-05-26 12:13:43 xend] INFO (XendMigrate:421) restore BEGIN: ['restore',
['id', '10'], ['file', '/root/oxygen.xen']]
[2005-05-26 12:13:43 xend] INFO (XendRoot:112) EVENT> xend.restore ['begin',
['restore', ['id', '10'], ['file', '/root/oxygen.xen']]]
[2005-05-26 12:13:43 xend] ERROR (SrvBase:163) op=restore: errors: transfer
daemon (xfrd) error: 1
[2005-05-26 12:13:43 xend] INFO (XendMigrate:440) Restore ERROR: ['restore',
['id', '10'], ['file', '/root/oxygen.xen']]
[2005-05-26 12:13:43 xend] INFO (XendRoot:112) EVENT> xend.restore ['error',
['restore', ['id', '10'], ['file', '/root/oxygen.xen']]]
Comment 1 Rik van Riel 2005-05-26 13:37:36 EDT
Is the guest domain SMP or ballooned ?

In that case it's a known limitation of the upstream Xen code base.
Comment 2 AJ Lewis 2005-05-26 14:13:26 EDT
The guest domain is neither SMP, nor ballooned.
Comment 5 AJ Lewis 2005-05-26 14:22:49 EDT
Also, I get the same error with an 'xm migrate domain localhost'
Comment 6 Rik van Riel 2005-05-30 10:54:37 EDT
This is probably an artifact of being unlucky in chosing a snapshot of
xen-unstable.  With some luck it will be fixed next time I rebase.

I need to have a better set of tests to run before releasing an RPM...
Comment 7 Michael Paesold 2005-06-20 16:54:29 EDT
Right, this is just an artifact. Could you either get a new shapshot or fix this 
bug by correcting the check in xm_linux_restore?
Comment 8 Rik van Riel 2005-06-20 17:01:44 EDT

would you happen to know which patch I need to apply to make this work?

Once I've gathered up a set of bugfixes, I'll probably create an updated Xen RPM
for FC4.
Comment 9 Michael Paesold 2005-06-21 01:58:12 EDT
(In reply to comment #8)

There are two options, I guess. Either I can produce a very local patch myself 
for the given snapshot, or you could look at the changesets in the BK repository 
and pick up some limited changesets from there. Unfortunately the code there was 
not just fixed but rather reworked in structure. So I guess I will have a go and 
create a patch. You can then decide what direction to take.
Comment 10 Michael Paesold 2005-06-21 04:17:41 EDT
Created attachment 115736 [details]
Fix result check of xm_domain_create in xm_linux_restore

I have tested the attached patch. xm restore now executes completely.
Nevertheless there are still other problems. When connecting with "xm console"
after the restore, this is output:

Debug: sleeping function called from invalid context at mm/slab.c:2126
in_atomic():0, irqs_disabled():1
 [<c0150c87>] __kmalloc+0xe7/0x100
 [<c01a5a75>] proc_create+0xb5/0x130
 [<c0117058>] try_to_wake_up+0x98/0x330
 [<c01a5bdf>] proc_mkdir_mode+0x2f/0x70
 [<c01a5c40>] proc_mkdir+0x20/0x30
 [<c0146a65>] register_handler_proc+0xc5/0xf0
 [<c014608e>] setup_irq+0xae/0x110
 [<c010613c>] ctrl_if_resume+0xfc/0x110
 [<c0107052>] __do_suspend+0x192/0x1e0
 [<c012ff93>] worker_thread+0x1b3/0x270
 [<c01071b0>] __shutdown_handler+0x0/0x50
 [<c0119120>] default_wake_function+0x0/0x20
 [<c012fde0>] worker_thread+0x0/0x270
 [<c01348b8>] kthread+0xc8/0xd0
 [<c01347f0>] kthread+0x0/0xd0
 [<c01081ed>] kernel_thread_helper+0x5/0x18

Perhaps upgrading to a new snapshot is an option, at least for the
"development" repository of fedora?
Comment 11 Michael Paesold 2005-06-21 04:36:22 EDT
Forgot to mention: despite the error message, the restored domain seems to work 
correctly afterwards.

Note You need to log in before you can comment on or make changes to this bug.