2:01 p.m.
Hey there,
I just installed Fedora 18 on one of my servers and installed xen, libvirt, and
virt-manager. When I tried to create my first VM with virt-manager, I received some libxl
errors which led me to this orange block of text:
http://wiki.xen.org/wiki/Fedora_Host_Installation#Installing_the_Virt_Tools
After removing libvirt-daemon-driver-libxl, I noticed that libvirt-daemon-xen was removed
along with it as a dependency. Creating VM's failed again with an error during the
hotplug of the vif. I decided to get a little more forceful:
yum -y install libvirt-daemon-xen
rpm -ev --nodeps libvirt-daemon-driver-libxl
I restarted the libvirtd daemon and now I'm creating VM's without any errors. Am
I alone on this one? I was about to pop something in Bugzilla for it but I figured
I'd ask the list just in case. If this belongs on the fedora-virt list, please throw
a large piece of furniture in my general direction and I'll try to remember next time.
;)
--
Major Hayden
6:11 p.m.
On Fri, 8 Feb 2013, Major Hayden wrote:
After removing libvirt-daemon-driver-libxl, I noticed that
libvirt-daemon-xen was removed along with it as a dependency. Creating
VM's failed again with an error during the hotplug of the vif. I
decided to get a little more forceful:
yum -y install libvirt-daemon-xen
rpm -ev --nodeps libvirt-daemon-driver-libxl
I restarted the libvirtd daemon and now I'm creating VM's without any
errors. Am I alone on this one? I was about to pop something in
Bugzilla for it but I figured I'd ask the list just in case. If this
belongs on the fedora-virt list, please throw a large piece of furniture
in my general direction and I'll try to remember next time. ;)
libvirt-daemon-xen is just a metapackage which pulls in packages you might
want to use when using libvirt with xen, so it will go if you remove
libvirt-daemon-driver-libxl but removing it doesn't change anything else.
I suspect it was the libvirt restart that fixed your problems.
Michael Young
3:30 p.m.
On Feb 8, 2013, at 6:11 PM, M A Young <m.a.young(a)durham.ac.uk> wrote:
libvirt-daemon-xen is just a metapackage which pulls in packages you
might want to use when using libvirt with xen, so it will go if you remove
libvirt-daemon-driver-libxl but removing it doesn't change anything else. I suspect it
was the libvirt restart that fixed your problems.
Michael Young
Thanks for that quick reply.
I went through the whole process on a new server this afternoon and Xen is running fine.
You're probably right about that libvirtd restart being the critical piece. Thanks
again for your hard work with Xen. ;)
--
Major Hayden
11:54 a.m.
On Sun, 2013-02-10 at 15:30 -0600, Major Hayden wrote:
On Feb 8, 2013, at 6:11 PM, M A Young <m.a.young(a)durham.ac.uk>
wrote:
> libvirt-daemon-xen is just a metapackage which pulls in packages you might want to
use when using libvirt with xen, so it will go if you remove libvirt-daemon-driver-libxl
but removing it doesn't change anything else. I suspect it was the libvirt restart
that fixed your problems.
>
> Michael Young
Thanks for that quick reply.
I went through the whole process on a new server this afternoon and Xen is running fine.
You're probably right about that libvirtd restart being the critical piece. Thanks
again for your hard work with Xen. ;)
Ok, so it seems the package we want (for now) to be installed is
libvirt-daemon-driver-xen, and not libvirt-daemon-xen... Does that
sounds right?
I'll update the Wiki page accordingly... Have you spotted any other
issues with it? If yes, feel free to point me to them (or register to
our wiki and fix them yourself! :-P).
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
noon
On Mon, Feb 11, 2013 at 06:54:16PM +0100, Dario Faggioli wrote:
On Sun, 2013-02-10 at 15:30 -0600, Major Hayden wrote:
> On Feb 8, 2013, at 6:11 PM, M A Young <m.a.young(a)durham.ac.uk> wrote:
>
> > libvirt-daemon-xen is just a metapackage which pulls in packages you might want
to use when using libvirt with xen, so it will go if you remove
libvirt-daemon-driver-libxl but removing it doesn't change anything else. I suspect it
was the libvirt restart that fixed your problems.
> >
> > Michael Young
>
> Thanks for that quick reply.
>
> I went through the whole process on a new server this afternoon and Xen is running
fine. You're probably right about that libvirtd restart being the critical piece.
Thanks again for your hard work with Xen. ;)
>
Ok, so it seems the package we want (for now) to be installed is
libvirt-daemon-driver-xen, and not libvirt-daemon-xen... Does that
sounds right?
No, people want to be installing 'libvirt-daemon-xen' in most
circumstances. This has deps to ensure that you have all the
"recommended" packages required to run libvirt + xen together.
libvirt-daemon-driver-xen, is just the bare minimum libvirt
driver and nothing else, so is not what users typically want.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
12:19 p.m.
On Feb 11, 2013, at 11:54 AM, Dario Faggioli <raistlin(a)linux.it> wrote:
Ok, so it seems the package we want (for now) to be installed is
libvirt-daemon-driver-xen, and not libvirt-daemon-xen... Does that
sounds right?
FWIW, my system is working perfectly with this package set:
# rpmquery --queryformat "%{NAME}\n" -a | egrep "libvirt|xen" |
sort
libvirt-client
libvirt-daemon
libvirt-daemon-config-network
libvirt-daemon-config-nwfilter
libvirt-daemon-driver-interface
libvirt-daemon-driver-lxc
libvirt-daemon-driver-network
libvirt-daemon-driver-nodedev
libvirt-daemon-driver-nwfilter
libvirt-daemon-driver-qemu
libvirt-daemon-driver-secret
libvirt-daemon-driver-storage
libvirt-daemon-driver-uml
libvirt-daemon-driver-xen
libvirt-python
xen
xen-hypervisor
xen-libs
xen-licenses
xen-runtime
Installing libvirt-daemon-xen brings in libvirt-daemon-driver-libxl as a dependency and
that's when things begin to break.
--
Major Hayden
3:13 a.m.
On Mon, 2013-02-11 at 18:00 +0000, Daniel P. Berrange wrote:
> Ok, so it seems the package we want (for now) to be installed
is
> libvirt-daemon-driver-xen, and not libvirt-daemon-xen... Does that
> sounds right?
No, people want to be installing 'libvirt-daemon-xen' in most
circumstances. This has deps to ensure that you have all the
"recommended" packages required to run libvirt + xen together.
libvirt-daemon-driver-xen, is just the bare minimum libvirt
driver and nothing else, so is not what users typically want.
Well, this is a very fair point, with the only issue being that, if you
install 'libvirt-daemon-xen', things break! :-(
How can we change that and make it work? Perhaps libvirt-daemon-xen
shouldn't bring in, as dependency, libvirt-daemon-driver-libxl, at least
not in versions where the libxl libvirt driver is known to be broken?
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
3:14 a.m.
On Mon, 2013-02-11 at 12:19 -0600, Major Hayden wrote:
On Feb 11, 2013, at 11:54 AM, Dario Faggioli
<raistlin(a)linux.it> wrote:
> Ok, so it seems the package we want (for now) to be installed is
> libvirt-daemon-driver-xen, and not libvirt-daemon-xen... Does that
> sounds right?
FWIW, my system is working perfectly with this package set:
# rpmquery --queryformat "%{NAME}\n" -a | egrep "libvirt|xen" |
sort
libvirt-client
libvirt-daemon
libvirt-daemon-config-network
libvirt-daemon-config-nwfilter
libvirt-daemon-driver-interface
libvirt-daemon-driver-lxc
libvirt-daemon-driver-network
libvirt-daemon-driver-nodedev
libvirt-daemon-driver-nwfilter
libvirt-daemon-driver-qemu
libvirt-daemon-driver-secret
libvirt-daemon-driver-storage
libvirt-daemon-driver-uml
libvirt-daemon-driver-xen
libvirt-python
xen
xen-hypervisor
xen-libs
xen-licenses
xen-runtime
Installing libvirt-daemon-xen brings in libvirt-daemon-driver-libxl as a dependency and
that's when things begin to break.
Yep, exact same thing here, on any Fedora installation from 16 to 18
that I was able to test up to now.
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
4:31 a.m.
On Tue, Feb 12, 2013 at 10:13:41AM +0100, Dario Faggioli wrote:
On Mon, 2013-02-11 at 18:00 +0000, Daniel P. Berrange wrote:
> > Ok, so it seems the package we want (for now) to be installed is
> > libvirt-daemon-driver-xen, and not libvirt-daemon-xen... Does that
> > sounds right?
>
> No, people want to be installing 'libvirt-daemon-xen' in most
> circumstances. This has deps to ensure that you have all the
> "recommended" packages required to run libvirt + xen together.
> libvirt-daemon-driver-xen, is just the bare minimum libvirt
> driver and nothing else, so is not what users typically want.
>
Well, this is a very fair point, with the only issue being that, if you
install 'libvirt-daemon-xen', things break! :-(
How can we change that and make it work? Perhaps libvirt-daemon-xen
shouldn't bring in, as dependency, libvirt-daemon-driver-libxl, at least
not in versions where the libxl libvirt driver is known to be broken?
The libxl driver should be disabled in Fedora versions whre it does
not work. AFAIK, that was already done, so libxl is only used when
built against newest Xen.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
4:48 a.m.
On Tue, 12 Feb 2013, Dario Faggioli wrote:
Well, this is a very fair point, with the only issue being that, if
you
install 'libvirt-daemon-xen', things break! :-(
How can we change that and make it work? Perhaps libvirt-daemon-xen
shouldn't bring in, as dependency, libvirt-daemon-driver-libxl, at least
not in versions where the libxl libvirt driver is known to be broken?
It seems to me this thread has been focussing on a work around for an
undisclosed problem rather than identifying what the problem actually is
and solving it, or coming up with a better workaround. Could someone
provide more details of exactly what happens and preferably submit
a bug report to http://bugzilla.redhat.com/ so it can be looked at
properly.
Michael Young
9:57 a.m.
On Tue, 2013-02-12 at 10:48 +0000, M A Young wrote:
It seems to me this thread has been focussing on a work around for an
undisclosed problem rather than identifying what the problem actually is
and solving it, or coming up with a better workaround.
Indeed, while identifying and fixing/helping to fix was my first and
main intent. I'm think this is still related to what we were discussing
here: https://bugzilla.redhat.com/show_bug.cgi?id=893699, although that
took so many different directions that it is now very difficult to make
any sense out of it!
If I'm not providing enough or good enough feedback and suggestions, I'm
sorry, but really, my primary concern is to see all this working! :-)
Could someone
provide more details of exactly what happens and preferably submit
a bug report to http://bugzilla.redhat.com/ so it can be looked at
properly.
Let me try (again), repeating all the steps, starting from a fresh F18
install. After that, we'll decide if we want to stick with 893699
bugzilla entry, or create a new one, or whatever else we want to do...
Ok, here I am.
1. Install F18
2. yum install xen
3. reboot
4. ps aux | grep xend [nothing found]
5. creating a domain with xl [_works_]
6. yum install libvirt-daemon-xen virt-manager virt-viewer \
python-virt-inst libvirt-daemon-config-network
7. rpm -qa | grep daemon-driver-libxl [yes, 0.10.2.3-1]
8. rpm -qa | grep daemon-driver-xen [yes, 0.10.2.3-1]
9. reboot (just in case!)
10. ps aux | grep xend [nothing found]
11. systemctl status libvirtd.service [active (running)]
12. start virt manager [connected to xen:// (I
can't see Dom0, but that
is fine, IIRC)]
13. ps aux | grep xend [nothing found]
14. creating a domain with xl [_works_]
15. creating a domain with virt-install [_DOES_NOT_ work (*)]
16. creating a domain with virt-manager [_DOES_NOT_ work (**)]
17. systemctl stop libvirtd.service
18. yum remove libvirt-daemon-driver-libxl
19. systemctl start libvirtd.service
20. ps aux | grep xend [nothing found]
21. start virt-manager [_COULD_NOT_ connect
to xen://]
22. sudo xend
23. start virt-manager [connected to xen://]
24. creating a domain with virt-install [_works_]
25. creating a domain with virt-manager [_works_]
26. creating a domain with xl [_works_ (**)]
27. reboot
28. ps aux | grep xend [nothing found]
29. start virt-manager [_COULD_NOT_ connect
to xen://]
30. creating a domain with virt-manager [_DOES_NOT_ work
(of course!)]
31. creating a domain with virt-install [_DOES_NOT_ work
(of course!)]
32. creating a domain with xl [_works_]
Ok, I think I'm done and I really hope this could be helpful!
It seems to me that:
1) if libvirt-daemon-driver-libxl is present, libxl driver is correctly
loaded, but it still has some bugs that prevent actually using it
2) if libvirt-daemon-driver-libxl is _not_ present we (I ?) are still
seeing at least some of the issues described in the 893699 bugzilla
above. Am I the only one seeing this? Who is supposed to start xend
and when should hat happen?
The net effect is that, right now, I can't use libvirt with Xen at all,
on F18, neither with -driver-libxl nor with -driver-xen... Again, am I
the only one?
(*) # virt-install -l
http://fedora.mirror.constant.com/linux/releases/18/Fedora/x86_64/os/ --ram 1024 --disk
/dev/vms/F18_x64 --name F18_x64
Starting install...
Retrieving file .treeinfo...
| 2.2 kB 00:00:00 !!!
Retrieving file vmlinuz...
| 9.3 MB 00:00:06 !!!
Retrieving file initrd.img...
| 53 MB 00:00:34 !!!
ERROR internal error libxenlight failed to create new domain 'F16_x64'
Domain installation does not appear to have been successful.
(**) It shouldn't. Starting from Xen 4.2 we have a check in xl that
looks for a lock file (by default in /var/lock/subsys/xend) and disallow
xl to do anything if xend is running. Here, the fact that I have to
started xend by hand messes that up. In fact, there should be an
initscript of some sort for xend... Where is it and what package is
supposed to provide it?
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
9:58 a.m.
On Mon, 2013-02-11 at 12:19 -0600, Major Hayden wrote:
FWIW, my system is working perfectly with this package set:
Ok, just one more question...
# rpmquery --queryformat "%{NAME}\n" -a | egrep
"libvirt|xen" | sort
libvirt-client
libvirt-daemon
libvirt-daemon-config-network
libvirt-daemon-config-nwfilter
libvirt-daemon-driver-interface
libvirt-daemon-driver-lxc
libvirt-daemon-driver-network
libvirt-daemon-driver-nodedev
libvirt-daemon-driver-nwfilter
libvirt-daemon-driver-qemu
libvirt-daemon-driver-secret
libvirt-daemon-driver-storage
libvirt-daemon-driver-uml
libvirt-daemon-driver-xen
libvirt-python
xen
xen-hypervisor
xen-libs
xen-licenses
xen-runtime
And with this configuration you have xend starting automatically either
at startup, or at libvirt startup, or when you first try to connect to
xen://, or something like that?
I mean, are you able to create VMs with virt-manager and/or virt-install
_without_ having to start xend by hand?
I'm asking because I'm not! :-(
Installing libvirt-daemon-xen brings in libvirt-daemon-driver-libxl
as a dependency and that's when things begin to break.
Yes, again, that is the same here, and I also see the libxenlight
related errors you where talking about. Problem is that, for me, just
removing libvirt-daemon-driver-libxl and restarting libvirtd is not at
all enough, as xend is not started...
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
10:03 a.m.
On Tue, 2013-02-12 at 10:31 +0000, Daniel P. Berrange wrote:
The libxl driver should be disabled in Fedora versions whre it does
not work. AFAIK, that was already done, so libxl is only used when
built against newest Xen.
Yes, I remember that being the plan. What I'm missing (well, one of the
things I'm missing) is whether libxl should be enabled or disabled in
F18.
Looking at it from a Xen POV, it should be enabled, because F18 ships
Xen 4.2, and libxl is the default toolstack for 4.2, while Xend is
formally deprecated. However, installing what we get with
libvirt-daemon-driver-libxl does not work, hence the confusion. :-/
Also, at least in my case, even _without_ libvirt-daemon-driver-libxl
and with _only_ libvirt-daemon-driver-xen, I can't use libvirt, as xend
does not starts properly, as it was used o do just a couple of months
ago (for sure it was starting in F16 and F17).
Hope this (and the other mails I sent) clarify the thing a bit... :-)
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
4:32 p.m.
On Tue, 12 Feb 2013, Dario Faggioli wrote:
On Tue, 2013-02-12 at 10:48 +0000, M A Young wrote:
> It seems to me this thread has been focussing on a work around for an
> undisclosed problem rather than identifying what the problem actually is
> and solving it, or coming up with a better workaround.
>
Indeed, while identifying and fixing/helping to fix was my first and
main intent. I'm think this is still related to what we were discussing
here: https://bugzilla.redhat.com/show_bug.cgi?id=893699, although that
took so many different directions that it is now very difficult to make
any sense out of it!
If I'm not providing enough or good enough feedback and suggestions, I'm
sorry, but really, my primary concern is to see all this working! :-)
> Could someone
> provide more details of exactly what happens and preferably submit
> a bug report to http://bugzilla.redhat.com/ so it can be looked at
> properly.
>
Let me try (again), repeating all the steps, starting from a fresh F18
install. After that, we'll decide if we want to stick with 893699
bugzilla entry, or create a new one, or whatever else we want to do...
Ok, here I am.
1. Install F18
2. yum install xen
3. reboot
4. ps aux | grep xend [nothing found]
5. creating a domain with xl [_works_]
6. yum install libvirt-daemon-xen virt-manager virt-viewer \
python-virt-inst libvirt-daemon-config-network
7. rpm -qa | grep daemon-driver-libxl [yes, 0.10.2.3-1]
8. rpm -qa | grep daemon-driver-xen [yes, 0.10.2.3-1]
9. reboot (just in case!)
10. ps aux | grep xend [nothing found]
11. systemctl status libvirtd.service [active (running)]
12. start virt manager [connected to xen:// (I
can't see Dom0, but that
is fine, IIRC)]
13. ps aux | grep xend [nothing found]
14. creating a domain with xl [_works_]
15. creating a domain with virt-install [_DOES_NOT_ work (*)]
Check /var/log/libvirt/libxl/libxl.log to see what went wrong. I have done
some testing and in my case it seems it defaults to trying the blktap
driver for disks, which won't work with the Fedora kernel. There may be
some way to get it to use file, phy or other driver as you can with an xl
configuration file, but I haven't found a way that works yet.
Michael Young
5:48 p.m.
On Tue, 12 Feb 2013, M A Young wrote:
> Let me try (again), repeating all the steps, starting from a
fresh F18
> install. After that, we'll decide if we want to stick with 893699
> bugzilla entry, or create a new one, or whatever else we want to do...
>
> Ok, here I am.
>
> 1. Install F18
> 2. yum install xen
> 3. reboot
> 4. ps aux | grep xend [nothing found]
> 5. creating a domain with xl [_works_]
> 6. yum install libvirt-daemon-xen virt-manager virt-viewer \
> python-virt-inst libvirt-daemon-config-network
> 7. rpm -qa | grep daemon-driver-libxl [yes, 0.10.2.3-1]
> 8. rpm -qa | grep daemon-driver-xen [yes, 0.10.2.3-1]
> 9. reboot (just in case!)
> 10. ps aux | grep xend [nothing found]
> 11. systemctl status libvirtd.service [active (running)]
> 12. start virt manager [connected to xen:// (I
> can't see Dom0, but that
> is fine, IIRC)]
> 13. ps aux | grep xend [nothing found]
> 14. creating a domain with xl [_works_]
> 15. creating a domain with virt-install [_DOES_NOT_ work (*)]
Check /var/log/libvirt/libxl/libxl.log to see what went wrong. I have done
some testing and in my case it seems it defaults to trying the blktap driver
for disks, which won't work with the Fedora kernel. There may be some way to
get it to use file, phy or other driver as you can with an xl configuration
file, but I haven't found a way that works yet.
Actually, in your case you could try --disk
path=/dev/vms/F18_x64,driver_name=phy . Unfortunately driver_name=file
doesn't work for a disk image file as it seems that uses blktap, which is
arguably a libvirt libxl driver bug.
Michael Young
5:50 a.m.
On Tue, 2013-02-12 at 22:32 +0000, M A Young wrote:
> 1. Install F18
> 2. yum install xen
> 3. reboot
> 4. ps aux | grep xend [nothing found]
> 5. creating a domain with xl [_works_]
> 6. yum install libvirt-daemon-xen virt-manager virt-viewer \
> python-virt-inst libvirt-daemon-config-network
> 7. rpm -qa | grep daemon-driver-libxl [yes, 0.10.2.3-1]
> 8. rpm -qa | grep daemon-driver-xen [yes, 0.10.2.3-1]
> 9. reboot (just in case!)
> 10. ps aux | grep xend [nothing found]
> 11. systemctl status libvirtd.service [active (running)]
> 12. start virt manager [connected to xen:// (I
> can't see Dom0, but that
> is fine, IIRC)]
> 13. ps aux | grep xend [nothing found]
> 14. creating a domain with xl [_works_]
> 15. creating a domain with virt-install [_DOES_NOT_ work (*)]
Check /var/log/libvirt/libxl/libxl.log to see what went wrong. I have done
some testing and in my case it seems it defaults to trying the blktap
driver for disks, which won't work with the Fedora kernel.
Same here, and using 'driver_name=phy' as you suggest in the other mail
works. I also agree we should point libvirt-libxl people to this (and I
will).
libxl: verbose: libxl_create.c:158:libxl__domain_build_info_setdefault: qemu-xen is
unavailable, use qemu-xen-traditional instead: No such file or directory
libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x7f784c0011a0: create: how=(nil)
callback=(nil) poller=0x7f784c001200
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda
spec.backend=tap
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=xvda, backend tap unsuitable
because blktap not available
libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no suitable backend for
disk xvda
libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x7f784c0011a0: complete, rc=-3
libxl: debug: libxl_create.c:1187:do_domain_create: ao 0x7f784c0011a0: inprogress:
poller=0x7f784c001200, flags=ic
libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x7f784c0011a0: destroy
Now, after having had small SELinux and bridging issues, I've got an
installation going... Let's see where it breaks! :-P
That being said, what do you think about the xend issues I was also
talking about in the original mail (which are more or less the same that
were already here https://bugzilla.redhat.com/show_bug.cgi?id=893699) ?
I'm talking about steps 18 to 32 there, where I say that I'm still not
able to get xend starting properly and automatically ? I'd really prefer
libxl to work and xend to "die", but until we're not there, I think we
should have at least one which is working! :-O
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
7:34 a.m.
On Wed, 2013-02-13 at 12:50 +0100, Dario Faggioli wrote:
That being said, what do you think about the xend issues I was also
talking about in the original mail (which are more or less the same that
were already here https://bugzilla.redhat.com/show_bug.cgi?id=893699) ?
I'm talking about steps 18 to 32 there, where I say that I'm still not
able to get xend starting properly and automatically ? I'd really prefer
libxl to work and xend to "die", but until we're not there, I think we
should have at least one which is working! :-O
Regarding this, I probably forgot to mention that, other than running
xend manually, I'm also trying to enable and start it properly:
xend.service - Xend - interface between hypervisor and some applications
Loaded: loaded (/usr/lib/systemd/system/xend.service; enabled)
Active: failed (Result: exit-code) since Wed 2013-02-13 14:26:23 CET; 3min 37s ago
Process: 1053 ExecStart=/usr/sbin/xend (code=exited, status=1/FAILURE)
Process: 983 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited,
status=0/SUCCESS)
Feb 13 14:26:21 localhost.localdomain systemd[1]: Starting Xend - interface between
hypervisor and some applications...
Feb 13 14:26:23 localhost.localdomain systemd[1]: xend.service: control process exited,
code=exited status=1
Feb 13 14:26:23 localhost.localdomain systemd[1]: Failed to start Xend - interface between
hypervisor and some applications.
Feb 13 14:26:23 localhost.localdomain systemd[1]: Unit xend.service entered failed state
And in journalctl, I see a bunch of:
Feb 13 14:26:11 localhost.localdomain systemd-udevd[653]: failed to execute
'/usr/lib/udev/socket:/org/xen/xend/udev_event'
'socket:/org/xen/xend/udev_event': No such file or directory
Feb 13 14:26:11 localhost.localdomain systemd-udevd[654]: failed to execute
'/usr/lib/udev/socket:/org/xen/xend/udev_event'
'socket:/org/xen/xend/udev_event': No such file or directory
Feb 13 14:26:11 localhost.localdomain systemd-udevd[655]: failed to execute
'/usr/lib/udev/socket:/org/xen/xend/udev_event'
'socket:/org/xen/xend/udev_event': No such file or directory
Feb 13 14:26:11 localhost.localdomain systemd-udevd[656]: failed to execute
'/usr/lib/udev/socket:/org/xen/xend/udev_event'
'socket:/org/xen/xend/udev_event': No such file or directory
Feb 13 14:26:11 localhost.localdomain systemd-udevd[657]: failed to execute
'/usr/lib/udev/socket:/org/xen/xend/udev_event'
'socket:/org/xen/xend/udev_event': No such file or directory
Feb 13 14:26:11 localhost.localdomain systemd-udevd[658]: failed to execute
'/usr/lib/udev/socket:/org/xen/xend/udev_event'
'socket:/org/xen/xend/udev_event': No such file or directory
Feb 13 14:26:11 localhost.localdomain systemd-udevd[659]: failed to execute
'/usr/lib/udev/socket:/org/xen/xend/udev_event'
'socket:/org/xen/xend/udev_event': No such file or directory
...
What can it be? SELinux perhaps (yes, I'm using it)? I'll try disabling
and see what happens.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
8:23 a.m.
On Wed, 2013-02-13 at 14:34 +0100, Dario Faggioli wrote:
What can it be? SELinux perhaps (yes, I'm using it)? I'll try
disabling
and see what happens.
Tried and yes, it was SELinux. I actually did not disabled it, but went
through a dozen of those 'audit2allow + semodule', and I can now enable
and start the service.
I'll update the documentation on the Xen Wiki.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
12:48 p.m.
On Tue, 2013-02-12 at 10:48 +0000, M A Young wrote:
It seems to me this thread has been focussing on a work around for an
undisclosed problem rather than identifying what the problem actually is
and solving it, or coming up with a better workaround. Could someone
provide more details of exactly what happens and preferably submit
a bug report to http://bugzilla.redhat.com/ so it can be looked at
properly.
Ok, I repeated all my usual domain creation tests and I can confirm this
is not an issue anymore:
https://bugzilla.redhat.com/show_bug.cgi?id=893699
and that, is xend.service is properly managed with systemctl and stuff,
everything works as expected.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
1:11 p.m.
On Tue, 2013-02-12 at 10:48 +0000, M A Young wrote:
It seems to me this thread has been focussing on a work around for an
undisclosed problem rather than identifying what the problem actually is
and solving it, or coming up with a better workaround. Could someone
provide more details of exactly what happens and preferably submit
a bug report to http://bugzilla.redhat.com/ so it can be looked at
properly.
I created this:
https://bugzilla.redhat.com/show_bug.cgi?id=912488
to track the libvirt-libxl issue I was also seeing and reporting in this
thread.
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
4085
days inactive
4095
days old
19 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Dario Faggioli -
M A Young -
Major Hayden