On Sun, 07 Aug 2011 21:28:17 +0300
Ronen Hod r...@redhat.com wrote:
Well, we want to support Microsoft's VSS, and that requires a guest
agent that communicates with all the writers (applications), waiting
for them to flush their app data in order to generate a consistent
app-level
Well, we want to support Microsoft's VSS, and that requires a guest
agent that communicates with all the writers (applications), waiting
for them to flush their app data in order to generate a consistent
app-level snapshot. The VSS platform does most of the work.
Still, at the bottom line, the
On Thu, Jul 28, 2011 at 11:53:50AM +0900, Fernando Luis Vázquez Cao wrote:
On Wed, 2011-07-27 at 17:24 +0200, Andrea Arcangeli wrote:
making
sure no lib is calling any I/O function to be able to defreeze the
filesystems later, making sure the oom killer or a wrong kill -9
$RANDOM isn't
On 07/27/11 18:40, Andrea Arcangeli wrote:
Another thing to note is that snapshotting is not necessarily something
that should be completely transparent to the guest. One of the planned
future features for the guest agent (mentioned in the snapshot wiki, and
a common use case that I've
On 07/27/11 20:36, Christoph Hellwig wrote:
Initiating the freeze from kernelspace doesn't make much sense. With
virtio we could add in-band freeze request to the protocol, and although
that would be a major change in that way virtio-blk works right now it's
at least doable. But all other
On 07/28/2011 03:03 AM, Andrea Arcangeli wrote:
On Thu, Jul 28, 2011 at 11:53:50AM +0900, Fernando Luis Vázquez Cao wrote:
On Wed, 2011-07-27 at 17:24 +0200, Andrea Arcangeli wrote:
making
sure no lib is calling any I/O function to be able to defreeze the
filesystems later, making sure the oom
On 07/28/2011 03:54 AM, Jes Sorensen wrote:
On 07/27/11 18:40, Andrea Arcangeli wrote:
Another thing to note is that snapshotting is not necessarily something
that should be completely transparent to the guest. One of the planned
future features for the guest agent (mentioned in the snapshot
Michael Roth さんは書きました:
On 07/28/2011 03:03 AM, Andrea Arcangeli wrote:
On Thu, Jul 28, 2011 at 11:53:50AM +0900, Fernando Luis Vázquez Cao
wrote:
On Wed, 2011-07-27 at 17:24 +0200, Andrea Arcangeli wrote:
making
sure no lib is calling any I/O function to be able to defreeze the
filesystems
Hello everyone,
I've been thinking at the current design of the fsfreeze feature used
by libvirt.
It currently relays on an userland agent in the guest talking to qemu
with some vmchannel communication. The guest agent would walk the
filesystems in the guest and call fsfreeze ioctl on them.
The
On 07/27/2011 10:24 AM, Andrea Arcangeli wrote:
Hello everyone,
I've been thinking at the current design of the fsfreeze feature used
by libvirt.
It currently relays on an userland agent in the guest talking to qemu
with some vmchannel communication. The guest agent would walk the
filesystems
On 07/27/2011 10:24 AM, Andrea Arcangeli wrote:
Hello everyone,
I've been thinking at the current design of the fsfreeze feature used
by libvirt.
It currently relays on an userland agent in the guest talking to qemu
with some vmchannel communication. The guest agent would walk the
filesystems
Hello Michael,
On Wed, Jul 27, 2011 at 11:07:13AM -0500, Michael Roth wrote:
One thing worth mentioning is that the current host-side interface to
the guest agent is not what we're hoping to build libvirt interfaces
around. It's a standalone, out-of-band tool for now, but when QMP is
On Wed, Jul 27, 2011 at 11:34:44AM -0500, Anthony Liguori wrote:
Currently, QEMU doesn't know about fsfreeze. I don't think it ever will
either.
Ah, sorry thanks for the correction, it's some other repo that you
were modifying (qga).
One challenge though is that it's highly desirable to
Initiating the freeze from kernelspace doesn't make much sense. With
virtio we could add in-band freeze request to the protocol, and although
that would be a major change in that way virtio-blk works right now it's
at least doable. But all other real storage targets only communicate
with their
On Wed, Jul 27, 2011 at 08:36:10PM +0200, Christoph Hellwig wrote:
Initiating the freeze from kernelspace doesn't make much sense. With
virtio we could add in-band freeze request to the protocol, and although
that would be a major change in that way virtio-blk works right now it's
at least
On Wed, 2011-07-27 at 17:24 +0200, Andrea Arcangeli wrote:
making
sure no lib is calling any I/O function to be able to defreeze the
filesystems later, making sure the oom killer or a wrong kill -9
$RANDOM isn't killing the agent by mistake while the I/O is blocked
and the copy is going.
Yes
16 matches
Mail list logo
