Bug 771138 - xl create fails to create domain, gives unhelpful error messages
xl create fails to create domain, gives unhelpful error messages
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
16
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Xen Maintainance List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-01 17:06 EST by Robin Green
Modified: 2012-01-03 15:45 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-03 13:08:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xen config file (129 bytes, text/plain)
2012-01-01 17:08 EST, Robin Green
no flags Details

  None (edit)
Description Robin Green 2012-01-01 17:06:50 EST
Description of problem:
I learned that xen has a new CLI, xl, which is meant to replace xm, so because I had been encountering bugs with libvirt, I tried to use xl instead. However, I couldn't recreate the domain using my existing disk image - it only gets as far as pygrub asking me which kernel to boot before running into errors.

Version-Release number of selected component (if applicable):
xen-4.1.2-2.fc16.x86_64

How reproducible:
Always

Steps to Reproduce:
1. systemctl stop xend.service
2. Download attached config file F16.xen
3. xl create -c -d ~/F16.xen
  
Actual results:
VM should start and attach to console

Expected results:
After pygrub, I get:
libxl: error: libxl_dom.c:603:userdata_path unable to find domain info for domain 4: No such file or directory
cannot save config file: No such file or directory
libxl: error: libxl.c:711:libxl_domain_destroy non-existant domain 4
xenconsole: Could not read tty from store: No such file or directory

Additional information:
If I remember correctly, it was using /dev/xda before for the virtual disk inside the domU, but I had to change it to /dev/sda because xl didn't recognise /dev/xda as valid.
Comment 1 Robin Green 2012-01-01 17:08:17 EST
Created attachment 550169 [details]
xen config file
Comment 2 Robin Green 2012-01-01 17:21:00 EST
The real error is in xend.log:

[2012-01-01 21:28:07 27025] ERROR (XendDomain:447) Unable to recreate domain
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line 445, in _refreshTxn
    new_dom = XendDomainInfo.recreate(dom, False)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 204, in recreate
    vmpath = vmpath)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 455, in __init__
    self._checkName(self.info['name_label'])
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 3518, in _checkName
    (" as domain %s" % str(dom.domid)) or ""))
VmError: VM name 'F16' already exists

Confusing - I thought that xl did not use xend.
Comment 3 Konrad Rzeszutek Wilk 2012-01-03 13:08:05 EST
It does not. That log is probably from the previous invocation when you tried to start it using xm.

You can easily verify that by removing the log files before you use 'xl'.

Anyhow the "libxl: error: libxl_dom.c:603:userdata_path unable to find domain info for domain 4: No such file or directory" could be:
 1)  a bug in pygrub - but I doubt it as I understand you tried it with 'xm' and it worked, right?
 2). xl is not getting the details from 'pygrub' as it simply does have the functionality to do that (b/c it is not implemented in the 4.1 version).

But either way, xl in 4.1 is in experimental phase, not yet fully baked. If you want to have a version that has features/fixes in it, I recommend you use the xen-unstable version. That will require you compile the xen-unstable toolstack and hypervisor by yourself.

So closing this bug as NETXTRELEASE. But if you try it with the xen-unstable version, and you see the same problem, then please post it on xen-devel and we can handle it there.

If however, it fails with 'xm' as well, then lets open a different bug with 'xm' and pygrub. Also make sure you have the latest version of Xen - MA Young added a bunch of fixes to pygrub.
Comment 4 Michael Young 2012-01-03 15:45:05 EST
It won't help with the error messages but there are two things to try to get xl working;
1. disable selinux beforehand (eg. by running setenforce 0 as root)
2. run xm or xl as root - I am not convinced either of them work as an ordinary user.

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