Forwarding to the alias.
Thanks,
Vinod
Original Message
Subject:Re: [RFC 0/7] Migration stats
Date: Mon, 13 Aug 2012 15:20:10 +0200
From: Juan Quintela
Reply-To:
To: Chegu Vinod
CC:
[ snip ]
>> - Prints the real downtime that we ha
On 10/13/2012 12:32 AM, Gleb Natapov wrote:
On Fri, Oct 12, 2012 at 07:38:42PM -0700, Chegu Vinod wrote:
Hello,
I am using a very recent upstream version of qemu.git along with
kvm.git kernels (in the host and guest).
[Guest kernel had been compiled with CONFIG_X86_X2APIC and
On 10/29/2012 9:21 AM, Vinod, Chegu wrote:
Date: Mon, 29 Oct 2012 15:11:25 +0100
From: Juan Quintela
To: qemu-devel@nongnu.org
Cc: owass...@redhat.com, mtosa...@redhat.com, a...@redhat.com,
pbonz...@redhat.com
Subject: [Qemu-devel] [PATCH 00/18] Migration thread lite (20121029)
Hi
Afte
6 MB
node 4 cpus: 40 41 42 43 44 45 46 47 48 49
node 4 size: 65536 MB
node 5 cpus: 50 51 52 53 54 55 56 57 58 59
node 5 size: 65536 MB
node 6 cpus: 60 61 62 63 64 65 66 67 68 69
node 6 size: 65536 MB
node 7 cpus: 70 71 72 73 74 75 76 77 78 79
node 7 size: 65536 MB
Signed-off-by: Chegu Vin
On 6/18/2012 1:29 PM, Eduardo Habkost wrote:
On Sun, Jun 17, 2012 at 01:12:31PM -0700, Chegu Vinod wrote:
The -numa option to qemu is used to create [fake] numa nodes
and expose them to the guest OS instance.
There are a couple of issues with the -numa option:
a) Max VCPU's that c
On 6/18/2012 3:11 PM, Eric Blake wrote:
On 06/18/2012 04:05 PM, Andreas Färber wrote:
Am 17.06.2012 22:12, schrieb Chegu Vinod:
diff --git a/vl.c b/vl.c
index 204d85b..1906412 100644
--- a/vl.c
+++ b/vl.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
Did you check whether this
ode 5 cpus: 50 51 52 53 54 55 56 57 58 59
node 5 size: 65536 MB
node 6 cpus: 60 61 62 63 64 65 66 67 68 69
node 6 size: 65536 MB
node 7 cpus: 70 71 72 73 74 75 76 77 78 79
Signed-off-by: Chegu Vinod , Jim Hull ,
Craig Hada
---
cpus.c |3 ++-
hw/pc.c |4 +++-
sysemu.h |3 ++-
vl.
node 3 cpus: 30 31 32 33 34 35 36 37 38 39
node 3 size: 65536 MB
node 4 cpus: 40 41 42 43 44 45 46 47 48 49
node 4 size: 65536 MB
node 5 cpus: 50 51 52 53 54 55 56 57 58 59
node 5 size: 65536 MB
node 6 cpus: 60 61 62 63 64 65 66 67 68 69
node 6 size: 65536 MB
node 7 cpus: 70 71 72 73 74 75 76
migration: calculate expected_downtime
arch_init.c | 1 +
include/migration/migration.h | 1 +
migration.c | 15 +--
3 files changed, 15 insertions(+), 2 deletions(-)
Reviewed-by: Chegu Vinod
On 2/15/2013 9:46 AM, Paolo Bonzini wrote:
This series does many of the improvements that the migration thread
promised. It removes buffering, lets a large amount of code run outside
the big QEMU lock, and removes some duplication between incoming and
outgoing migration.
Patches 1 to 7 are simp
Hi Satoru,
FYI... I had tried to use this change earlier and it did show some
improvements in perf. (due to reduced exits).
But as expected mlockall () on large sized guests adds a considerable
delay in boot time. For e.g. on an 8 socket Westmere box => a 256G guest
: took an additional ~2+
ning on a 80VCPU/512G guest (~80% busy)
Thanks to Juan and Paolo for some useful suggestions. More
refinment is needed (e.g. smarter way to detect & variable
throttling based on need etc). For now I was hoping to get
some feedback or hear about other more refined ideas.
Signed-o
On 4/24/2013 6:59 PM, Anthony Liguori wrote:
On Wed, Apr 24, 2013 at 6:42 PM, Chegu Vinod <mailto:chegu_vi...@hp.com>> wrote:
Busy enterprise workloads hosted on large sized VM's tend to dirty
memory faster than the transfer rate achieved via live guest
migration.
On 6/4/2012 6:13 AM, Isaku Yamahata wrote:
On Mon, Jun 04, 2012 at 05:01:30AM -0700, Chegu Vinod wrote:
Hello Isaku Yamahata,
Hi.
I just saw your patches..Would it be possible to email me a tar bundle of these
patches (makes it easier to apply the patches to a copy of the upstream
qemu.git
On 6/8/2012 11:08 AM, Jan Kiszka wrote:
[CC'ing qemu as this discusses its code base]
On 2012-06-08 19:57, Chegu Vinod wrote:
On 6/8/2012 10:42 AM, Alex Williamson wrote:
On Fri, 2012-06-08 at 10:10 -0700, Chegu Vinod wrote:
On 6/8/2012 9:46 AM, Alex Williamson wrote:
On Fri, 2012-06-
On 6/10/2012 2:30 AM, Gleb Natapov wrote:
On Fri, Jun 08, 2012 at 11:20:53AM -0700, Chegu Vinod wrote:
On 6/8/2012 11:08 AM, Jan Kiszka wrote:
BTW, another data point ...if I try to boot a the RHEL6.3 kernel in
the guest (with the latest qemu.git and the 3.4.1 on the host) it
boots just fine
Hello,
I did pick up these patches a while back and did run some migration tests while
running simple workloads in the guest. Below are some results.
FYI...
Vinod
Config Details:
Guest 10vcps, 60GB (running on a host that is 6cores(12threads) and 64GB).
The hosts are identical X86_64 Bla
Hello,
'am having some issues trying to live migrate a large guest and would
like to get some pointers
on how to go about about debugging this. Here is some info. on the
configuration
_Hardware :_
Two DL980's each with 80 Westmere cores + 1 TB of RAM. Using a 10G NIC
private link
(back to
On 6/8/2012 11:37 AM, Jan Kiszka wrote:
On 2012-06-08 20:20, Chegu Vinod wrote:
On 6/8/2012 11:08 AM, Jan Kiszka wrote:
[CC'ing qemu as this discusses its code base]
On 2012-06-08 19:57, Chegu Vinod wrote:
On 6/8/2012 10:42 AM, Alex Williamson wrote:
On Fri, 2012-06-08 at 10:10 -0700,
On 6/12/2012 8:39 AM, Gleb Natapov wrote:
On Tue, Jun 12, 2012 at 08:33:59AM -0700, Chegu Vinod wrote:
I rebuilt the 3.4.1 kernel in the guest from scratch and retried my
experiments and measured
the boot times...
a) Host : RHEL6.3 RC1 + qemu-kvm (that came with it)& Guest :
RHEL6.3
Eric Blake.
Signed-off-by: Chegu Vinod
---
arch_init.c | 44 +++
cpus.c| 12 +
include/migration/migration.h | 12 +
include/qemu/main-loop.h
On 4/29/2013 7:53 AM, Eric Blake wrote:
On 04/27/2013 02:50 PM, Chegu Vinod wrote:
Busy enterprise workloads hosted on large sized VM's tend to dirty
memory faster than the transfer rate achieved via live guest migration.
Despite some good recent improvements (& using dedicated 1
On 4/30/2013 8:20 AM, Juan Quintela wrote:
Chegu Vinod wrote:
Busy enterprise workloads hosted on large sized VM's tend to dirty
memory faster than the transfer rate achieved via live guest migration.
Despite some good recent improvements (& using dedicated 10Gig NICs
between hosts)
On 4/30/2013 9:01 AM, Juan Quintela wrote:
Chegu Vinod wrote:
On 4/30/2013 8:20 AM, Juan Quintela wrote:
(qemu) info migrate
capabilities: xbzrle: off auto-converge: off <
Migration status: active
total time: 1487503 milliseconds
148 seconds
1487 seconds and still the Migration is
On 4/30/2013 8:04 AM, Orit Wasserman wrote:
On 04/27/2013 11:50 PM, Chegu Vinod wrote:
Busy enterprise workloads hosted on large sized VM's tend to dirty
memory faster than the transfer rate achieved via live guest migration.
Despite some good recent improvements (& using dedicated 1
ttling thread at the start of stage 3
- rebased to latest qemu.git
Changes from v1:
- rebased to latest qemu.git
- added auto-converge capability(default off) - suggested by Anthony Liguori &
Eric Blake.
Signed-off-by: Chegu Vinod
--
On 5/1/2013 5:38 AM, Eric Blake wrote:
On 05/01/2013 06:22 AM, Chegu Vinod wrote:
Busy enterprise workloads hosted on large sized VM's tend to dirty
memory faster than the transfer rate achieved via live guest migration.
Despite some good recent improvements (& using dedicated 1
On 5/1/2013 8:40 AM, Paolo Bonzini wrote:
I shall make the suggested changes.
Appreciate your review feedback on this part of the change.
Hi Paolo.,
Thanks for taking a look (BTW, I accidentally left out the "RFC" in the
patch subject line...my bad!).
Hi Vinod,
I think unfortunately it is n
Hi Michael,
I picked up the qemu bits from your github branch and gave it a try.
(BTW the setup I was given temporary access to has a pair of MLX's IB
QDR cards connected back to back via QSFP cables)
Observed a couple of things and wanted to share..perhaps you may be
aware of them alrea
off) - suggested by Anthony Liguori &
Eric Blake.
Signed-off-by: Chegu Vinod
---
arch_init.c | 61 -
cpus.c| 41 +++
include/migration/migration.h |7 +
include/qemu-common.h
The auto-converge migration capability allows the user to specify if they
choose live migration seqeunce to automatically detect and force convergence.
Signed-off-by: Chegu Vinod
---
include/migration/migration.h |2 ++
migration.c |9 +
qapi-schema.json
rit, Juan and Eric
- stop the throttling thread at the start of stage 3
- rebased to latest qemu.git
Changes from v1:
- rebased to latest qemu.git
- added auto-converge capability(default off) - suggested by Anthony Liguori &
Eric Blake.
Signed-off
Introduce an asynchronous version of run_on_cpu() i.e. the caller
doesn't have to block till the call back routine finishes execution
on the target vcpu.
Signed-off-by: Chegu Vinod
---
cpus.c| 29 +
include/qemu-common.h |1 +
includ
al ram: 268444224 kbytes
duplicate: 64946416 pages
skipped: 64903523 pages
normal: 7044971 pages
normal bytes: 28179884 kbytes
Signed-off-by: Chegu Vinod
---
arch_init.c | 68 +
include/migration/migration.h |4 ++
migra
07:28 PM, Chegu Vinod wrote:
Hi Michael,
I picked up the qemu bits from your github branch and gave it a
try. (BTW the setup I was given temporary access to has a pair of
MLX's IB QDR cards connected back to back via QSFP cables)
Observed a couple of things and wanted to share..pe
On 5/9/2013 1:05 PM, Igor Mammedov wrote:
On Thu, 9 May 2013 12:43:20 -0700
Chegu Vinod wrote:
If a user chooses to turn on the auto-converge migration capability
these changes detect the lack of convergence and throttle down the
guest. i.e. force the VCPUs out of the guest for some
On 5/9/2013 1:24 PM, Igor Mammedov wrote:
On Thu, 9 May 2013 12:43:20 -0700
Chegu Vinod wrote:
If a user chooses to turn on the auto-converge migration capability
these changes detect the lack of convergence and throttle down the
guest. i.e. force the VCPUs out of the guest for some
On 5/10/2013 6:07 AM, Anthony Liguori wrote:
Chegu Vinod writes:
If a user chooses to turn on the auto-converge migration capability
these changes detect the lack of convergence and throttle down the
guest. i.e. force the VCPUs out of the guest for some duration
and let the migration
hanged, 260 insertions(+), 181 deletions(-)
create mode 100644 include/exec/memory-physical.h
.
Tested-by: Chegu Vinod
---
Hi Juan,
Here are some results from migrating couple of*big fat* guests using TCP
migration and RDMA migration and the last one was with a workload. As one would
On 3/11/2014 1:48 PM, Juan Quintela wrote:
wrote:
From: ChenLiang
It is inaccuracy and complex that using the transfer speed of
migration thread to determine whether the convergence migration.
The dirty page may be compressed by XBZRLE or ZERO_PAGE.The counter
of updating dirty bitmap will be
On 11/13/2012 8:18 AM, Juan Quintela wrote:
Hi
If you have anything else to put, please add.
Migration Thread
* Plan is integrate it as one of first thing in December (me)
* Remove copies with buffered file (me)
Bitmap Optimization
* Finish moving to individual bitmaps for migration/vga/code
*
Hello,
'am running into an issue with the latest bits. [ Pl. see below. The
vhost thread seems to be getting
stuck while trying to memcopy...perhaps a bad address?. ] Wondering if
this is a known issue or
some recent regression ?
'am using the latest qemu (from qemu.git) and the latest kvm.
On 1/9/2013 8:35 PM, Jason Wang wrote:
On 01/10/2013 04:25 AM, Chegu Vinod wrote:
Hello,
'am running into an issue with the latest bits. [ Pl. see below. The
vhost thread seems to be getting
stuck while trying to memcopy...perhaps a bad address?. ] Wondering
if this is a known issue or
Hello,
I have been noticing host hangs when trying to boot large guests
(>=40Vcpus) with the current upstream qemu.
Host is running 3.8.2 kernel.
qemu is the latest one from qemu.git.
Example qemu command line listed below... this used to work with a
slightly older qemu (about 1.5 weeks ago
}
+ if (unlikely(disable_hugepages)) {
+ vfio_lock_acct(1);
+ return 1;
+ }
+
/* Lock all the consecutive pages from pfn_base */
for (i = 1, vaddr += PAGE_SIZE; i < npage; i++, vaddr += PAGE_SIZE) {
unsigned long pfn = 0;
.
Te
Hello,
For guest sizes >= 1TB RAM the guest OS is unable to boot up (please
see attached GIF file for the Oops message). Wonder if this is a
bug/regression in qemu/seabios or does one have to enable/disable
something else in the qemu command line (pl. see below) ?
Thanks
Vinod
Host and G
On 6/1/2013 9:09 PM, Michael R. Hines wrote:
All,
I have successfully performed over 1000+ back-to-back RDMA migrations
automatically looped *in a row* using a heavy-weight memory-stress
benchmark here at IBM.
Migration success is done by capturing the actual serial console
output of the virt
Introduce an asynchronous version of run_on_cpu() i.e. the caller
doesn't have to block till the call back routine finishes execution
on the target vcpu.
Signed-off-by: Chegu Vinod
Reviewed-by: Paolo Bonzini
---
cpus.c| 29 +
include/qemu-com
al ram: 268444224 kbytes
duplicate: 64946416 pages
skipped: 64903523 pages
normal: 7044971 pages
normal bytes: 28179884 kbytes
Signed-off-by: Chegu Vinod
---
arch_init.c | 85 +++
1 files changed, 85 insertions(+), 0 deletions(-)
diff -
f) - suggested by Anthony Liguori &
Eric Blake.
Signed-off-by: Chegu Vinod
---
Chegu Vinod (3):
Introduce async_run_on_cpu()
Add 'auto-converge' migration capability
Force auto-convegence of live m
The auto-converge migration capability allows the user to specify if they
choose live migration seqeunce to automatically detect and force convergence.
Signed-off-by: Chegu Vinod
Reviewed-by: Paolo Bonzini
Reviewed-by: Eric Blake
---
include/migration/migration.h |2 ++
migration.c
On 6/14/2013 1:38 PM, Michael R. Hines wrote:
Chegu,
I sent a V9 to the mailing list:
The version goes even further, by explicitly timing the pinning
latency and
pushing the value out to QMP so the user clearly knows which component
of total migration time is consumed by pinning.
If you're s
Reviewed-by: Paolo Bonzini
Reviewed-by: Chegu Vinod
Tested-by: Chegu Vinod
Thx
Vinod
Wiki: http://wiki.qemu.org/Features/RDMALiveMigration
Github: g...@github.com:hinesmr/qemu.git
Here is a brief summary of total migration time and downtime using RDMA:
Using a 40gbps infiniband link per
On 6/14/2013 1:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: "Michael R. Hines"
For very large virtual machines, pinning can take a long time.
While this does not affect the migration's *actual* time itself,
it is still important for the user to know what's going on and
to know what component
On 6/20/2013 5:54 AM, Paolo Bonzini wrote:
Il 14/06/2013 15:58, Chegu Vinod ha scritto:
If a user chooses to turn on the auto-converge migration capability
these changes detect the lack of convergence and throttle down the
guest. i.e. force the VCPUs out of the guest for some duration
and let
Introduce an asynchronous version of run_on_cpu() i.e. the caller
doesn't have to block till the call back routine finishes execution
on the target vcpu.
Signed-off-by: Chegu Vinod
Reviewed-by: Paolo Bonzini
---
cpus.c| 29 +
include/qemu-com
v1:
- rebased to latest qemu.git
- added auto-converge capability(default off) - suggested by Anthony Liguori &
Eric Blake.
Signed-off-by: Chegu Vinod
---
Chegu Vinod (3):
Introduce async_run_on_cpu()
Add 'auto-converge' migra
al ram: 268444224 kbytes
duplicate: 64946416 pages
skipped: 64903523 pages
normal: 7044971 pages
normal bytes: 28179884 kbytes
Signed-off-by: Chegu Vinod
---
arch_init.c | 79 +++
1 files changed, 79 insertions(+), 0 deletions(-)
diff -
The auto-converge migration capability allows the user to specify if they
choose live migration seqeunce to automatically detect and force convergence.
Signed-off-by: Chegu Vinod
Reviewed-by: Paolo Bonzini
Reviewed-by: Eric Blake
---
include/migration/migration.h |2 ++
migration.c
al ram: 268444224 kbytes
duplicate: 64946416 pages
skipped: 64903523 pages
normal: 7044971 pages
normal bytes: 28179884 kbytes
Signed-off-by: Chegu Vinod
---
arch_init.c | 79 +++
1 files changed, 79 insertions(+), 0 deletions(-)
diff -
Oops! A minor glitch on my side (pl. ignore the subject line of
this...as this is actually patch 3/3 and not patch 2/3). I just resent
this as patch 3/3 with the correct subject line.
Thx
Vinod
On 6/23/2013 1:05 PM, Chegu Vinod wrote:
If a user chooses to turn on the auto-converge
On 6/24/2013 6:01 AM, Paolo Bonzini wrote:
One nit and one question:
Il 23/06/2013 22:11, Chegu Vinod ha scritto:
@@ -404,6 +413,23 @@ static void migration_bitmap_sync(void)
/* more than 1 second = 1000 millisecons */
if (end_time > start_time + 1000) {
+
al ram: 268444224 kbytes
duplicate: 64946416 pages
skipped: 64903523 pages
normal: 7044971 pages
normal bytes: 28179884 kbytes
Signed-off-by: Chegu Vinod
---
arch_init.c | 79 +++
1 files changed, 79 insertions(+), 0 deletions(-)
diff -
rt of stage 3
- rebased to latest qemu.git
Changes from v1:
- rebased to latest qemu.git
- added auto-converge capability(default off) - suggested by Anthony Liguori &
Eric Blake.
Signed-off-by: Chegu Vinod
---
Chegu Vinod (3):
Introduce as
The auto-converge migration capability allows the user to specify if they
choose live migration seqeunce to automatically detect and force convergence.
Signed-off-by: Chegu Vinod
Reviewed-by: Paolo Bonzini
Reviewed-by: Eric Blake
---
include/migration/migration.h |2 ++
migration.c
Introduce an asynchronous version of run_on_cpu() i.e. the caller
doesn't have to block till the call back routine finishes execution
on the target vcpu.
Signed-off-by: Chegu Vinod
Reviewed-by: Paolo Bonzini
---
cpus.c| 29 +
include/qemu-com
On 6/24/2013 8:59 AM, Paolo Bonzini wrote:
Il 24/06/2013 11:47, Chegu Vinod ha scritto:
If a user chooses to turn on the auto-converge migration capability
these changes detect the lack of convergence and throttle down the
guest. i.e. force the VCPUs out of the guest for some duration
and let
ode 3 size: 65536 MB
node 4 cpus: 40 41 42 43 44 45 46 47 48 49
node 4 size: 65536 MB
node 5 cpus: 50 51 52 53 54 55 56 57 58 59
node 5 size: 65536 MB
node 6 cpus: 60 61 62 63 64 65 66 67 68 69
node 6 size: 65536 MB
node 7 cpus: 70 71 72 73 74 75 76 77 78 79
Signed-off-by: Chegu
Original Message
Subject:[Qemu-devel] [RFC 00/27] Migration thread (WIP)
Date: Tue, 24 Jul 2012 20:36:25 +0200
From: Juan Quintela
To: qemu-devel@nongnu.org
Hi
This series are on top of the migration-next-v5 series just posted.
First of all, this is an RF
On 7/26/2012 11:41 AM, Chegu Vinod wrote:
Original Message
Subject:[Qemu-devel] [RFC 00/27] Migration thread (WIP)
Date: Tue, 24 Jul 2012 20:36:25 +0200
From: Juan Quintela
To: qemu-devel@nongnu.org
Hi
This series are on top of the migration-next-v5
On 7/27/2012 7:11 AM, Vinod, Chegu wrote:
-Original Message-
From: Juan Quintela [mailto:quint...@redhat.com]
Sent: Friday, July 27, 2012 4:06 AM
To: Vinod, Chegu
Cc: qemu-devel@nongnu.org; Orit Wasserman
Subject: Re: Fwd: [RFC 00/27] Migration thread (WIP)
Chegu Vinod wrote:
On 7/26
71 matches
Mail list logo
