On Wed, Jan 15, 2014 at 05:23:58PM +, Peter Maydell wrote:
libcurl versions 7.16.0 and later have a timer callback interface which
must be implemented in order for libcurl to make forward progress (it
will sometimes rely on being called back on the timeout if there are
no file descriptors
On Wed, Jan 15, 2014 at 11:06:23PM +0100, Paolo Bonzini wrote:
Il 15/01/2014 18:23, Peter Maydell ha scritto:
libcurl versions 7.16.0 and later have a timer callback interface which
must be implemented in order for libcurl to make forward progress (it
will sometimes rely on being called
On further investigation, the No such file or directory error occurs
when using snapshot=on.
ie:
This fails:
./x86_64-softmmu/qemu-system-x86_64 -drive
'file=http://127.0.0.1/~rjones/cirros-0.3.1-x86_64-disk.img,if=virtio,snapshot=on'
This works:
./x86_64-softmmu/qemu-system-x86_64 -drive
Does anyone have any thoughts on what I'm missing / doing wrong here?
[00616ms] /home/remote/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 \
-global virtio-blk-device.scsi=off \
-nodefconfig \
-enable-fips \
-nodefaults \
-display none \
-machine accel=kvm:tcg \
-m
On Tue, Mar 25, 2014 at 02:53:19PM +0100, Paolo Bonzini wrote:
Il 25/03/2014 14:30, Richard W.M. Jones ha scritto:
Does anyone have any thoughts on what I'm missing / doing wrong here?
[00616ms] /home/remote/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 \
-global virtio-blk
On Tue, May 13, 2014 at 06:02:39PM +0200, Markus Armbruster wrote:
libssh2_session_last_error() already returns the error code.
Cc: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
block/ssh.c | 9 -
1 file changed, 4 insertions(+), 5
The last four patches are just a refactoring to use qemu error
handling, therefore ACK to all four of them.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical
On Wed, May 14, 2014 at 01:06:21PM +0200, Markus Armbruster wrote:
Richard W.M. Jones rjo...@redhat.com writes:
On Tue, May 13, 2014 at 06:02:39PM +0200, Markus Armbruster wrote:
libssh2_session_last_error() already returns the error code.
Cc: Richard W.M. Jones rjo...@redhat.com
On Tue, May 13, 2014 at 06:02:39PM +0200, Markus Armbruster wrote:
libssh2_session_last_error() already returns the error code.
Cc: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Richard W.M. Jones rjo...@redhat.com
block/ssh.c | 9
On Tue, May 13, 2014 at 06:02:40PM +0200, Markus Armbruster wrote:
Cc: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Richard W.M. Jones rjo...@redhat.com
block/ssh.c | 68
On Tue, May 13, 2014 at 06:02:41PM +0200, Markus Armbruster wrote:
Cc: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Richard W.M. Jones rjo...@redhat.com
block/ssh.c | 23 ++-
1 file changed, 14 insertions(+), 9
On Tue, May 13, 2014 at 06:02:43PM +0200, Markus Armbruster wrote:
Completes the conversion to Error started in commit 015a103^..d5124c0.
Cc: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Richard W.M. Jones rjo...@redhat.com
block
On Tue, May 13, 2014 at 06:02:42PM +0200, Markus Armbruster wrote:
Cc: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Richard W.M. Jones rjo...@redhat.com
block/ssh.c | 34 +-
1 file changed, 17 insertions
off.
Signed-off-by: Dr. David Alan Gilbert dgilb...@redhat.com
Tested-by: Richard W.M. Jones rjo...@redhat.com
I was able to use this option in order to install VMware ESXi as a
guest under KVM. Here are my notes on how to do this:
https://rwmj.wordpress.com/2014/05/19/notes-on-getting-vmware
On Tue, May 20, 2014 at 09:47:26AM +0100, Dr. David Alan Gilbert wrote:
* Gerd Hoffmann (kra...@redhat.com) wrote:
/* init basic PC hardware */
-pc_basic_device_init(isa_bus, gsi, rtc_state, floppy,
xen_enabled(),
-0x4);
+pc_basic_device_init(isa_bus, gsi,
On Wed, May 21, 2014 at 12:57:59PM +, Violaine V. wrote:
Hi everyone,
I’m trying to use QEMU (qemu-system-x86_64) to emulate an x86 virtual
machine on an ARM host : a Samsung Chromebook with Cortex-A15 CPU.
The Chromebook only has 2 GB of RAM and a relatively slow 32 bit
processor, and
On Mon, May 26, 2014 at 01:53:57PM +0400, M.Kustova wrote:
About fuzzer effectiveness. 'qemu-img' was set as the fuzzer target,
so its commands under interest are any that modify or/and read an
image. As first step, a tested command will be selected randomly or
specified by user.
qemu-io
A few years ago I suggested a way to use systemtap probes to do
feedback-directed fuzz-testing:
http://rwmj.wordpress.com/2010/11/22/half-baked-ideas-feedback-directed-fuzz-testing-of-filesystems/#content
When I tried to implement it, it turned out to mainly uncover bugs in
systemtap :-/
Rich.
On Wed, Feb 12, 2014 at 09:22:29AM -0800, Ian Main wrote:
On Wed, Jan 29, 2014 at 01:07:27PM +0800, Fam Zheng wrote:
This series adds for point-in-time snapshot NBD exporting based on
blockdev-backup (variant of drive-backup with existing device as target).
We get a thin point-in-time
Hi Tom,
I would love to test your latest non-upstream qemu patches, because
the better emulation of VSX may enable me to get libguestfs working on
ppc64p7.
Do you have a public git tree anywhere which contains something
testable? The published patches no longer cleanly apply to qemu.git.
Rich.
Tom,
I tested your patches [see below] and I found they work very well.
They solve all the immediate problems that libguestfs was hitting with
qemu not emulating certain POWER7 instructions.
I am now running a full libguestfs test which will take several hours,
but it looks as if -- even if this
On Thu, Feb 20, 2014 at 10:23:42AM +, Richard W.M. Jones wrote:
I am now running a full libguestfs test which will take several hours,
but it looks as if -- even if this test fails -- it won't be because
of lack of emulation / missing instructions in qemu.
The tests ran. I hit two bugs
On Thu, Feb 20, 2014 at 01:36:57PM +0100, Alexander Graf wrote:
On 20.02.2014, at 13:34, Richard W.M. Jones rjo...@redhat.com wrote:
On Thu, Feb 20, 2014 at 10:23:42AM +, Richard W.M. Jones wrote:
I am now running a full libguestfs test which will take several hours,
but it looks
On Tue, Apr 29, 2014 at 04:03:24PM +0100, Matthew Booth wrote:
[PATCH 1/8] curl: Fix long line
[PATCH 2/8] curl: Remove unnecessary use of goto
[PATCH 3/8] curl: Fix return from curl_read_cb with invalid state
[PATCH 4/8] curl: Remove erroneous sleep waiting for curl completion
[PATCH 5/8]
() interfaces
are not needed since no fd handlers, timers, or BHs stay registered when
requests have been drained.
For now this doesn't make much difference but will allow ssh to work in
IOThread instances in the future.
Cc: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Stefan Hajnoczi
On Thu, May 01, 2014 at 03:54:57PM +0100, Peter Maydell wrote:
Nothing earthshattering here, but it does have the patch which
actually lets us boot an emulated AArch64 CPU on a board...
Hi Peter,
I have real aarch64 hardware, and I'm trying to find a version of
qemu-system-aarch64 which will
On Sun, May 04, 2014 at 07:48:38PM +0100, Peter Maydell wrote:
On 4 May 2014 19:30, Richard W.M. Jones rjo...@redhat.com wrote:
I have real aarch64 hardware, and I'm trying to find a version of
qemu-system-aarch64 which will boot a KVM guest in some form.
Upstream qemu fails
I think this problem comes from my environment adding -fPIE.
In any case, without that flag it doesn't crash in qemu (it
kernel panics instead ..)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog:
On Sun, May 04, 2014 at 08:36:20PM +0100, Peter Maydell wrote:
OK, so you have a kernel (possibly just kernel config) problem
here -- this means QEMU got EPERM trying to open /dev/kvm.
Yes for some reason it was 0600. I set it to 0666.
This isn't going to work for aarch64 at the moment
I'm trying to get fstrim in a guest to cause the host disk to become
sparse, without success so far. I wonder if anyone can see what I'm
missing?
Guest:
- guest kernel: 3.13.4-200.fc20.x86_64
- ext4 guest filesystem
- fstrim from util-linux 2.24.1
- cat
On Mon, Mar 10, 2014 at 04:11:20PM +, Richard W.M. Jones wrote:
Guest:
- guest kernel: 3.13.4-200.fc20.x86_64
- ext4 guest filesystem
- fstrim from util-linux 2.24.1
- cat /sys/block/sda/device/scsi_disk/*/provisioning_mode
unmap
I noticed that I wasn't mounting the guest
On Mon, Mar 10, 2014 at 05:57:01PM +0100, Paolo Bonzini wrote:
Il 10/03/2014 17:14, Richard W.M. Jones ha scritto:
On Mon, Mar 10, 2014 at 04:11:20PM +, Richard W.M. Jones wrote:
Guest:
- guest kernel: 3.13.4-200.fc20.x86_64
- ext4 guest filesystem
- fstrim from util-linux 2.24.1
Finally I tracked down the reason why my early test failed, but then
it just started working by magic.
The reason is this:
If you:
- create an ext4 filesystem
- mount it WITHOUT -o discard
- create and remove some big files
- unmount
- mount -o discard
- fstrim
then the fstrim has no
git bisect is unsure, but one of these commits seems to have
completely broken virtio-serial.
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
0399a3819b27083ba69b88a9baa9025facab85bd
2ef66625f3a8978dcbbad773e6813f747971381e
We cannot bisect more!
On Thu, Mar 13, 2014 at 03:32:05PM +, Richard W.M. Jones wrote:
Anyhow, the error is:
hw/char/virtio-console.c:132:virtconsole_realize: Object 0x7f85482fb8a0 is
not an instance of type virtconsole
The full log including command line is attached.
Sorry, I realize that libvirt hid
On Thu, Mar 13, 2014 at 04:51:10PM +0100, Andreas Färber wrote:
A test is only as good as its coverage - testing virtserialport in
addition to virtconsole shows that commit
0399a3819b27083ba69b88a9baa9025facab85bd (virtio-console: QOM cast
cleanup for VirtConsole) broke virtserialport.
This
, and use virtserialport type for casting.
Note that virtio-serial-port is the abstract base type in
virtio-serial-bus.c, whereas virtserialport is the user-instantiatable
type in virtio-console.c. Therefore using TYPE_VIRTIO_CONSOLE_SERIAL_PORT.
Reported-by: Richard W.M. Jones rjo...@redhat.com
I got fstrim happily working in Fedora 20, but it's not working with
the upstream kernel. The message is:
fstrim -v /sysroot/
[ 45.541339] sda: WRITE SAME failed. Manually zeroing.
/sysroot/: 47.2 MiB (49466368 bytes) trimmed
While this isn't technically an error, it of course doesn't
On Fri, Mar 14, 2014 at 01:30:40PM +0100, Paolo Bonzini wrote:
Il 13/03/2014 22:49, Richard W.M. Jones ha scritto:
- Is there any reason why virtio-scsi doesn't emulate WRITE SAME?
Yes, the reason is that you're using QEMU 1.7. :)
- Can you see where ext4 issues the zeroout/write same call
On Fri, Mar 14, 2014 at 01:47:59PM +0100, Paolo Bonzini wrote:
Il 14/03/2014 13:42, Richard W.M. Jones ha scritto:
I worked around this in any case by rearranging the test [2]:
Doing:
rm /a_big_file
fstrim /
sync
umount /
[shut down qemu]
would only trim 64 KB on the host
On Fri, Mar 14, 2014 at 02:28:24PM +0100, Paolo Bonzini wrote:
Il 14/03/2014 14:24, Richard W.M. Jones ha scritto:
Could be a race condition (something going on in the background
between rm and fstrim).
Not much happens in the libguestfs appliance. There are usually only
two processes
On Fri, Mar 14, 2014 at 06:50:37AM -0400, Jeff Cody wrote:
On 32-bit hosts, some compilers will warn on too large integer constants
for constants that are 64-bit in length. Explicitly put a 'ULL' suffix
on those defines.
-#define VHDX_FILE_SIGNATURE 0x656C696678646876 /* vhdxfile in ASCII */
On Fri, Mar 14, 2014 at 03:38:55PM +, Peter Maydell wrote:
On 14 March 2014 15:36, Richard W.M. Jones rjo...@redhat.com wrote:
On Fri, Mar 14, 2014 at 06:50:37AM -0400, Jeff Cody wrote:
On 32-bit hosts, some compilers will warn on too large integer constants
for constants that are 64
On Fri, Mar 14, 2014 at 05:26:06PM +0100, Laszlo Ersek wrote:
(b) UINT64_C() is for uint_least64_t (7.18.4.1 Macros for
minimum-width integer constants). uint_least64_t is a required type
(7.18.1.2 Minimum-width integer types).
In practice I'd say it doesn't matter which one we use:
- ULL
On Fri, Mar 14, 2014 at 06:27:07PM +0100, Laszlo Ersek wrote:
*Why* someone would want to use an integer constant with type
uint_least64_t is a separate matter. One example follows -- assume all
of the below:
- suppose you write portable C99 source code,
- hence you can't take uint64_t for
On Mon, Mar 17, 2014 at 02:40:09PM +, Peter Maydell wrote:
On 17 March 2014 14:28, Laszlo Ersek ler...@redhat.com wrote:
On 03/17/14 07:02, Dave Airlie wrote:
The main reason I'm considering this stuff is for security reasons if
the guest asks for something really illegal or crazy what
On Mon, Mar 17, 2014 at 02:57:41PM +, Richard W.M. Jones wrote:
On Mon, Mar 17, 2014 at 02:40:09PM +, Peter Maydell wrote:
On 17 March 2014 14:28, Laszlo Ersek ler...@redhat.com wrote:
On 03/17/14 07:02, Dave Airlie wrote:
The main reason I'm considering this stuff
On Thu, Mar 20, 2014 at 09:13:26PM -0300, Leandro Dorileo wrote:
Do the directly migration from QemuOptionParameter to QemuOpts on
ssh block driver.
Signed-off-by: Leandro Dorileo l...@dorileo.org
---
block/ssh.c | 29 +
1 file changed, 13 insertions(+), 16
operator before token (
#if defined(CONFIG_SDL) SDL_COMPILEDVERSION SDL_VERSIONNUM(2, 0, 0)
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
---
backends/baum.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/backends/baum.c b/backends/baum.c
index 665107f
If you have odd Intel or AMD hardware, I'd appreciate if you could
test my disk image which recursively launches nested KVM until
something breaks:
http://rwmj.wordpress.com/2014/07/03/super-nested-kvm/#content
FWIW:
* AMD FX(tm)-8320 Eight-Core Processor:
L3 guest fails to boot with
[
On Thu, Jul 03, 2014 at 06:34:33PM +0100, Richard W.M. Jones wrote:
There's also a TCG-only mode, but the test ran so slowly as to be
inconclusive. I might leave it going overnight.
Well I got bored with the TCG test after about 4 hours. It appears to
hang launching the L3 guest, reproducible
On Fri, Jul 04, 2014 at 04:17:11PM +0400, Vasiliy Tolstov wrote:
2014-07-04 1:00 GMT+04:00 Richard W.M. Jones rjo...@redhat.com:
Well I got bored with the TCG test after about 4 hours. It appears to
hang launching the L3 guest, reproducible on two different hosts both
running qemu 2.0.0
On Mon, Jul 28, 2014 at 04:48:46PM +0800, Hu Tao wrote:
ping...
All the 6 patches have reviewed-by now.
On Fri, Jul 11, 2014 at 02:09:57PM +0800, Hu Tao wrote:
This series adds two preallocation mode to qcow2 and raw:
Option preallocation=full preallocates disk space for image by
On Fri, Aug 22, 2014 at 05:22:33PM +0200, Kevin Wolf wrote:
It's still useful because it happens to reduce the overhead in most
implementations and it's a relatively quick operation, but the best way
I know of to actually _fully_ preallocate is still writing zeros. Which
of the two the user
On Fri, Aug 22, 2014 at 04:34:40PM +0100, Richard W.M. Jones wrote:
- really really try as hard as possible to make sure that future
allocations will never fail (ie. write random non-zero data to the
file)
s/will never fail/are not needed and will never fail/
Rich.
--
Richard Jones
On Fri, Aug 22, 2014 at 05:53:22PM +0200, Kevin Wolf wrote:
Am 22.08.2014 um 17:34 hat Richard W.M. Jones geschrieben:
On Fri, Aug 22, 2014 at 05:22:33PM +0200, Kevin Wolf wrote:
It's still useful because it happens to reduce the overhead in most
implementations and it's a relatively
On Mon, Aug 25, 2014 at 01:18:30PM +0800, Hu Tao wrote:
On Fri, Aug 22, 2014 at 05:00:08PM +0100, Richard W.M. Jones wrote:
What is proposed to be called 'preallocation=falloc' should fall back
to other methods (eg. writing random, writing zeroes). It should
also be called something more
On Mon, Aug 25, 2014 at 01:18:30PM +0800, Hu Tao wrote:
What if user cares about time(writing zeroes or non-zeroes is
time-consuming) and wants falloc only sometimes? I think this is the
main difference between preallocation=falloc and preallocation=full.
Also posix_fallocate in glibc falls
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
---
block/curl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/curl.c b/block/curl.c
index 2698ae3..46f1082 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -26,7 +26,7 @@
#include qapi/qmp/qbool.h
#include curl
-by: Richard W.M. Jones rjo...@redhat.com
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
If you use this patch + Daniel Henrique Barboza's patch that adds a
timeout, then you can access guest files on VMware ESX servers.
Rich.
Some servers (notably VMware ESX) accept range requests, but don't
send back the Accept-Ranges: bytes header in their initial response.
For these servers you can set override_accept_ranges to 'on' which
forces this block driver to send range requests anyway.
Signed-off-by: Richard W.M. Jones rjo
On Tue, Aug 26, 2014 at 08:57:30PM -0600, Eric Blake wrote:
On 08/26/2014 08:38 PM, Fam Zheng wrote:
On Tue, 08/26 21:48, Richard W.M. Jones wrote:
Some servers (notably VMware ESX) accept range requests, but don't
send back the Accept-Ranges: bytes header in their initial response
On Wed, Aug 27, 2014 at 08:37:22AM +0200, Markus Armbruster wrote:
Eric Blake ebl...@redhat.com writes:
On 08/26/2014 08:38 PM, Fam Zheng wrote:
On Tue, 08/26 21:48, Richard W.M. Jones wrote:
Some servers (notably VMware ESX) accept range requests, but don't
send back the Accept-Ranges
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
---
block/curl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index 46f1082..8b69f28 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -355,7 +355,7 @@ static void curl_multi_timeout_do
The original code in block/curl.c dereferences state *after* checking
that it is NULL. That's obviously wrong, and indeed I can easily
provoke a segfault when talking to a VMware vCenter server.
I'm not as sure that this fix is the correct one, so please review it
carefully. However it does at
No change in the patch itself since v1. However I have added a longer
explanation to the commit message.
Rich.
Server and doing any kind of complex read-heavy
operations. With this commit the segfault goes away.
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
block/curl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
,
file.cookie:vmware_soap_session=\52a01262-bf93-ccce-d379-8dabb3e55560\}'
image: [...]
file format: raw
virtual size: 8.0G (8589934592 bytes)
disk size: unavailable
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
---
block/curl.c| 20
qemu-options.hx | 5 +
2 files changed, 25
On Fri, Aug 29, 2014 at 04:33:12PM +0800, Hu Tao wrote:
+if (prealloc == PREALLOC_MODE_FULL) {
+/* posix_fallocate() doesn't set errno. */
+result = -posix_fallocate(fd, 0, total_size);
+if (result != 0) {
Is it better to test:
result != ENOSYS result !=
On Fri, Aug 29, 2014 at 10:03:59AM +0100, Stefan Hajnoczi wrote:
On Thu, Aug 28, 2014 at 09:04:21AM +0100, Richard W.M. Jones wrote:
diff --git a/block/curl.c b/block/curl.c
index d4b85d2..f59615d 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -352,7 +352,7 @@ static void
Since v1:
- Remove the conditional around g_strdup (thanks Matt Booth).
Rich.
,
file.cookie:vmware_soap_session=\52a01262-bf93-ccce-d379-8dabb3e55560\}'
image: [...]
file format: raw
virtual size: 8.0G (8589934592 bytes)
disk size: unavailable
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
---
block/curl.c| 16
qemu-options.hx | 5 +
2 files changed, 21
On Fri, Aug 29, 2014 at 09:10:10AM -0600, Eric Blake wrote:
On 08/29/2014 09:03 AM, Richard W.M. Jones wrote:
In order to access VMware ESX efficiently, we need to send a session
cookie. This patch is very simple and just allows you to send that
session cookie. It punts on the question
For the benefit of those who have absolutely no idea what you're
talking about, could you write a simpler summary of what you're trying
to do?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog:
I found out a few days ago that if you:
(1) Open a qcow2 file that has lazy_refcounts = on and a backing file, and
(2) Write lots of stuff, and
(3) Kill qemu with SIGTERM [which I believed, maybe incorrectly, is a
nice way to kill qemu]
.. then you can end up with a corrupt qcow2 file. In
On Sat, Aug 30, 2014 at 05:53:43PM +0200, Benoît Canet wrote:
The Saturday 30 Aug 2014 à 15:46:41 (+0100), Richard W.M. Jones wrote :
For the benefit of those who have absolutely no idea what you're
talking about, could you write a simpler summary of what you're trying
to do?
Rich
BTW, what is tcmu-runner? The github repo you pointed to is ... opaque.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
On Mon, Sep 01, 2014 at 02:41:02PM +0200, Greg Kurz wrote:
On Sat, 30 Aug 2014 15:53:13 +0100
Richard W.M. Jones rjo...@redhat.com wrote:
I can reproduce this easily, although of course the reproducer will
involve libguestfs.
Rich.
Can you share this reproducer ?
The immediate
A test case, attached.
Note that you have to look at the output of the final qemu-img info
command. In the case where it goes wrong, the 'backing file:' and
'backing file format:' lines disappear completely. In the case where
the bug is not reproduced, these lines are still present.
It's 100%
# Write stuff to the overlay.
guestfish EOF
add-drive overlay.qcow2 format:qcow2 cachemode:unsafe
To head off any suggestions, removing cachemode:unsafe doesn't fix it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and
On Thu, Sep 04, 2014 at 02:35:22PM +0200, Kevin Wolf wrote:
Please change the code to always write zeros for FULL,
How is this useful for anyone? You don't know if the underlying SAN
is going to detect these zeroes or combine these blocks together.
It's just slow for no reason.
Rich.
--
On Thu, Sep 04, 2014 at 02:52:57PM +0200, Kevin Wolf wrote:
Am 04.09.2014 um 14:45 hat Richard W.M. Jones geschrieben:
On Thu, Sep 04, 2014 at 02:35:22PM +0200, Kevin Wolf wrote:
Please change the code to always write zeros for FULL,
How is this useful for anyone? You don't know
On Thu, Sep 04, 2014 at 03:17:51PM +0200, Kevin Wolf wrote:
Am 04.09.2014 um 15:07 hat Richard W.M. Jones geschrieben:
On Thu, Sep 04, 2014 at 02:52:57PM +0200, Kevin Wolf wrote:
Am 04.09.2014 um 14:45 hat Richard W.M. Jones geschrieben:
On Thu, Sep 04, 2014 at 02:35:22PM +0200, Kevin
On Thu, Sep 04, 2014 at 05:23:21PM +0200, Kevin Wolf wrote:
The definition of besteffort depends on what you want to achieve. It
is policy, and we generally try to keep policy out of qemu.
I think qemu *should* have a policy of make it work and don't fail - first -
and then offer a million
On Fri, Sep 05, 2014 at 04:39:51PM +0100, Stefan Hajnoczi wrote:
Did you try older QEMU versions? I'm curious if this is something that
crept in later or is fundamentally broken in lazy_refcounts=on.
At your prompting, I've done a bit more investigation.
I was basing my observations on qemu
,
+.help = Enable vmport (pc q35),
},{
.name = iommu,
.type = QEMU_OPT_BOOL,
--
1.8.4
I reviewed the code and compiled-tested it, but didn't run it since
I've moved my ESXi server to baremetal *. You can add:
Reviewed-by: Richard W.M. Jones rjo
;, file.timeout:-1 }': timeout parameter is too
large or negative: Invalid argument
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
---
block/curl.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index 225407c..5233ff6 100644
--- a/block/curl.c
+++ b
On Mon, Oct 06, 2014 at 04:38:59PM +0200, Laszlo Ersek wrote:
On 10/06/14 16:32, Richard W.M. Jones wrote:
qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
long (not an int).
Store the timeout (which is a positive number of seconds) as a
uint64_t. Check
(sreq)) {
+scsi_req_continue(sreq);
}
-bdrv_io_unplug(req-sreq-dev-conf.bs);
-scsi_req_unref(req-sreq);
+scsi_req_unref(sreq);
}
static void virtio_scsi_handle_cmd(VirtIODevice *vdev, VirtQueue *vq)
?
Yes, that fixes it.
Tested-by: Richard W.M. Jones rjo
On Sat, Oct 18, 2014 at 12:03:23AM +0200, Wouter Verhelst wrote:
Hi all,
(added rjones from nbdkit fame -- hi there)
[I'm happy to implement whatever you come up with, but I've added
Florian Weimer to CC who is part of Red Hat's product security group]
So I think the following would make
I'm pleased to announce libguestfs 1.28, a library and set of tools
for accessing and modifying virtual machine disk images.
This release took 7 months of work by a considerable number of people,
and has many new features (see release notes below), including new
'virt-v2v' and 'virt-p2v' tools
This patch is identical to the previous version, except that I have
rebased it on top of current qemu HEAD.
Previous discussion:
https://lists.gnu.org/archive/html/qemu-devel/2014-10/threads.html#00518
;, file.timeout:-1 }': timeout parameter is too
large or negative: Invalid argument
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
Reviewed-by: Laszlo Ersek ler...@redhat.com
---
block/curl.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index
On Mon, Oct 20, 2014 at 01:56:43PM +0200, Florian Weimer wrote:
On 10/20/2014 01:51 PM, Markus Armbruster wrote:
Furthermore, STARTTLS is vulnerable to active attacks: if you can get
between the peers, you can make them fall back to unencrypted silently.
How do you plan to guard against that?
No change since previous repost, except I have rebased it against git
head.
Three line change for obvious bug. Can I get another review?
Previous discussion:
https://lists.gnu.org/archive/html/qemu-devel/2014-10/threads.html#00518
Rich.
;, file.timeout:-1 }': timeout parameter is too
large or negative: Invalid argument
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
Reviewed-by: Laszlo Ersek ler...@redhat.com
---
block/curl.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index
On Sun, Oct 26, 2014 at 04:57:46PM +0800, Gonglei wrote:
On 2014/10/26 16:42, Richard W.M. Jones wrote:
qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
long (not an int).
Store the timeout (which is a positive number of seconds) as a
uint64_t. Check
On Sun, Oct 26, 2014 at 06:45:02PM +0800, Gonglei wrote:
On 2014/10/26 18:22, Richard W.M. Jones wrote:
It's just there to stop unreasonable timeouts or negative numbers.
10 s is 27 hours, and no webserver I know of would keep a
connection open that long. Possibly not even the IP
On Sun, Oct 26, 2014 at 06:55:21PM +0800, Gonglei wrote:
On 2014/10/26 18:48, Richard W.M. Jones wrote:
On Sun, Oct 26, 2014 at 06:45:02PM +0800, Gonglei wrote:
On 2014/10/26 18:22, Richard W.M. Jones wrote:
It's just there to stop unreasonable timeouts or negative numbers.
10 s
401 - 500 of 1226 matches
Mail list logo
