Hi,
I want to P2V a redhat server to kvm vm, and lvm was used to manage disks
in the redhat server.
I want to only migrate the really used storage to vm image, which can
reduce the time cost significantly sometimes,
so I need the information of logical volume to physical disks bitmap, to
know whic
On 26/12/14 16:32, Denis V. Lunev wrote:
On 26/12/14 16:13, Peter Lieven wrote:
Am 26.12.2014 um 13:35 schrieb Denis V. Lunev:
The check for maximum length was added by
commit c31cb70728d2c0c8900b35a66784baa446fd5147
Author: Peter Lieven
Date: Thu Oct 24 12:06:58 2013 +0200
blo
On 26 December 2014 at 10:16, Denis V. Lunev wrote:
> IMHO the patch does not change anything even on hot-hot path.
> the declaration 'struct kvm_irqfd irqfd = {};' will
> result in memset inside.
>
> Thus in order to achieve declared goal author should
> declare
>struct kvm_irqfd irqfd;
> and
This patch adds a python tool to the scripts directory that can read
a dumped migration stream if it contains the JSON description of the
device states. I constructs a human readable JSON stream out of it.
It's very simple to use:
$ qemu-system-x86_64
(qemu) migrate "exec:cat > mig"
$ ./s
One of the annoyances of the current migration format is the fact that
it's not self-describing. In fact, it's not properly describing at all.
Some code randomly scattered throughout QEMU elaborates roughly how to
read and write a stream of bytes.
We discussed an idea during KVM Forum 2013 to add
To support programmatic JSON assembly while keeping the code that generates it
readable, this patch introduces a simple JSON writer. It emits JSON serially
into a buffer in memory.
The nice thing about this writer is its simplicity and low memory overhead.
Unlike the QMP JSON writer, this one does
Migration is a black hole to most people. One of the biggest reasons for
this is that its protocol is a secret, undocumented sauce of code rolling
around random parts of the QEMU code base.
But what if we simply exposed the description of how the format looks like
alongside the actual migration st
For ftell we flush the output buffer to ensure that we don't have anything
lingering in our internal buffers. This is a very safe thing to do.
However, with the dynamic size measurement that the dynamic vmstate
description will bring this would turn out quite slow.
Instead, we can fast path this
To support programmatic JSON assembly while keeping the code that generates it
readable, this patch introduces a simple JSON writer. It emits JSON serially
into a buffer in memory.
The nice thing about this writer is its simplicity and low memory overhead.
Unlike the QMP JSON writer, this one does
On 26/12/14 16:13, Peter Lieven wrote:
Am 26.12.2014 um 13:35 schrieb Denis V. Lunev:
The check for maximum length was added by
commit c31cb70728d2c0c8900b35a66784baa446fd5147
Author: Peter Lieven
Date: Thu Oct 24 12:06:58 2013 +0200
block: honour BlockLimits in bdrv_co_do_write
I think your just not trying hard enough ;-)
I have reproduced this on four different (bare metal) machines. I used
the default ubuntu QEMU (2.0.0) and the latest GIT version. All machines
where running ubuntu 14.04. I also tried to reproduce it on a virtualbox
VM and I could only get it to crash
Am 26.12.2014 um 13:35 schrieb Denis V. Lunev:
> The check for maximum length was added by
> commit c31cb70728d2c0c8900b35a66784baa446fd5147
> Author: Peter Lieven
> Date: Thu Oct 24 12:06:58 2013 +0200
> block: honour BlockLimits in bdrv_co_do_write_zeroes
>
> but actually if driver p
move code dealing with a block device to a separate function. This will
allow to implement additional processing for an ordinary files.
Pls note, that xfs_code has been moved before checking for
s->has_write_zeroes as xfs_write_zeroes does not touch this flag inside.
This makes code a bit more con
This efficiently writes zeroes on Linux if the kernel is capable enough.
FALLOC_FL_ZERO_RANGE correctly handles all cases, including and not
including file expansion.
Signed-off-by: Denis V. Lunev
CC: Kevin Wolf
CC: Stefan Hajnoczi
---
block/raw-posix.c | 13 -
configure |
This sequence works efficiently if FALLOC_FL_ZERO_RANGE is not supported.
Simple fallocate(0) will extend file with zeroes when appropriate in the
middle of the file if there is a hole there and at the end of the file.
Unfortunately fallocate(0) does not drop the content of the file if
there is a
actually the code
if (ret == -ENODEV || ret == -ENOSYS || ret == -EOPNOTSUPP ||
ret == -ENOTTY) {
ret = -ENOTSUP;
}
is present twice and will be added a couple more times. Create helper
for this. Place it into do_fallocate() for further convinience.
Signed-off-by: Denis V.
These patches eliminate data writes completely on Linux if fallocate
FALLOC_FL_ZERO_RANGE or FALLOC_FL_PUNCH_HOLE are supported on
underlying filesystem.
This should seriously increase performance in some special cases.
Signed-off-by: Denis V. Lunev
CC: Kevin Wolf
CC: Stefan Hajnoczi
There is a possibility that we are extending our image and thus writing
zeroes beyond end of the file. In this case we do not need to care
about the hole to make sure that there is no data in the file under
this offset (pre-condition to fallocate(0) to work). We could simply call
fallocate(0).
Thi
The check for maximum length was added by
commit c31cb70728d2c0c8900b35a66784baa446fd5147
Author: Peter Lieven
Date: Thu Oct 24 12:06:58 2013 +0200
block: honour BlockLimits in bdrv_co_do_write_zeroes
but actually if driver provides .bdrv_co_write_zeroes callback, there is
no need to
The pattern
do {
if (fallocate(s->fd, mode, offset, len) == 0) {
return 0;
}
} while (errno == EINTR);
is used twice at the moment and I am going to add more usages. Move it
to the helper function.
Signed-off-by: Denis V. Lunev
CC: Kevin Wolf
CC: Stefan Hajnoc
I can't reproduce this, no matter how hard I try. Tried 4 virtio devices
and 4 e1000 devices (8 network devices in total). Tried 2.1 and 2.2 and
current git. It all Just Works (tm). What I'm doing wrong? :)
--
You received this bug notification because you are a member of qemu-
devel-ml, which
On 26/12/14 13:00, Peter Maydell wrote:
On 26 December 2014 at 08:05, Tiejun Chen wrote:
We should avoid to set irqfd{} unconditionally.
Signed-off-by: Tiejun Chen
Is there a hot path that we use this on such that the difference
in code order matters at all?
thanks
-- PMM
IMHO the patch
On 26 December 2014 at 08:05, Tiejun Chen wrote:
> We should avoid to set irqfd{} unconditionally.
>
> Signed-off-by: Tiejun Chen
Is there a hot path that we use this on such that the difference
in code order matters at all?
thanks
-- PMM
On Thu, Dec 25, 2014 at 08:37:30AM +0300, Denis V. Lunev wrote:
> This sequence works efficiently if FALLOC_FL_ZERO_RANGE is not supported.
> The idea is that FALLOC_FL_PUNCH_HOLE could not increase file size
> but it cleans already allocated blocks inside the file. If we have to
> create something
On Thu, Dec 25, 2014 at 08:37:29AM +0300, Denis V. Lunev wrote:
> +#ifdef CONFIG_FALLOCATE_ZERO_RANGE
> +do {
> +if (fallocate(s->fd, CONFIG_FALLOCATE_ZERO_RANGE,
Must be a typo, FALLOC_FL_ZERO_RANGE is what you mean.
Roman.
On Thu, Dec 25, 2014 at 2:29 AM, Andrew "Truck" Holland
wrote:
> Again, thank you for putting this together. I've enjoyed watching
> each day unfold, several times looking at the site in anticipation
> before the "next day" came up and being dissapointed it wasn't out
> yet. I now have finally d
We should avoid to set irqfd{} unconditionally.
Signed-off-by: Tiejun Chen
---
kvm-all.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 18cc6b4..5b9786b 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1257,21 +1257,21 @@ int kvm_irqc
27 matches
Mail list logo
