Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 158899

Summary: Unable to 'xm restore' domU
Product: [Fedora] Fedora Reporter: AJ Lewis <alewis>
Component: xenAssignee: Rik van Riel <riel>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: joe.ammond, mpaesold
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-16 19:03:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 158895    
Bug Blocks:    
Description Flags
Fix result check of xm_domain_create in xm_linux_restore none

Description AJ Lewis 2005-05-26 17:20:21 UTC
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                   :
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 17:37:36 UTC
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 18:13:26 UTC
The guest domain is neither SMP, nor ballooned.

Comment 5 AJ Lewis 2005-05-26 18:22:49 UTC
Also, I get the same error with an 'xm migrate domain localhost'

Comment 6 Rik van Riel 2005-05-30 14:54:37 UTC
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 20:54:29 UTC
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 21:01:44 UTC

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 05:58:12 UTC
(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 08:17:41 UTC
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 08:36:22 UTC
Forgot to mention: despite the error message, the restored domain seems to work 
correctly afterwards.