@Thomas,
Is there really no way to detect the format other than relying on
extension? :-(
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1819182
Title:
info does not recognize file format of vpc
$ ./go-create
#version: 2.11.1
qcow: PASS fmt=qcow auto=qcow exp=qcow [name=my-img.qcow opts=]
qcow2: PASS fmt=qcow2 auto=qcow2 exp=qcow2 [name=my-img.qcow2 opts=]
qed: PASS fmt=qed auto=qed exp=qed
Public bug reported:
After creating or converting an image to vpc with 'subformat=fixed'
'qemu-img info' incorrectly identifies the image as 'raw' format.
$ qemu-img --version
qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.10)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project
** Tags added: qemu-file-locking
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no feature flag
Status in QEMU:
Opinion
Status in libvirt package in
I've taked this qemu-file-locking just so we can group/easily find other bugs
that have this tag.
link to search for all bugs with that tag is: https://goo.gl/W2aT2T
or the longer form:
Kevin,
thanks again. You've provided enough support for me at this point. I had
looked at trying to coalesce multiple -drive values into a single one, and that
can definitely be made to work with the newer qemu, but i'm not sure I can make
it work with older.
the goal there would be to do
I see the answer to my question above. 'format' is now driver=qcow2.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no feature flag
Status in QEMU:
Your example does work (using -blockdev), but I can't get it to work with
-drive.
$ qemu-system-x86_64 \
-drive id=d01,file=disk1.img,format=qcow2 \
-device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on \
-device drive=d01,serial=s01,driver=virtio-blk,index=2,share-rw=on
Kevin,
Thanks for the suggestion of share-rw=on. I figured I'd try to change our
'xkvm' wrapper around qemu to use that.
Unfortunately, it looks like , at least in our version of qemu (QEMU emulator
version 2.10.0(Debian 1:2.10+dfsg-0ubuntu1)), that this does not work
with the -drive path.
$
** Attachment added: "dump-qmp-schema.py: a hack job to dump and partially
"uncompress" qemu schema output"
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028/+attachment/4948029/+files/dump-qmp-schema.py
** Attachment removed: "dump-qmp-schema.py: a hack job to dump and partially
** Attachment added: "dump-qmp-schema.py: a hack job to dump and partially
"uncompress" qemu schema output"
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028/+attachment/4948028/+files/dump-qmp-schema.py
--
You received this bug notification because you are a member of qemu-
Note, that Michael Roth's comments are probably valid. I suspect that
if leftyfb ever saw this working on powerVM host, then it was through
the kvm_pr module. In my experience, that works generally pretty well
(buit my testing has only ever been done powerNV host).
--
You received this bug
ok. so after playing some, this all comes down to needing 'usb=off' on
the qemu command line.
works:
qemu-system-ppc64 -enable-kvm -machine usb=off -device
virtio-net-pci,netdev=net00 -netdev type=user,id=net00 -drive
if=virtio,file=xenial-server-cloudimg-ppc64el-disk1.img,format=qcow2 -drive
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1563887
Title:
qemu-system-ppc64 freezes on starting image on ppc64le
Status in QEMU:
Invalid
This may or may not be relevant here, but the mysterious "uncaught
target signal 11" error was fixed for maas images (lp:maas-images) build
process by increasing the memory to the VMs that were doing the build.
We had been doing the cross/qemu-static building in ~512M vms and that
was resulting in
I just worked around this in cloud-init by disabling the smartOS datasource if
the uname arch is arm* or aarch*
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceSmartOS.py
--
You received this bug notification because you are a member of qemu-
I just did some bug cleanup work here.
Per Michael's comment, this is now fixed in seabios. So I marked the seabios
task as fix-released in Ubuntu.
12.04 will not have this fix present, as its seabios is 0.6.2, but versions
of ubuntu 12.10 (quantal) and later should be fix-released.
Note,
For the cloud-images specifically, this problem was solved once before in bug
450463. our cloud-images have the following in their /etc/modules:
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per
This fix-commited upstream at
http://git.qemu.org/?p=qemu.git;a=commit;h=9c3a596a03cc10c2d9097f057b9ccb9d557a4d5f
.
** Changed in: qemu
Status: Confirmed = Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
. This
implies that the text and data segments must be consecutive in the
OS image; this is true for existing a.out executable formats. If
this field is zero, the boot loader assumes that the text and data
segments occupy the whole OS image file.
Signed-off-by: Scott Moser smo...@ubuntu.com
diff
Re-sending to qemu-devel. I'd originally sent this to kvm mailing list.
-- Forwarded message --
Date: Sat, 17 Mar 2012 00:08:06
From: Scott Moser smo...@ubuntu.com
To: k...@vger.kernel.org
Subject: [PATCH] fix multiboot loading if load_end_addr == 0
The previous code did
Forwarded to qemu-devel mailing list at http://www.mail-archive.com
/qemu-devel@nongnu.org/msg103059.html .
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/957622
Title:
kvm -kernel with grub
** Patch added: suggested debdiff
https://bugs.launchpad.net/qemu/+bug/957622/+attachment/2894794/+files/lp957622.debdiff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/957622
Title:
kvm
I'm pretty sure this is a bug in the linked commit above, in that it
does not account for this statement in the multiboot spec:
`load_end_addr'
Contains the physical address of the end of the data segment.
(load_end_addr - load_addr) specifies how much data to load. This
implies
I've a fix for this upstream at
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/88404
** Changed in: qemu-kvm (Ubuntu)
Status: New = In Progress
** Changed in: qemu
Status: New = Confirmed
** Changed in: qemu-kvm (Ubuntu)
Importance: Undecided = Medium
--
You received
** Changed in: kvm (Ubuntu)
Status: New = Invalid
** Changed in: qemu (Ubuntu)
Status: New = Invalid
** Changed in: qemu-kvm (Ubuntu)
Importance: Undecided = Medium
** Changed in: qemu-kvm (Ubuntu)
Status: New = Triaged
--
You received this bug notification because you
Just a comment, the commands in the summary will boot the first time,
but a reboot will (possibly) fail. bug 615529 has more info on that.
--
seabios should have native scsi support
https://bugs.launchpad.net/bugs/611142
You received this bug notification because you are a member of qemu-
** Tags removed: ec2-images
--
seabios should have native scsi support
https://bugs.launchpad.net/bugs/611142
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Status in “qemu-kvm” package in Ubuntu: New
Status in
Just on other thought, grub *does* have a 'scsi' module, that in theory
could handle identifying scsi disks outside of 'biosdisk'. However, it
doesn't work now.
--
seabios should have native scsi support
https://bugs.launchpad.net/bugs/611142
You received this bug notification because you are a
Public bug reported:
Binary package hint: seabios
Currently when a grub multiboot image is booted with 'kvm -kernel' and
'biosdisk' module, it will see block devices of type IDE or virtio. It
will not see scsi devices.
To demonstrate this:
$ qemu-img create -f qcow2 disk.img 1G
$ grub-mkrescue
I'm fully aware that this isn't a high priority bug for anyone primarily due to
the fact that it uses the word 'scsi'.
However, I wanted to document it here.
Also, I'm attaching an IRC log of a conversation with aligouri in #kvm
discussing the issue.
** Attachment added: #kvm discussion about
** Changed in: qemu-kvm (Ubuntu)
Importance: Undecided = Medium
** Changed in: qemu-kvm (Ubuntu)
Status: New = Triaged
--
qemu-system-arm segfaults emulating versatile machine after running debootstrap
--second-stage inside vm
https://bugs.launchpad.net/bugs/604872
You received this
32 matches
Mail list logo
