Hi, I'm having trouble installing a fedora f20 guest on a centos5
host, I previously had a working f16 guest, so I guess I want to
know if this is possible or not.
virt-install seems to work ok as before, but then the reboot fails
with this error:
Error starting domain: POST operation failed: xend_post: error from
xen daemon: (xend.err "Error creating domain: Boot loader didn't
return any data!")
I've tried formatting /boot as ext2 and ext3 with the same result,
now I'm out of ideas. Here is my virt-install command:
virt-install --paravirt --name honk --ram 2048 --disk \
path=/dev/VolGroup02/LogVol12 --vnc --location \
Another question with internal snapshots. I can see the snapshot tree with:
virsh snapshot-list Win7vm --tree
However, I would like to know from what previous snapshot I'm currently
running off. Something like the "You are here" that VMware shows. Is
there a way to find that out?
Here are some Fedora virt happenings for December.
Fedora 20 released!
Fedora 20 was officially released on December 17th:
There was some last minute issues with the 'fedup' update tool, but they
should be resolved now. Just make sure you fully update F19 before trying to
upgrade to F20!
Since F20 is out, virt-preview for F19 will no longer be receiving new builds.
FWIW, no F21 schedule has been posted yet.
Libvirt 1.2.0, separate python bindings
libvirt 1.2.0 was released on Monday December 2nd 2013. Major changes:
- Add support for gluster pool (Eric Blake)
- Split out python binding (Daniel P. Berrange)
- vbox: add support for 4.3 APIs (Ryota Ozaki)
Per the second item there, the libvirt python bindings are now a standalone
project. This was mainly done to simplify distributing these bindings via pip
which was of interest to Openstack.
seabios 1.7.4 was released on December 23rd. Highlights from the changelog:
- Support for obtaining ACPI tables directly from QEMU.
- Initial support for XHCI USB controllers (initially for QEMU only).
- Support for booting from "pvscsi" devices on QEMU.
This will soon be heading to rawhide.
Total bugs on 2013-12-02 : 190
Total bugs on 2014-01-05 : 166
note: I dropped gnome-boxes from the stats. There isn't much perceptible bug
triaging happening with that component, so the numbers pretty much grow
without bound until Fedora goes end of life. Which makes it not all that
interesting to track here. 'spice' was added, it should have been there the
I also did a lot of F18 bug closing/confirming/deferring in preparation of F18
* Fedora 18 : 7
* Fedora 19 : 75
* Fedora 20 : 66
* Fedora rawhide : 18
* edk2 : 1
* gtk-vnc : 1
* ipxe : 4
* libguestfs : 7
* libosinfo : 1
* libvirt : 42
* libvirt-sandbox : 9
* netcf : 6
* openbios : 1
* qemu : 24
* seabios : 2
* spice : 11
* spice-gtk : 3
* virt-dmesg : 1
* virt-manager : 20
* virt-viewer : 7
* virt-what : 2
* virtio-win : 1
* xen : 10
* xorg-x11-drv-qxl : 13
* ASSIGNED : 11
* NEW : 142
* ON_QA : 1
* POST : 12
Bugs of note
libvirt-guests.service is broken in F20
Still waiting for some guidance from systemd folks, no solution yet.
I have a F19 that I'm wiping out in order to perform a clean intall of
F20. Is it ok to simply tar /etc/libvirt and /var/lib/libvirt/ and
untar them on the new installation? Or is it better to grab the VM
definition files & their disks and import them with vish on the new setup?
The first option seems very straightforward but don't know if there are
new config files or changes in syntax that I may be overriding by
extracting the previous version.
I have been attempting to attach a USB keyboard & mouse from the host to a
Windows 7 guest using QEMU's USB2 controller. The keyboard seems to attach
correctly, however I have trouble with certain mice and devices. When
starting the guest, the devices remain attached for a second or two, then
they disconnect. the libvirt logs show that it no longer sees the USB
device, and I see this in dmesg:
[ 10.876071] usb 3-13: reset full-speed USB device number 2 using xhci_hcd
[ 10.888206] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
disabled ep ffff88041917f740
[ 10.888209] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
disabled ep ffff88041917f800
[ 10.888210] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
disabled ep ffff88041917f7c0
[ 11.041209] usb 3-14: reset full-speed USB device number 3 using xhci_hcd
[ 11.054379] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
disabled ep ffff8800c8d559c0
[ 11.054383] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
disabled ep ffff8800c8d55440
<repeats for some time>
[ 87.476806] usb 3-14: new full-speed USB device number 4 using xhci_hcd
[ 87.491908] usb 3-14: New USB device found, idVendor=046d, idProduct=c066
[ 87.491911] usb 3-14: New USB device strings: Mfr=1, Product=2,
[ 87.491912] usb 3-14: Product: G9x Laser Mouse
[ 87.491914] usb 3-14: Manufacturer: Logitech
[ 87.491914] usb 3-14: SerialNumber: 081BB92CA70018
[ 87.494697] input: Logitech G9x Laser Mouse as
[ 87.494994] hid-generic 0003:046D:C066.0008: input,hidraw0: USB HID v1.11
Mouse [Logitech G9x Laser Mouse] on usb-0000:00:14.0-14/input0
[ 87.498834] input: Logitech G9x Laser Mouse as
[ 87.499078] hid-generic 0003:046D:C066.0009: input,hiddev0,hidraw1: USB
HID v1.11 Keyboard [Logitech G9x Laser Mouse] on usb-0000:00:14.0-14/input1
As you can see the device re-attaches to the host. The device is plugged
into a USB2 port, but it appears to be controlled by Intel's XHCI controller:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series
Chipset Family USB xHCI [8086:8c31] (rev 04)
I'm running 3.12.5-303.fc20.x86_64, which is Fedora 20's
kernel-3.12.5-302.fc20.x86_64 with the i915 VGA arbitration patches applied.
Should I report a bug against the kernel?