Let me also add that installing guests on F18-Beta Dom0 used to work last time I tried, a couple of months ago, right before the Virtualization Test Day (Nov 1st).
I'm sure it was xend that was being used, as libvirt's libxl driver was not ready at the time, and I explicitly installed the libvirt-daemon-xen package and removed/not installed the libvirt-daemon-driver-libxl package (which existed at the time).
And it all was out of the box, i.e., without the need of starting xend by hand, like it is now necessary.
Thanks,
Dario

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #3)
> > I don't have anything related to libvirt installed yet, let me try adding
> > them. I'll report back here what happens...
> >
> Ok, it looks like installing these packages managed in solving the issue! I
> did soemthing like this:
>
> # yum install libvirt-daemon-xen python-virtinst
> libvirt-daemon-config-network libvirt-daemon-driver-network virt-manager
>
> and I now (after rebooting) can see xend running:
>
> [...]
>
> Is all this to be expected?
>
Ok, thinking more about it, I think this I was saying above _is_ right. I mean, it is correct for xend to be started only when you install libvirt/virt-install/virt-manager (I don't exactly know who's responsible for this! :-D).
However, still on Fedora 17, I updated the virt-preview repository, and now I don't have xend automatically started any longer!
These means that this combination of packages:
libvirt-daemon-config-nwfilter-1.0.1-2.fc17.x86_64
libvirt-client-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-nwfilter-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-storage-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-network-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-secret-1.0.1-2.fc17.x86_64
libvirt-daemon-xen-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-nodedev-1.0.1-2.fc17.x86_64
libvirt-daemon-config-network-1.0.1-2.fc17.x86_64
libvirt-daemon-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-qemu-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-xen-1.0.1-2.fc17.x86_64
libvirt-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-interface-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-uml-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-lxc-1.0.1-2.fc17.x86_64
libvirt-python-1.0.1-2.fc17.x86_64
Has the same effect of this one:
# rpm -qa | grep libvirt
libvirt-daemon-driver-network-0.10.2.2-3.fc18.x86_64
libvirt-daemon-kvm-0.10.2.2-3.fc18.x86_64
libvirt-daemon-driver-uml-0.10.2.2-3.fc18.x86_64
libvirt-glib-0.1.4-1.fc18.x86_64
libvirt-daemon-driver-interface-0.10.2.2-3.fc18.x86_64
libvirt-daemon-qemu-0.10.2.2-3.fc18.x86_64
libvirt-0.10.2.2-3.fc18.x86_64
libvirt-client-0.10.2.2-3.fc18.x86_64
libvirt-daemon-driver-nodedev-0.10.2.2-3.fc18.x86_64
libvirt-daemon-driver-xen-0.10.2.2-3.fc18.x86_64
libvirt-gconfig-0.1.4-1.fc18.x86_64
libvirt-daemon-driver-secret-0.10.2.2-3.fc18.x86_64
libvirt-gobject-0.1.4-1.fc18.x86_64
libvirt-daemon-driver-qemu-0.10.2.2-3.fc18.x86_64
libvirt-daemon-driver-lxc-0.10.2.2-3.fc18.x86_64
libvirt-daemon-driver-nwfilter-0.10.2.2-3.fc18.x86_64
libvirt-daemon-config-network-0.10.2.2-3.fc18.x86_64
libvirt-daemon-xen-0.10.2.2-3.fc18.x86_64
libvirt-daemon-0.10.2.2-3.fc18.x86_64
libvirt-daemon-config-nwfilter-0.10.2.2-3.fc18.x86_64
libvirt-python-0.10.2.2-3.fc18.x86_64
libvirt-daemon-driver-storage-0.10.2.2-3.fc18.x86_64
which is not starting xend automatically.
If we assume that the responsible for this is libvirt-daemon-xen (is that right?), I think I can now say that libvirt-daemon-xen-0.9.11.8-2.fc17 does start xend automatically, while neither of libvirt-daemon-driver-xen-1.0.1-2.fc17.x86_64 or libvirt-daemon-xen-0.10.2.2-3.fc18.x86_64 does.
Thanks again,
Dario

