I just installed a minimal F18 host on which I want to run some guest
hosts. Problem is that the minimal installation of Fedora 18 left out LVM.
I could create a disc image for my guest host, but I am afraid that this
comes with a performance penalty.
The host system is already running Xen.
Can anyone advice me on whether I'm better off reinstalling with LVM or
that going without LVM is Okay?
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:
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. ;)
I just noticed that he thing described in the subject happens, when I
'yum upgrade' both a F18 or a rawhide system, and when the updates
include a new version of xen-XXX.
In some more details, what I noticed is after doing the following:
- yum upgrade, and the upgrade included a new version of xen-xxx
- reboot and choose 'Fedora with Xen Hypervisor'
Makes the system no longer able to boot.
Just booting another option, executing manually `grub2-mkconfig
-o /boot/grub/grub.cfg' and rebooting again did the trick.
So, it looks like, while installing the xen package for the first time
correctly creatte the GRUB2 menu entry, updating it does not properly
refreshes it. Is this happening only to me? Is this intended/supposed to
If so, sorry for bothering. :-) If no, let me know if I should file a
bug, or whatever else I can do to help fixing this.
Thanks and Regards,
<<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)
"rpm -qlp xen-4.2.1-5.fc18.x86_64.rpm" yields quite a surprise.
There is no trace of xl. The package still includes xm which requires
xend, both of which have been deprecated since (I think) xen 4.0.0.
Granted, I built, rather than yummed, 4.0.0 from sources and have been
using xl ever since but the continued distribution of xm confuses me
Does anybody know why this was done?
Is there a package that includes xl?
This is extremely frustrating. I've been waiting years for a mainline
kernel that includes Dom0/DomU and PCI-passthrough support and now that
it is available I still have to build xen from scratch to get the new xl
tool stack that was introduced many versions ago.
Thanks for any insight, tips.