Il 12/12/2012 10:03, Dietmar Maurer ha scritto:
>>> So our snapshot implementation uses the following steps:
>>>
>>> 1.) qmp: savevm-start [statefile]
>>>
>>> This save the VM state into [statefile] and then stops the VM.
>>
>> That's migrate exec:cat>statefile (or similar)
>
> We save to block de
> > So our snapshot implementation uses the following steps:
> >
> > 1.) qmp: savevm-start [statefile]
> >
> > This save the VM state into [statefile] and then stops the VM.
>
> That's migrate exec:cat>statefile (or similar)
We save to block devices, so we need to allocate them in advance
with a
> > 1.) qmp: savevm-start [statefile]
> >
> > This save the VM state into [statefile] and then stops the VM.
>
> That's migrate exec:cat>statefile (or similar)
Basic functionality is the same, but we support saving state to block devices.
But there are many migration related patches in the last
> So our snapshot implementation uses the following steps:
>
> 1.) qmp: savevm-start [statefile]
>
> This save the VM state into [statefile] and then stops the VM.
That's migrate exec:cat>statefile (or similar)
> 2.) qga freezefs
How can freezefs run while the VM is stopped?
> 3.) create snap
OK, I'll adjust the code into the upstream framework, thanks for your
declaration.
> OK, I will try to give a short overview on the functionality.
>
> First, we decided to use 'internal' snapshots for our 'live snapshot'
> implementation.
> Internal snapshots almost always use some kind of ref
OK, I will try to give a short overview on the functionality.
First, we decided to use 'internal' snapshots for our 'live snapshot'
implementation.
Internal snapshots almost always use some kind of reference counting, making
snapshot action (like 'create/delete snapshot') quite efficient and fast
于 2012-12-10 14:23, Dietmar Maurer 写道:
I can do the clean up or rebase from the url you have given, and include
them as part of my serials. Just want to avoid conflict between your patch
next year and mine by include yours as sub patches. :)
That would be great.
I have read the code fr
>I can do the clean up or rebase from the url you have given, and include
> them as part of my serials. Just want to avoid conflict between your patch
> next year and mine by include yours as sub patches. :)
That would be great.
于 2012-12-9 15:12, Dietmar Maurer 写道:
https://git.proxmox.com/?p=pve-qemu-
kvm.git;a=blob;f=debian/patches/in
ternal-snapshot-
async.patch;h=6c86de3a6160c58d77baa41a7774c4a80e63639e
;hb=HEAD
Unfortunately I had no time to cleanup those patches.
- Dietmar
have that patch been sent to m
> > https://git.proxmox.com/?p=pve-qemu-
> kvm.git;a=blob;f=debian/patches/in
> > ternal-snapshot-
> async.patch;h=6c86de3a6160c58d77baa41a7774c4a80e63639e
> > ;hb=HEAD
> >
> > Unfortunately I had no time to cleanup those patches.
> >
> > - Dietmar
> >
>have that patch been sent to mail-list? I
于 2012-12-7 18:12, Dietmar Maurer 写道:
We already have a full functional implementation to create live snapshots
including VM state.
The interface allows you to create internal snapshots, or use external tools to
create the blockdev snapshots
directly on the underlying storage (we use that with
We already have a full functional implementation to create live snapshots
including VM state.
The interface allows you to create internal snapshots, or use external tools to
create the blockdev snapshots
directly on the underlying storage (we use that with nexenta). VM state is
stored directly
This patch is a scratch which enables a full live backup of VM,
actually it is equal to savevm lively. As a test it uses hmp
command migrate to trigger the action.
The ultimate goal is providing another command to user as:
snapshotvm [with_state] [internal] [live]
which then create vm backups
13 matches
Mail list logo