(In reply to comment #8)
> Libvirt in rawhide should be able to talk to xl no problem. Libvirt in F18
> has backported packages but I'm waiting for some other bug fixes to
> accumulate before I push a build. Likely next week.
>
Ok, very nice to read that, thanks! I'll take some time (tomorrow) to test rawhide.
However, besides having a working libxl driver, which is great, I think libvirt-daemon-driver-xen should still start xend automatically, shouldn't it? So that, if one wants to use xend, he can install such package, while if he wants libxl, he can go for libvirt-daemon-driver-libxl (or whatever it is called)... Or am I misunderstanding how the whole thing is meant to be?
Anyway, I'll test this too on rawhide and report back, either here or on the list.
Thanks a lot for looking at this!
Dario

(In reply to comment #9)
> (In reply to comment #8)
> > Libvirt in rawhide should be able to talk to xl no problem. Libvirt in F18
> > has backported packages but I'm waiting for some other bug fixes to
> > accumulate before I push a build. Likely next week.
> >
>
> [...]
>
> Anyway, I'll test this too on rawhide and report back, either here or on the
> list.
>
Ok, here I am, a bit late as my testbox was otherwise engaged yesterday.
So, in rawhide, If in _do_ install libvirt-daemon-driver-xen and _do_not_ install libxl-daemon-driver-libxl, xend is automatically loaded and I can create guests with both virt-inst and virt-manager, which is good. :-)
However, if I do the opposite, i.e., I _do_not_ install (well, remove) libvirt-daemon-driver-xen and _do_install libvirt-daemon-driver-libxl, virt-inst and virt-manager stops working.
In fact, virt-inst does not even try:
# virt-install -l http://fedora.mirror.constant.com/linux/development/18/x86_64/os/ --ram 1024 --disk /dev/vms/F18_x64 --name F18_x64
WARNING KVM acceleration not available, using 'qemu'
While this is what virt-manager tells me, after failing to connect to XEN:
Unable to connect to libvirt.
internal error libxenlight state driver is not active
Verify that:
- A Xen host kernel was booted
- The Xen service has been started
Libvirt URI is: xen:///
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 1027, in _open_thread
self.vmm = self._try_open()
File "/usr/share/virt-manager/virtManager/connection.py", line 1009, in _try_open
flags)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: internal error libxenlight state driver is not active
Might be worth to say that xend seems to be still being run automatically:
# ps aux | grep xend
root 1770 0.4 0.2 838656 23672 ? SLl 11:04 0:05 /usr/bin/python -Es /usr/sbin/xend status
and that I seem to be able to create guests manually with `xl create'.
Is all the above supposed to happen / am I doing something wrong?

(In reply to comment #10)
> While this is what virt-manager tells me, after failing to connect to XEN:
> Unable to connect to libvirt.
>
> internal error libxenlight state driver is not active
The libxl driver did not load.
> Might be worth to say that xend seems to be still being run automatically:
> # ps aux | grep xend
> root 1770 0.4 0.2 838656 23672 ? SLl 11:04 0:05
> /usr/bin/python -Es /usr/sbin/xend status
Is it? That looks to be a status check only. But if xend is running, the libxl driver will not load.
Are there any messages in the libvirtd logs that indicate why the libxl driver refused/failed to load?

I have noticed before that libvirt does a status check by calling xend during start up. Unfortunately the process seems to stick around if xend isn't otherwise running, though I haven't got around to working out why and if it is worth fixing.

By the way, to get a log, change "log_level" to 1 in /etc/libvirt/libvirtd.service and then view the logs by running:
sudo journalctl -u libvirtd.service
(assuming libvirt was started by systemd, of course)

Sorry for the noise in the previous comments. I was wrong about libxl working. I did quite a few tests with libxl and here are the results:
1. libvirt-daemon-driver-libxl always requires libvirt-daemon-driver-xen. This was my setup. As soon as I remove the xen driver, I get "internal error libxenlight state driver is not active" as other have gotten above.
2. That "/usr/bin/python -Es /usr/sbin/xend status" in ps is deceiving. Try starting libvirt, run "virsh -c xen:///", and notice how "xm info" works. Now kill that xend status process and watch how "xm info" fails. Running that command in a terminal returns the xend status. But when libvirt runs it, the actual xend daemon is started. *This explains why the status checking process never exits.*
3. Knowing that xl doesn't require xend, I replaced /usr/sbin/xend with:
#!/bin/bash
exit 0
virsh (with xen and libxl driver installed) fails with "unable to connect to 'localhost:8000': Connection refused", which is a xen message, not a libxl message. It means that libxl is falling back to the xen driver.

Have you started any domains with the driver? Like the qemu driver, the libxl driver ignores the host (domain 0), so unless you have persistent domains defined 'virsh list' will show nothing. 'virsh list --all' will show persistent domains that are inactive.
Does 'virsh version' report the libxl driver active? E.g.
# virsh version
Compiled against library: libvirt 1.0.1
Using library: libvirt 1.0.1
Using API: xenlight 1.0.1
Running hypervisor: xenlight 4.3.0
BTW, the libxl driver currently does not support managing out-of-band domains, e.g. those created through libxl.

(In reply to comment #25)
> If by persistent, you mean VMs created using libvirt (as opposed to "xl
> create"), then yes, none of my persistent VMs show up. 'virsh -c xen:///
> list --all' shows nothing.
By persistent, I mean domains that still exist when they are inactive. Persistent domains are also known as define domains, and managed domains. You create a persistent domain with 'virsh define', start it with 'virsh start', shut it down with 'virsh shutdown', and remove it entirely with 'virsh undefine'. By contrast, transient (aka ephemeral, unmanaged) domains are no longer known to libvirt once they are shutdown.
> I've tried creating a PVM Debian DomU, but unfortunately, that fails too.
> Here's the libvirt log: http://paste.kde.org/653372/raw/ Whatever that error
> is, it completely killed the libvirt daemon: http://paste.kde.org/653384/raw/
Looks like you are hitting some of the issues (segfaults, asserts in libxl or pthreads) addressed by this patchset for the libxl driver
https://www.redhat.com/archives/libvir-list/2013-January/msg01463.html
and these patches for libxl
http://lists.xen.org/archives/html/xen-devel/2012-12/msg00684.htmlhttp://lists.xen.org/archives/html/xen-devel/2012-12/msg00685.html> I see that you're running Xen 4.3.0. Would you like me to compile Xen from
> git/hg? Would libvirt need to be recompiled against the new Xen?
I haven't tested this on a 4.2.x system yet, but need to do so before committing the libvirt patches, which are awaiting review btw :).

(In reply to comment #26)
> I haven't tested this on a 4.2.x system yet, but need to do so before
> committing the libvirt patches, which are awaiting review btw :).
I have now tested the patches on 4.2.1 and didn't notice any problems. By patches, I mean the libvirt *and* libxl ones mentioned in #26.

(In reply to comment #29)
> (In reply to comment #26)
> > I haven't tested this on a 4.2.x system yet, but need to do so before
> > committing the libvirt patches, which are awaiting review btw :).
>
> I have now tested the patches on 4.2.1 and didn't notice any problems. By
> patches, I mean the libvirt *and* libxl ones mentioned in #26.
Awesome. I'll try it on Fedora's Xen 4.2.1 and libvirt 1.0.1.

(In reply to comment #29)
> (In reply to comment #26)
> > I haven't tested this on a 4.2.x system yet, but need to do so before
> > committing the libvirt patches, which are awaiting review btw :).
>
> I have now tested the patches on 4.2.1 and didn't notice any problems. By
> patches, I mean the libvirt *and* libxl ones mentioned in #26.
>
Very cool!
So, Jim, now it would be awesome if we could get all these patches into F18, as an update to the Xen and libvirt package, I guess. What do we need for that? My impression is that the libxl patches need to be backported to some 4.2.X Xen version... Have you already discussed this with the guys on xen-devel? Should you need any help (provided you think this is The Right Thing), do not hesitate to ask.
On the libvirt side, I think we just need to be sure you get the patch upstream, and then wait for an update of that package too. Do you mind letting me/us (either here or via e-mail) know when that happen (I mean, patches upstream)?
Thanks and Regards, Dario

(In reply to comment #8)
> Libvirt in rawhide should be able to talk to xl no problem. Libvirt in F18
> has backported packages but I'm waiting for some other bug fixes to
> accumulate before I push a build. Likely next week.
>
Ok, so, despite the bug being filed because a xend issue, the discussion took a bunch of different directions, and it all was very useful, as it helped uncovering the causes of two other bugs! :-)
However, since it looks like having the libvirt libxl driver in a good enough shape in Fedora might require some more time, I wonder whether we at least can put the good old libvirt-daemon-driver-xen --the xend based one-- to work out of the box in F18, as it used to be. This way, provided we tell people _not_to_ install libvirt-daemon-driver-libxl (for now), they'll be able to use virt-install and virt-manager without issues.
So, wrt this, Cole, I can confirm that, on rawhide, having only libvirt-daemon-driver-xen-1.0.1-4.fc19.x86_64 works fine, xend is started and virt-{install,manager} are fully functional. OTOH, on F18, where the package in question is libvirt-daemon-driver-xen-0.10.2.2-3.fc18.x86_64, the issue is still there, xend does not start, and thus virt-* don't work.
Is the plan still to have the rawhide packages pushed back to F18, as an update? Please, don't get me wrong, I've zero intention to push, just trying to make sure I understand what will happen. :-)
Thanks and Regards, Dario

(In reply to comment #32)
> Ok, so, despite the bug being filed because a xend issue, the discussion
> took a bunch of different directions, and it all was very useful, as it
> helped uncovering the causes of two other bugs! :-)
It did take a weird turn didn't it? I'm glad all of the bugs are being resolved :)
> However, since it looks like having the libvirt libxl driver in a good
> enough shape in Fedora might require some more time, I wonder whether we at
> least can put the good old libvirt-daemon-driver-xen --the xend based one--
> to work out of the box in F18, as it used to be. This way, provided we tell
> people _not_to_ install libvirt-daemon-driver-libxl (for now), they'll be
> able to use virt-install and virt-manager without issues.
Now that the "xend status" issue is fixed (not sure if it landed in the f18 updates repo yet), I assume that using xend is as simple as:
# systemctl enable xend.service
and using libxl is as simple as:
# systemctl disable xend.service
As far as I'm aware, Fedora just needs to enable the xend service by default and everything should work fine as before.
Cheers

>
> So, wrt this, Cole, I can confirm that, on rawhide, having only
> libvirt-daemon-driver-xen-1.0.1-4.fc19.x86_64 works fine, xend is started
> and virt-{install,manager} are fully functional. OTOH, on F18, where the
> package in question is libvirt-daemon-driver-xen-0.10.2.2-3.fc18.x86_64, the
> issue is still there, xend does not start, and thus virt-* don't work.
>
Hmm, I don't know why there should be any difference in xend autostarting between rawhide and F18, nor why that would be related to libvirt. Can anyone elaborate?
> Is the plan still to have the rawhide packages pushed back to F18, as an
> update? Please, don't get me wrong, I've zero intention to push, just trying
> to make sure I understand what will happen. :-)
>
For libvirt we generally do not rebase the latest rawhide version to F18. rawhide tracks latest libvirt releases, F18 stays on the same major release from Alpha onwards. However if the underlying issue is reasonable to backport we can pull it in to f18.
(In reply to comment #33)
>
> As far as I'm aware, Fedora just needs to enable the xend service by default
> and everything should work fine as before.
>
To do that, someone needs to file a bug against systemd to have xend start by default. Here's an example request:
https://bugzilla.redhat.com/show_bug.cgi?id=885406

(In reply to comment #36)
> Hmm, I don't know why there should be any difference in xend autostarting
> between rawhide and F18, nor why that would be related to libvirt. Can
> anyone elaborate?
xen on F18 and rawhide is the same (they use the same code), though rawhide gets updates first because of the way the Fedora update system works. So the difference might have been that the testing on rawhide was with xen-4.2.1-5 where xend status behaves as libvirt expects, but with xen-4.2.1-3 or xen-4.2.1-4 on F18 where it doesn't.