Hi all,
This is just a heads-up that I intend to upgrade qemu to 1.1 for rawhide, dropping about a 100 spice/usb patches which are upstream now :)
If you do not want me to do this please protest loud and quickly, because I expect to build the new qemu before the end of today.
Regards.
Hans
On Wed, Jul 04, 2012 at 02:40:08PM +0200, Hans de Goede wrote:
Hi all,
This is just a heads-up that I intend to upgrade qemu to 1.1 for rawhide, dropping about a 100 spice/usb patches which are upstream now :)
If you do not want me to do this please protest loud and quickly, because I expect to build the new qemu before the end of today.
The opposite: The new qemu-kvm seems to fix a segfault in the qcow2 code that affects libguestfs, so please do it as fast as you can :-)
Rich.
On 07/04/2012 08:40 AM, Hans de Goede wrote:
Hi all,
This is just a heads-up that I intend to upgrade qemu to 1.1 for rawhide, dropping about a 100 spice/usb patches which are upstream now :)
If you do not want me to do this please protest loud and quickly, because I expect to build the new qemu before the end of today.
That would be great! I was planning on doing the same today/tomorrow, so let me know if you don't get to it and I'll be happy to pick it up.
Thanks, Cole
On Wed, Jul 4, 2012 at 2:40 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi all,
Hey Hans,
This is just a heads-up that I intend to upgrade qemu to 1.1 for rawhide, dropping about a 100 spice/usb patches which are upstream now :)
If you do not want me to do this please protest loud and quickly, because I expect to build the new qemu before the end of today.
While you're at it, would you mind picking up 2 patches from the stable-1.1 branch? They missed the release by a few days. They are: 6f82a5e qemu-kvm: virtio: Do not register mask notifiers without in-kernel irqchip support 398b87f qemu-kvm: Add missing default machine options
Kind regards,
Ruben
Hi,
On 07/04/2012 08:34 PM, Ruben Kerkhof wrote:
On Wed, Jul 4, 2012 at 2:40 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi all,
Hey Hans,
This is just a heads-up that I intend to upgrade qemu to 1.1 for rawhide, dropping about a 100 spice/usb patches which are upstream now :)
If you do not want me to do this please protest loud and quickly, because I expect to build the new qemu before the end of today.
While you're at it, would you mind picking up 2 patches from the stable-1.1 branch? They missed the release by a few days. They are: 6f82a5e qemu-kvm: virtio: Do not register mask notifiers without in-kernel irqchip support 398b87f qemu-kvm: Add missing default machine options
I've already added those 2 :) But there are some problems doing the non kvm builds from the qemu-kvm sources. First I got linker errors, which I've fixed with the following patch:
--- a/Makefile.objs +++ b/Makefile.objs @@ -211,10 +211,8 @@ hw-obj-y = hw-obj-y += vl.o loader.o hw-obj-$(CONFIG_VIRTIO) += virtio-console.o hw-obj-y += usb/libhw.o -hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o hw-obj-y += fw_cfg.o hw-obj-$(CONFIG_PCI) += pci_bridge.o pci_bridge_dev.o -hw-obj-$(CONFIG_PCI) += msix.o msi.o hw-obj-$(CONFIG_PCI) += shpc.o hw-obj-$(CONFIG_PCI) += slotid_cap.o hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o --- a/Makefile.target +++ b/Makefile.target @@ -183,9 +183,10 @@ obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o b # virtio has to be here due to weird dependency between PCI and virtio-net. # need to fix this properly obj-$(CONFIG_NO_PCI) += pci-stub.o -obj-$(CONFIG_PCI) += pci.o +obj-$(CONFIG_PCI) += pci.o msi.o msix.o obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o vi obj-$(CONFIG_VIRTIO) += virtio-scsi.o +obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o obj-y += vhost_net.o obj-$(CONFIG_VHOST_NET) += vhost.o obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o
And now make check is hanging, so likely there is some silent breakage of non kvm builds too. I'm going to try the big hammer next and put a "make clean" between the kvm and non kvm builds.
Regards,
Hans
On Thu, Jul 05, 2012 at 10:10:25AM +0200, Hans de Goede wrote:
And now make check is hanging, so likely there is some silent breakage of non kvm builds too. I'm going to try the big hammer next and put a "make clean" between the kvm and non kvm builds.
Can you push a build to koji without 'make clean' as an interim step. I will test it with something which is far more thorough than anything qemu does.
Rich.
This is done now. Please test the following package:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4219848
This package can also be installed on F17. You may see the following error:
$ qemu-kvm qemu-kvm: symbol lookup error: qemu-kvm: undefined symbol: rbd_aio_discard
The fix is to upgrade 'ceph' and 'ceph-libs' to the more recent version from Rawhide.
I'm using and testing it on two of my machines (F17 & Rawhide) and it runs VMs, runs libguestfs tests etc fine. So it appears to be a solid release.
----------------------------------------------------------------------
I would like to backport this whole package to Fedora 17.
The reason is that the current F17 contains a rare data corruptor in the qcow2 code (for details, see: https://www.redhat.com/archives/libguestfs/2012-July/msg00020.html )
Large amounts of qcow2 code changed between 1.0 and 1.1.0 and instead of cherry picking fixes, I think we need the new, tested, known- working code.
Comments welcome.
Rich.
I would like to backport this whole package to Fedora 17.
The reason is that the current F17 contains a rare data corruptor in the qcow2 code (for details, see: https://www.redhat.com/archives/libguestfs/2012-July/msg00020.html )
Large amounts of qcow2 code changed between 1.0 and 1.1.0 and instead of cherry picking fixes, I think we need the new, tested, known- working code.
Comments welcome.
I will test it as soon as possible, but it may be a good idea to put it in virt-preview in order to allow more people to test it first? (Along with ceph and ceph-libs if necessary)
Fréderic.
On Thu, Jul 05, 2012 at 05:26:45PM +0200, Frédéric Grelot wrote:
I would like to backport this whole package to Fedora 17.
The reason is that the current F17 contains a rare data corruptor in the qcow2 code (for details, see: https://www.redhat.com/archives/libguestfs/2012-July/msg00020.html )
Large amounts of qcow2 code changed between 1.0 and 1.1.0 and instead of cherry picking fixes, I think we need the new, tested, known- working code.
Comments welcome.
I will test it as soon as possible, but it may be a good idea to put it in virt-preview in order to allow more people to test it first? (Along with ceph and ceph-libs if necessary)
Can everyone do this ^^ now? And if so, how?
Rich.
On Thu, Jul 05, 2012 at 04:55:50PM +0100, Richard W.M. Jones wrote:
On Thu, Jul 05, 2012 at 05:26:45PM +0200, Frédéric Grelot wrote:
I would like to backport this whole package to Fedora 17.
The reason is that the current F17 contains a rare data corruptor in the qcow2 code (for details, see: https://www.redhat.com/archives/libguestfs/2012-July/msg00020.html )
Large amounts of qcow2 code changed between 1.0 and 1.1.0 and instead of cherry picking fixes, I think we need the new, tested, known- working code.
Comments welcome.
I will test it as soon as possible, but it may be a good idea to put it in virt-preview in order to allow more people to test it first? (Along with ceph and ceph-libs if necessary)
Can everyone do this ^^ now? And if so, how?
(Sorry, that question was address to Cole)
Rich.
On 07/05/2012 11:55 AM, Richard W.M. Jones wrote:
On Thu, Jul 05, 2012 at 05:26:45PM +0200, Frédéric Grelot wrote:
I would like to backport this whole package to Fedora 17.
The reason is that the current F17 contains a rare data corruptor in the qcow2 code (for details, see: https://www.redhat.com/archives/libguestfs/2012-July/msg00020.html )
Large amounts of qcow2 code changed between 1.0 and 1.1.0 and instead of cherry picking fixes, I think we need the new, tested, known- working code.
Comments welcome.
I will test it as soon as possible, but it may be a good idea to put it in virt-preview in order to allow more people to test it first? (Along with ceph and ceph-libs if necessary)
Can everyone do this ^^ now?
Nope, I'm the only one with permissions, it's still just a personal repo. I've updated qemu there now.
Thanks, Cole
On Thu, Jul 05, 2012 at 03:25:43PM +0100, Richard W.M. Jones wrote:
I'm using and testing it on two of my machines (F17 & Rawhide) and it runs VMs, runs libguestfs tests etc fine. So it appears to be a solid release.
Well, I found one bug:
https://bugs.launchpad.net/qemu/+bug/1021649
Rich.
Hi,
On 07/06/2012 11:23 AM, Richard W.M. Jones wrote:
On Thu, Jul 05, 2012 at 03:25:43PM +0100, Richard W.M. Jones wrote:
I'm using and testing it on two of my machines (F17 & Rawhide) and it runs VMs, runs libguestfs tests etc fine. So it appears to be a solid release.
Well, I found one bug:
/me too, qemu asserts whenever an isoc USB-2.0 device is redirected (such as most webcams). I've written a fix for this, and added this to pkgs.fed... git master. I've not yet fired of a build, assuming more fixes may be on there way...
Regards,
Hans
[On the topic of qemu 1.1.0 in Fedora 17]
I'm seeing some very peculiar problems with virt-install that might be due to libvirt. Is libvirt in F17 too old for qemu 1.1.0?
-------
(1) Just installing qemu-system-x86 isn't enough for libvirt to recognize any hypervisors:
ERROR Host does not support any virtualization options
virsh capabilities doesn't show any <guest> section at all. Of course qemu-kvm *is* installed and working.
Solution: install the qemu meta-package. Unfortunately that means I have to have qemu-system-{cris,sh4,arm,mips} which I didn't want.
(2) If I use virt-install --cpu=host, I get:
ERROR unsupported configuration: CPU specification not supported by hypervisor
Solution was to not use this option.
(3) Now virt-install says:
ERROR internal error process exited while connecting to monitor: char device redirected to /dev/pts/19 Error: Cirrus VGA not available
Solution was to use --graphics=spice.
(4) Now virt-install says:
ERROR internal error process exited while connecting to monitor: char device redirected to /dev/pts/19 do_spice_init: starting 0.10.1 spice_server_add_interface: SPICE_INTERFACE_MIGRATION spice_server_add_interface: SPICE_INTERFACE_KEYBOARD spice_server_add_interface: SPICE_INTERFACE_MOUSE Kernel image must be specified
The error here is "Kernel image must be specified".
By this point it was getting very strange, so I decided to look at the libvirt log files for the qemu command line ...
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-arm -S -M integratorcp -no-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name OpenSUSE113x64 -uuid 4f959395-9203-7e3d-09e6-e43369286a2c -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/OpenSUSE113x64.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-reboot -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci,addr=0x1.0x2 -drive file=/dev/vg_pin/OpenSUSE113x64,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive file=/mnt/media/installers/OpenSUSE-11.3-x86_64/openSUSE-11.3-NET-x86_64.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:0d:16:de,bus=pci,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -k en-gb -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x4
Yikes. ???? qemu-system-arm ????
-------
The version of libvirt is libvirt-0.9.11.4-3.fc17.x86_64, and this is a mostly up to date F17 system, except that I've installed qemu-kvm 1.1.0 + ceph from Rawhide.
Suggestions welcome.
Rich.
Here is the output of virsh capabilities. It seems to make no sense. But it might indicate that something about detection of the qemu-kvm-1.1.0 binary fails, so libvirt assumes that it's not working.
Rich.
$ sudo virsh capabilities <capabilities>
<host> <uuid>2b8c6f80-b15c-11df-9cfd-b727e82cf6bb</uuid> <cpu> <arch>x86_64</arch> <model>Westmere</model> <vendor>Intel</vendor> <topology sockets='1' cores='2' threads='2'/> <feature name='rdtscp'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='smx'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pclmuldq'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_mem/> <suspend_disk/> <suspend_hybrid/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='4'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> </cpus> </cell> </cells> </topology> <secmodel> <model>selinux</model> <doi>0</doi> </secmodel> </host>
<guest> <os_type>hvm</os_type> <arch name='arm'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-arm</emulator> <machine>integratorcp</machine> <machine>collie</machine> <machine>nuri</machine> <machine>smdkc210</machine> <machine>connex</machine> <machine>verdex</machine> <machine>highbank</machine> <machine>mainstone</machine> <machine>musicpal</machine> <machine>n800</machine> <machine>n810</machine> <machine>sx1</machine> <machine>sx1-v1</machine> <machine>cheetah</machine> <machine>realview-eb</machine> <machine>realview-eb-mpcore</machine> <machine>realview-pb-a8</machine> <machine>realview-pbx-a9</machine> <machine>akita</machine> <machine>spitz</machine> <machine>borzoi</machine> <machine>terrier</machine> <machine>lm3s811evb</machine> <machine>lm3s6965evb</machine> <machine>tosa</machine> <machine>versatilepb</machine> <machine>versatileab</machine> <machine>vexpress-a9</machine> <machine>vexpress-a15</machine> <machine>xilinx-zynq-a9</machine> <machine>z2</machine> <domain type='qemu'> </domain> </arch> <features> <deviceboot/> </features> </guest>
<guest> <os_type>hvm</os_type> <arch name='mips'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mips</emulator> <machine>malta</machine> <machine>magnum</machine> <machine>pica61</machine> <machine>mipssim</machine> <machine>mips</machine> <domain type='qemu'> </domain> </arch> <features> <deviceboot/> </features> </guest>
<guest> <os_type>hvm</os_type> <arch name='mipsel'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mipsel</emulator> <machine>malta</machine> <machine>magnum</machine> <machine>pica61</machine> <machine>mipssim</machine> <machine>mips</machine> <domain type='qemu'> </domain> </arch> <features> <deviceboot/> </features> </guest>
</capabilities>
On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote:
Here is the output of virsh capabilities. It seems to make no sense. But it might indicate that something about detection of the qemu-kvm-1.1.0 binary fails, so libvirt assumes that it's not working.
With luck libvirt should have said what's wrong via syslog. Can you see if there were any log messages ?
Daniel
On Fri, Jul 06, 2012 at 04:06:13PM +0100, Daniel P. Berrange wrote:
On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote:
Here is the output of virsh capabilities. It seems to make no sense. But it might indicate that something about detection of the qemu-kvm-1.1.0 binary fails, so libvirt assumes that it's not working.
With luck libvirt should have said what's wrong via syslog. Can you see if there were any log messages ?
Ah, thanks, I was looking in /var/log/libvirt/libvirtd.log. Here is syslog from the point that I restart libvirtd:
Jul 6 16:07:54 spin libvirtd: Could not find keytab file: /etc/libvirt/krb5.tab: No such file or directory Jul 6 16:07:56 spin libvirtd[2157]: 2012-07-06 15:07:56.745+0000: 2172: info : libvirt version: 0.9.11.4, package: 3.fc17 (Fedora Project, 2012-06-28-13:50:28, x86-05.phx2.fedoraproject.org) Jul 6 16:07:56 spin libvirtd[2157]: 2012-07-06 15:07:56.745+0000: 2172: error : virCommandWait:2315 : internal error Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,? -device scsi-disk,?) status unexpected: exit status 1 Jul 6 16:07:56 spin libvirtd[2157]: 2012-07-06 15:07:56.811+0000: 2172: error : virCommandWait:2315 : internal error Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,? -device scsi-disk,?) status unexpected: exit status 1 Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.087+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.087+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.087+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.088+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.088+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.088+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.088+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.088+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.089+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.089+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.089+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.089+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.089+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.090+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.090+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.090+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.090+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.091+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.091+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.091+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.091+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.091+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.092+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin libvirtd[2157]: 2012-07-06 15:07:57.092+0000: 2172: error : virDomainDefParseXML:8249 : internal error No guest options available for arch 'x86_64' Jul 6 16:07:57 spin udevd[499]: RUN+="socket:..." support will be removed from a future udev release. Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use libudev to subscribe to events. Jul 6 16:07:57 spin udevd[499]: RUN+="socket:..." support will be removed from a future udev release. Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use libudev to subscribe to events.
The full output of that failing command is:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,? -device scsi-disk,? KVM not supported for this target No accelerator found!
Adding the option '-machine accel=kvm:tcg' fixes the output.
A quick look through upstream libvirt commits doesn't come up with anything obvious.
BTW I think (for libvirt AND libguestfs) we'd find these bugs a lot quicker if Rawhide tracked qemu-kvm git revisions more closely.
Rich.
On Fri, Jul 06, 2012 at 04:13:26PM +0100, Richard W.M. Jones wrote:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,? -device scsi-disk,?
Actually, this command works fine if run as root, but not as me. I assume libvirtd is running as qemu.qemu by this point?
Rich.
On Fri, Jul 06, 2012 at 04:13:26PM +0100, Richard W.M. Jones wrote:
On Fri, Jul 06, 2012 at 04:06:13PM +0100, Daniel P. Berrange wrote:
On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote:
Here is the output of virsh capabilities. It seems to make no sense. But it might indicate that something about detection of the qemu-kvm-1.1.0 binary fails, so libvirt assumes that it's not working.
With luck libvirt should have said what's wrong via syslog. Can you see if there were any log messages ?
The full output of that failing command is:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,? -device scsi-disk,? KVM not supported for this target No accelerator found!
Adding the option '-machine accel=kvm:tcg' fixes the output.
Sigh, qemu-kvm.git has done a broken merge yet again. Binaries built from qemu.git work fine when /dev/kvm is missing & this shoud not be changed by qemu-kvm.git I've previously fixed it with
commit ce967f6610dcd7b7762dbad5a639fecf42d5c76d Author: Daniel P. Berrange berrange@redhat.com Date: Fri Aug 5 09:50:29 2011 +0100
Fix default accelerator when configured with --disable-kvm
The default accelerator is hardcoded to 'kvm'. This is a fine default for qemu-kvm normally, but if the user built with ./configure --disable-kvm, then the resulting binaries will not work by default
* vl.c: Default to 'tcg' unless CONFIG_KVM is defined
Signed-off-by: Daniel P. Berrange berrange@redhat.com Signed-off-by: Marcelo Tosatti mtosatti@redhat.com
but this code seems to have changed somewhat
Daniel
On Fri, Jul 06, 2012 at 04:26:22PM +0100, Daniel P. Berrange wrote:
On Fri, Jul 06, 2012 at 04:13:26PM +0100, Richard W.M. Jones wrote:
On Fri, Jul 06, 2012 at 04:06:13PM +0100, Daniel P. Berrange wrote:
On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote:
Here is the output of virsh capabilities. It seems to make no sense. But it might indicate that something about detection of the qemu-kvm-1.1.0 binary fails, so libvirt assumes that it's not working.
With luck libvirt should have said what's wrong via syslog. Can you see if there were any log messages ?
The full output of that failing command is:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,? -device scsi-disk,? KVM not supported for this target No accelerator found!
Adding the option '-machine accel=kvm:tcg' fixes the output.
Sigh, qemu-kvm.git has done a broken merge yet again. Binaries built from qemu.git work fine when /dev/kvm is missing & this shoud not be changed by qemu-kvm.git I've previously fixed it with
commit ce967f6610dcd7b7762dbad5a639fecf42d5c76d Author: Daniel P. Berrange berrange@redhat.com Date: Fri Aug 5 09:50:29 2011 +0100
Fix default accelerator when configured with --disable-kvm The default accelerator is hardcoded to 'kvm'. This is a fine default for qemu-kvm normally, but if the user built with ./configure --disable-kvm, then the resulting binaries will not work by default * vl.c: Default to 'tcg' unless CONFIG_KVM is defined Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>but this code seems to have changed somewhat
It was broken by this commit
commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d Author: Jan Kiszka jan.kiszka@siemens.com Date: Fri Mar 2 10:30:43 2012 +0100
qemu-kvm: Use machine options to configure qemu-kvm defaults
Upstream is moving towards this mechanism, so start using it in qemu-kvm already to configure the specific defaults: kvm enabled on, just like in-kernel irqchips.
Signed-off-by: Jan Kiszka jan.kiszka@siemens.com Signed-off-by: Avi Kivity avi@redhat.com
Daniel
-
Cole Robinson -
Daniel P. Berrange -
Frédéric Grelot -
Hans de Goede -
Richard W.M. Jones -
Ruben Kerkhof