On 1 February 2018 at 17:36, sridhar kulkarni wrote:
> Sorry I meant to say arm a7. We are using a custom board "arm-machine" which
> is based on Vexpress-a15 but we use a7 core. I learnt reading through web
> sources that A7 emulation is not supported in qemu. Is this causing this
> behaviour? Bu
On Thursday, February 1, 2018 5:56 PM, Peter Maydell
wrote:
On 1 February 2018 at 12:19, sridhar kulkarni via Qemu-devel
wrote:
> I thought that RAM contents are not saved because of return value
> RAM_SAVE_CONTROL_NOT_SUPP. Now that you clarified about this, I debugged this
> furth
On 1 February 2018 at 12:19, sridhar kulkarni via Qemu-devel
wrote:
> I thought that RAM contents are not saved because of return value
> RAM_SAVE_CONTROL_NOT_SUPP. Now that you clarified about this, I debugged this
> further. After doing loadvm operation, I am getting following
> error,qemu-sy
On Tuesday, January 30, 2018 5:25 PM, Peter Xu wrote:
On Tue, Jan 30, 2018 at 10:34:31AM +, sridhar kulkarni via Qemu-devel
wrote:
> Hi,
> I am new bee to snapshot feature and how to use it correctly. My requirement
> is simple, in that I want to snapshot the running VM and save t
On Tue, Jan 30, 2018 at 10:34:31AM +, sridhar kulkarni via Qemu-devel wrote:
> Hi,
> I am new bee to snapshot feature and how to use it correctly. My requirement
> is simple, in that I want to snapshot the running VM and save the snapshot
> file. Using the snapshot file, I want to boot the VM
Hi,
I am new bee to snapshot feature and how to use it correctly. My requirement is
simple, in that I want to snapshot the running VM and save the snapshot file.
Using the snapshot file, I want to boot the VM directly to snapshot state.I
came across the qemu monitors "savevm" and "loadvm" comman
I am working on creating a snapshot for ARM based VM running on A7. We don't
use disk images, so to save the snapshot I am passing "-drive if=none,
format=qcow2, file=/home/sridhar/qemu_disk_images/dummy.qcow2" as dummy disk to
save the snapshot.
Then from qemu monitor, I run the "savevm" comman
On 11/03/2013 07:41 AM, 宫文超 wrote:
>
>
Top-posted replies to an untrimmed digest message and with an irrelevant
subject line are considered poor netiquette.
>
>
> When i use the savevm command to create a online snapshot i found it's very
> very slow,i found the online snapshot save four dev
On 11/02/2013 01:16 AM, Max Reitz wrote:
> Hi,
>
> Sorry I'm just now replying to this. I ran into the same issue (and
> another one) and it should be fixed by the upstream commits
> eedff66f21e542650d895801549ce05ac108278b and
> 6e13610aa454beba52944e8df6d93158d68ab911. Those have been merged to
Hi,
Sorry I'm just now replying to this. I ran into the same issue (and
another one) and it should be fixed by the upstream commits
eedff66f21e542650d895801549ce05ac108278b and
6e13610aa454beba52944e8df6d93158d68ab911. Those have been merged to
master yesterday, so could you re-build qemu from mas
On 10/16/2013 05:51 PM, Alexey Kardashevskiy wrote:
> On 10/10/2013 02:50 PM, Alexey Kardashevskiy wrote:
>> On 10/09/2013 06:47 PM, Paolo Bonzini wrote:
>>> Il 09/10/2013 09:15, Alexey Kardashevskiy ha scritto:
Sorry for my ignorance (I never ever touched this part of qemu) but how can
y
On 10/10/2013 02:50 PM, Alexey Kardashevskiy wrote:
> On 10/09/2013 06:47 PM, Paolo Bonzini wrote:
>> Il 09/10/2013 09:15, Alexey Kardashevskiy ha scritto:
>>> Sorry for my ignorance (I never ever touched this part of qemu) but how can
>>> you possibly avoid block.c while doing savevm? The qcow2 dr
On 10/09/2013 06:47 PM, Paolo Bonzini wrote:
> Il 09/10/2013 09:15, Alexey Kardashevskiy ha scritto:
>> Sorry for my ignorance (I never ever touched this part of qemu) but how can
>> you possibly avoid block.c while doing savevm? The qcow2 driver must not
>> use posix read()/write(), right? So no m
Il 09/10/2013 09:15, Alexey Kardashevskiy ha scritto:
> Sorry for my ignorance (I never ever touched this part of qemu) but how can
> you possibly avoid block.c while doing savevm? The qcow2 driver must not
> use posix read()/write(), right? So no matter how, all writes end up in
> bdrv_co_do_write
On 10/08/2013 08:33 PM, Paolo Bonzini wrote:
> Il 08/10/2013 11:23, Kevin Wolf ha scritto:
I think you need to modify qcow2_save_vmstate to save and restore
bs->total_sectors. Can you test that and if so post the patch?
>> It's a regression introduced by commit df2a6f29, right?
>
> Yes,
Il 08/10/2013 11:23, Kevin Wolf ha scritto:
>> > I think you need to modify qcow2_save_vmstate to save and restore
>> > bs->total_sectors. Can you test that and if so post the patch?
> It's a regression introduced by commit df2a6f29, right?
Yes, that's what introduced the "if".
> What you sugges
Am 08.10.2013 um 11:04 hat Paolo Bonzini geschrieben:
> Il 08/10/2013 10:40, Alexey Kardashevskiy ha scritto:
> > However qcow2_save_vmstate() sets bs->growable to 1 for a short time
> > (commit 178e08a58f40dd5aef2ce774fe0850f5d0e56918 from 2009) and this
> > triggers a branch in bdrv_co_do_writev(
Il 08/10/2013 10:40, Alexey Kardashevskiy ha scritto:
> However qcow2_save_vmstate() sets bs->growable to 1 for a short time
> (commit 178e08a58f40dd5aef2ce774fe0850f5d0e56918 from 2009) and this
> triggers a branch in bdrv_co_do_writev() which changes bs->total_sectors.
> So when QEMU writes snaps
Hi!
I need the community help with savevm/loadvm.
I run QEMU like this:
./qemu-system-ppc64 \
-drive file=virtimg/fc19_16GB.qcow2 \
-nodefaults \
-m "2048" \
-machine "pseries" \
-nographic \
-vga "none" \
-enable-kvm
The disk image is an 16GB qcow2 image.
Now I start the guest and do
Am 09.09.2013 um 10:47 hat xuanmao_001 geschrieben:
> > I sent patches that should eliminate the difference between the first
> > and second snapshot at least.
>
> where I can find the patches that can
> eliminate the difference between the first
> and second snapshot ? Does they fit qemu-kvm-1.0
> I sent patches that should eliminate the difference between the first
> and second snapshot at least.
where I can find the patches that can eliminate the difference between the first
and second snapshot ? Does they fit qemu-kvm-1.0,1 ?
xuanmao_001
From: Kevin Wolf
Date: 2013-09-09 16:35
To:
Am 09.09.2013 um 03:57 hat xuanmao_001 geschrieben:
> >> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> >> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
>
> > Is this for cache=unsafe as well?
>
> > Juan, any specific reason for using 32k?
>> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
>> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
> Is this for cache=unsafe as well?
> Juan, any specific reason for using 32k? I think it would be better to
> have a multiple of the qcow2 clust
Am 06.09.2013 um 03:31 hat xuanmao_001 geschrieben:
> Hi, qemuers:
>
> I found that the guest disk file cache mode will affect to the time of savevm.
>
> the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
> less than 10 seconds.
>
> here is the example I use virsh:
>
Hi, qemuers:
I found that the guest disk file cache mode will affect to the time of savevm.
the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
less than 10 seconds.
here is the example I use virsh:
@cache with writeback:
#the first snapshot
real0m21.904s
user0m
Hello,
http://www.boblycat.org/~malc/savevm.patch.gz
The problem is Paul Brook had broken the save state for keyboard by
introducing translate and not saving/loading it.
--
mailto:[EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
h
Hi,
On Wed, 26 Oct 2005, Henrik Nordstrom wrote:
> On Tue, 25 Oct 2005, Vesselin Peev wrote:
>
> > Yes, it does, thanks. Saves a finger stretch and one hitting one more key
> > :).
> > Also, one could hit them in any order, and any number of keys between them.
>
> Someone probably should wip to
On Wed, Oct 26, 2005 at 09:29:36PM +1300, Wesley Parish wrote:
> Thanks heaps! It works!
>
> (It should go in the docs, though. Is Fabrice okay with me adding that to
> them? ;)
>
=loadvm is in the man oage. so it's already in the docs.
> Wesley Parish
>
> On Wed, 26 Oct 2005 00:50, Johann
Thanks heaps! It works!
(It should go in the docs, though. Is Fabrice okay with me adding that to
them? ;)
Wesley Parish
On Wed, 26 Oct 2005 00:50, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 25 Oct 2005, Wesley Parish wrote:
> > when restoring a vm state saved to a file?
> >
> > Eg, do I f
On Tue, 25 Oct 2005, Vesselin Peev wrote:
Yes, it does, thanks. Saves a finger stretch and one hitting one more key :).
Also, one could hit them in any order, and any number of keys between them.
Someone probably should wip together a patch to sent Ctrl and Alt keyup
events to the guest when
Hi Johannes,
Please try this: do not go to the monitor, but hit Ctrl and Alt without
any other key. I bet the keyboard works after that...
Yes, it does, thanks. Saves a finger stretch and one hitting one more key
:).
Also, one could hit them in any order, and any number of keys between them.
Hi,
On Tue, 25 Oct 2005, Vesselin Peev wrote:
> I have found when I do so, I can't use the keyboard once everything is up and
> running (the mouse works). To work around that, go to the monitor momentarily
> (doing nothing there) and then back. The keyboard will work then.
Please try this: do no
riginal Message -
From: "Wesley Parish" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, October 25, 2005 11:32 AM
Subject: [Qemu-devel] (savevm and loadvm) appropriate order of events
when restoring a vm state saved to a file?
Eg, do I fire up qemu with this sort of invocation:
qemu -boo
Hi,
On Tue, 25 Oct 2005, Wesley Parish wrote:
> when restoring a vm state saved to a file?
>
> Eg, do I fire up qemu with this sort of invocation:
> qemu -boot c -hda
How ´bout
qemu -hda -loadvm
Hth,
Dscho___
Qemu-devel mailing list
Qemu
when restoring a vm state saved to a file?
Eg, do I fire up qemu with this sort of invocation:
qemu -boot c -hda
then later jump into the monitor and
loadvm
Or is there some other sequence of events? Some other method of importing the
saved vm filename?
Thanks
Wesley Parish
--
Clinerster
35 matches
Mail list logo