On Thu, Aug 25, 2011 at 3:06 PM, Eric Blake ebl...@redhat.com wrote:
On 08/25/2011 05:54 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:47 PM, Eric Blakeebl...@redhat.com wrote:
On 08/23/2011 09:35 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:18 PM, Eric
On Tue, Aug 23, 2011 at 4:47 PM, Eric Blake ebl...@redhat.com wrote:
On 08/23/2011 09:35 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:18 PM, Eric Blakeebl...@redhat.com wrote:
On 08/23/2011 09:12 AM, Stefan Hajnoczi wrote:
The
kinds of apps I am thinking about cannot make use of
On 08/25/2011 05:54 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:47 PM, Eric Blakeebl...@redhat.com wrote:
On 08/23/2011 09:35 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:18 PM, Eric Blakeebl...@redhat.comwrote:
On 08/23/2011 09:12 AM, Stefan Hajnoczi wrote:
The
On Wed, Aug 10, 2011 at 11:08 PM, Eric Blake ebl...@redhat.com wrote:
disk snapshot: the state of a virtual disk used at a given time; once a
snapshot exists, then it is possible to track a delta of changes that have
happened since that time.
Did you go into details of the delta API anywhere?
On 08/23/2011 03:52 AM, Stefan Hajnoczi wrote:
On Wed, Aug 10, 2011 at 11:08 PM, Eric Blakeebl...@redhat.com wrote:
disk snapshot: the state of a virtual disk used at a given time; once a
snapshot exists, then it is possible to track a delta of changes that have
happened since that time.
Did
On 08/23/2011 04:28 AM, Stefan Hajnoczi wrote:
I forgot to ask the obvious question:
I am writing a backup program that is using the new snapshot APIs. A
snapshot has been created, how do I read out the data from the
snapshot?
Here's how to access the data in the snapshot, at least for the
On Tue, Aug 23, 2011 at 2:48 PM, Eric Blake ebl...@redhat.com wrote:
On 08/23/2011 04:28 AM, Stefan Hajnoczi wrote:
I forgot to ask the obvious question:
I am writing a backup program that is using the new snapshot APIs. A
snapshot has been created, how do I read out the data from the
On Tue, Aug 23, 2011 at 2:40 PM, Eric Blake ebl...@redhat.com wrote:
On 08/23/2011 03:52 AM, Stefan Hajnoczi wrote:
On Wed, Aug 10, 2011 at 11:08 PM, Eric Blakeebl...@redhat.com wrote:
disk snapshot: the state of a virtual disk used at a given time; once a
snapshot exists, then it is
On 08/23/2011 09:12 AM, Stefan Hajnoczi wrote:
Hmm...so there is no abstraction. I still need to understand what the
underlying snapshot implementation does and what its limitations are.
We're still trying to get to that point. A while ago, I posted an RFC
for adding virStorageVolSnapshot*
On Tue, Aug 23, 2011 at 4:18 PM, Eric Blake ebl...@redhat.com wrote:
On 08/23/2011 09:12 AM, Stefan Hajnoczi wrote:
I think we simply cannot expose all this complexity to users. Each
application would have to support the many different cases. Libvirt
needs to tie this stuff together and
On 08/23/2011 09:35 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:18 PM, Eric Blakeebl...@redhat.com wrote:
On 08/23/2011 09:12 AM, Stefan Hajnoczi wrote:
I think we simply cannot expose all this complexity to users. Each
application would have to support the many different cases.
On 08/10/2011 04:08 PM, Eric Blake wrote:
The disks element has an optional number of disk subelements; at
most one per disk in the devices section of domain. Each disk
element has a mandatory attribute name='name', which must match the
target dev='name'/ of the domain xml, as a way of getting
On 08/12/2011 08:33 AM, Eric Blake wrote:
On 08/11/2011 08:36 PM, Eric Blake wrote:
In implementing this in virsh, I found that for backwards compatibility
reasons, it would be easier to two flags instead of one, since both use
cases seem plausible (do the bare minimum to remove my domain, but
On 08/10/2011 04:08 PM, Eric Blake wrote:
Next, we need a way to control which subset of disks is involved in a
snapshot command. Previous mail has documented that for ESX, the
decision can only be made at boot time - a disk can be persistent
(involved in snapshots, and saves changes across
Hello Kevin, hello Eric,
On Thursday 11 August 2011 12:00:46 Kevin Wolf wrote:
Am 11.08.2011 00:08, schrieb Eric Blake:
Libvirt currently has a bug in that it only saves domain/uuid rather
than the full domain xml along with a checkpoint - if any devices are
hot-plugged (or in the case of
Am 12.08.2011 09:18, schrieb Philipp Hahn:
Hello Kevin, hello Eric,
On Thursday 11 August 2011 12:00:46 Kevin Wolf wrote:
Am 11.08.2011 00:08, schrieb Eric Blake:
Libvirt currently has a bug in that it only saves domain/uuid rather
than the full domain xml along with a checkpoint - if any
Hello Kevin,
Am Freitag 12 August 2011 10:04:07 schrieb Kevin Wolf:
Am 12.08.2011 09:18, schrieb Philipp Hahn:
On Thursday 11 August 2011 12:00:46 Kevin Wolf wrote:
Am 11.08.2011 00:08, schrieb Eric Blake:
Libvirt currently has a bug in that it only saves domain/uuid
rather than the full
On 08/12/2011 02:56 AM, Philipp Hahn wrote:
For -loadvm to work you have to call kvm with the nearly same command
line arguments again; what may change you probably know better than me.
For I thinks it's essential to store the VM consiguration with the
snapshot, which would be the qemu command
On 08/11/2011 08:36 PM, Eric Blake wrote:
In implementing this in virsh, I found that for backwards compatibility
reasons, it would be easier to two flags instead of one, since both use
cases seem plausible (do the bare minimum to remove my domain, but
wihtout losing snapshot data, vs. nuke
On 08/12/2011 08:33 AM, Eric Blake wrote:
On 08/11/2011 08:36 PM, Eric Blake wrote:
In implementing this in virsh, I found that for backwards compatibility
reasons, it would be easier to two flags instead of one, since both use
cases seem plausible (do the bare minimum to remove my domain, but
Am 11.08.2011 00:08, schrieb Eric Blake:
[BCC'ing those who have responded to earlier RFC's]
I've posted previous RFCs for improving snapshot support:
ideas on managing a subset of disks:
https://www.redhat.com/archives/libvir-list/2011-May/msg00042.html
ideas on managing snapshots of
On 08/11/2011 04:00 AM, Kevin Wolf wrote:
Am 11.08.2011 00:08, schrieb Eric Blake:
After re-reading the feedback received on those threads, I think I've
settled on a pretty robust design for my first round of adding
improvements to the management of snapshots tied to a domain, while
leaving the
[ CCed qemu-devel, just in case someone's interested ]
Am 11.08.2011 15:23, schrieb Eric Blake:
[ Okay, some of it is handled later in this document, but I think it's
still useful to leave this summary in my mail. External VM state is
something that you don't seem to have covered yet - can't
On 08/11/2011 08:11 AM, Kevin Wolf wrote:
I agree with you. It feels a bit backwards for snapshots, but it's
really the only reasonable thing to do if you're using external
snapshots. That you can't rename block devices is actually a very point
point, too.
There's one more point to consider: If
On 08/10/2011 04:08 PM, Eric Blake wrote:
I'm not sure I covered this well earlier, but another useful definition is:
current snapshot - if this exists, it is the snapshot that would
become the parent if a new snapshot were created; or put another way, it
is the snapshot to which our current
On 08/10/2011 04:08 PM, Eric Blake wrote:
Undefining
++
In one regards, undefining a domain that has snapshots is just as bad as
undefining a domain with managed save state - since libvirt is
maintaining metadata about snapshot hierarchies, leaving this metadata
behind _will_ interfere
On 08/11/2011 02:50 PM, Eric Blake wrote:
On 08/10/2011 04:08 PM, Eric Blake wrote:
Undefining
++
Meanwhile, I propose changing the default behavior of
virDomainUndefine[Flags] to reject attempts to undefine a domain with
any defined snapshots, and to add a new flag for
[BCC'ing those who have responded to earlier RFC's]
I've posted previous RFCs for improving snapshot support:
ideas on managing a subset of disks:
https://www.redhat.com/archives/libvir-list/2011-May/msg00042.html
ideas on managing snapshots of storage volumes not tied to a domain
28 matches
Mail list logo
