similar to: Conflicting parameters on qemu call

Hi Daniel, > On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote: >> On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote: >>> On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: >>>> Hi Lists, >>>> >>>> I currently

On 21. Aug 2020, at 11:20, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote: >> Hi Daniel, >>> On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: >>> On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote: >>>> On 21. Aug 2020, at 10:38, Daniel P. Berrangé

On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: >> Hi Lists, >> >> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. >> >> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu >> when starting an

On Fri, Aug 21, 2020 at 01:38:23PM +0200, Jan Walzer wrote: > On 21. Aug 2020, at 11:20, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote: > >> Hi Daniel, > >>> On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: > >>> On Fri, Aug 21, 2020 at 11:00:27AM +0200,

On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote: > Hi Daniel, > > On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote: > >> On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote: > >>> On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan

On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote: > On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: > >> Hi Lists, > >> > >> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. > >> > >> It is imperative

On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: > Hi Lists, > > I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. > > It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu > when starting an instance, as without that, it will only use one thread > and hence of limited/no use. > > The problem is,

The latter is a better way to disable the qemu display output as we need to, without enabling extra devices (which are disabled already, anyway). Also, related to the change above, ban the -display parameter from the ones that can be supplied by the user. --- configure.ac | 8 ++++---- src/launch-direct.c | 12 ++++++++---- src/launch.c | 1 + 3 files changed, 13 insertions(+), 8

These assorted patches end up with adding virtio-scsi support to libguestfs. It passes libguestfs-test-tool, but I haven't yet tried to run the full set of tests. In theory > 26 devices can be added, but it's likely that certain parts of the daemon will break if you actually try this. This of course needs to be fixed. Thanks Paolo Bonzini for invaluable help. Rich.

On Wed, Sep 17, 2014 at 07:59:03PM +0530, Priyanka Ranjan wrote: > libguestfs: command: run: /usr/libexec/qemu-kvm > libguestfs: command: run: \ -nographic > libguestfs: command: run: \ -machine accel=kvm:tcg > libguestfs: command: run: \ -device ? > libguestfs: error: /usr/libexec/qemu-kvm exited with error status 1, see > debug messages above > libguestfs: trace: launch = -1

v1 was here: https://www.redhat.com/archives/libguestfs/2018-September/thread.html#00000 v2: - Make conditional on qemu >= 2.11.2 and libvirt >= 4.6.0. - Fix the libvirt XML to match what went upstream. Still untested. Rich.

Of course I mean state=off (not <htm state=on>) ... Rich.

[This email is either empty or too large to be displayed at this time]

More comprehensive support for virtio-scsi. Passes all the tests. Rich.

Unfortunately I was not able to test this because I don't currently have access to a P9 machine. Rich.

Hi there, I have used qemu to install FreeBSD 9.2 release, and i can boot it fine with: $ qemu-system-x86_64 -hda images/FreeBSD-9.2-RELEASE-amd64.img I then made virsh aware of my brand new VM (see attached XML), but when i run it via virsh, It hangs after the bootloader whith this message: Booting... CPU doesn't support long mode From the log, here is the generated qemu command:

On Fri, Aug 01, 2014 at 03:14:17PM -0700, Zetan Drableg wrote: > Setup debuginfo repo > /etc/yum.repos.d/debuginfo. > repo > [ol6_debuginfo] > name=Oracle Linux 6 debuginfo > baseurl=http://oss.oracle.com/ol6/debuginfo > gpgkey=https://oss.oracle.com/ol6/RPM-GPG-KEY-oracle > gpgcheck=1 > enabled=1 > > yum update > yum install kernel-debuginfo > > (gdb)

On Wed, Sep 17, 2014 at 08:52:57PM +0530, Priyanka Ranjan wrote: > Many Thanks Richard for your reply. > > # /usr/libexec/qemu-kvm -nographic -machine accel=kvm:tcg -device \? > > open /dev/kvm: No such file or directory > failed to initialize KVM: Operation not permitted > Back to tcg accelerator. > Could not allocate dynamic translator buffer > > I tried

Hello everyone I come back to ask for a hand to solve a problem that has affected me since October 2016 and I have not yet solved using libvirt. I thought I would solve it by going to a 4.9.x kernel with qemu 2.8.1.1 and with libvirt 3.2.0. Compile it all in a stable LFS environment version 7.9 and that all checks pass without errors. The strange thing is that the libvirtd process starts without

NB: This requires a qemu patch by Eduardo which is currently awaiting review: https://www.mail-archive.com/qemu-devel@nongnu.org/msg422959.html So not to be applied yet unless that qemu change goes upstream. Rich.