Peculiar errors with libvirt/virt-manager/xen in F18

[Major Hayden]

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

[M A Young]

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

[Major Hayden]

On Feb 8, 2013, at 6:11 PM, M A Young <m.a.young(a)durham.ac.uk&gt; 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

[Dario Faggioli]

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&gt;
> 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)

[Daniel P. Berrange]

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&gt; 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 :|

[Dario Faggioli]

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)

[Daniel P. Berrange]

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 :|

[Dario Faggioli]

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)

[M A Young]

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

[Dario Faggioli]

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)

[M A Young]

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

[M A Young]

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

[Dario Faggioli]

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)

[Dario Faggioli]

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)

[Dario Faggioli]

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)

[Dario Faggioli]

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)

[Dario Faggioli]

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)

[Major Hayden]

On Feb 11, 2013, at 11:54 AM, Dario Faggioli <raistlin(a)linux.it&gt; 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

[Dario Faggioli]

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&gt; 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)

[Dario Faggioli]

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)