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
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
On Feb 8, 2013, at 6:11 PM, M A Young m.a.young@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
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@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
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@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
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
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
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
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
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
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.
- Install F18
- yum install xen
- reboot
- ps aux | grep xend [nothing found]
- creating a domain with xl [_works_]
- yum install libvirt-daemon-xen virt-manager virt-viewer \ python-virt-inst libvirt-daemon-config-network
- rpm -qa | grep daemon-driver-libxl [yes, 0.10.2.3-1]
- rpm -qa | grep daemon-driver-xen [yes, 0.10.2.3-1]
- reboot (just in case!)
- ps aux | grep xend [nothing found]
- systemctl status libvirtd.service [active (running)]
- start virt manager [connected to xen:// (I can't see Dom0, but that is fine, IIRC)]
- ps aux | grep xend [nothing found]
- creating a domain with xl [_works_]
- 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
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.
- Install F18
- yum install xen
- reboot
- ps aux | grep xend [nothing found]
- creating a domain with xl [_works_]
- yum install libvirt-daemon-xen virt-manager virt-viewer \ python-virt-inst libvirt-daemon-config-network
- rpm -qa | grep daemon-driver-libxl [yes, 0.10.2.3-1]
- rpm -qa | grep daemon-driver-xen [yes, 0.10.2.3-1]
- reboot (just in case!)
- ps aux | grep xend [nothing found]
- systemctl status libvirtd.service [active (running)]
- start virt manager [connected to xen:// (I can't see Dom0, but that is fine, IIRC)]
- ps aux | grep xend [nothing found]
- creating a domain with xl [_works_]
- 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
On Tue, 2013-02-12 at 22:32 +0000, M A Young wrote:
- Install F18
- yum install xen
- reboot
- ps aux | grep xend [nothing found]
- creating a domain with xl [_works_]
- yum install libvirt-daemon-xen virt-manager virt-viewer \ python-virt-inst libvirt-daemon-config-network
- rpm -qa | grep daemon-driver-libxl [yes, 0.10.2.3-1]
- rpm -qa | grep daemon-driver-xen [yes, 0.10.2.3-1]
- reboot (just in case!)
- ps aux | grep xend [nothing found]
- systemctl status libvirtd.service [active (running)]
- start virt manager [connected to xen:// (I can't see Dom0, but that is fine, IIRC)]
- ps aux | grep xend [nothing found]
- creating a domain with xl [_works_]
- 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
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
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
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
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
On Feb 11, 2013, at 11:54 AM, Dario Faggioli raistlin@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
On Mon, 2013-02-11 at 12:19 -0600, Major Hayden wrote:
On Feb 11, 2013, at 11:54 AM, Dario Faggioli raistlin@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
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
-
Daniel P. Berrange -
Dario Faggioli -
M A Young -
Major Hayden