On 04/29/11 15:45, Anthony Liguori wrote:
On 04/29/2011 08:38 AM, Jes Sorensen wrote:
It is exactly the same for the management tool:
- Creation of the new image either succeeds or fails
- Switchover either succeeds or fails
Creating an image can be treated as an atomic operation. It
On 04/28/11 17:10, Anthony Liguori wrote:
On 04/28/2011 09:57 AM, Jes Sorensen wrote:
On 04/28/11 16:46, Anthony Liguori wrote:
Sorry this is inherently broken. The management tool should not be
keeping state in this process. I agree an async interface would be nice,
but the above process is
On 04/29/2011 08:38 AM, Jes Sorensen wrote:
On 04/28/11 17:10, Anthony Liguori wrote:
No, the command does too many things and as such, makes it impossible
for a management tool to gracefully recover.
It is exactly the same for the management tool:
- Creation of the new image either succeeds
On 04/27/11 17:05, Jes Sorensen wrote:
On 04/27/11 17:05, Luiz Capitulino wrote:
On Mon, 18 Apr 2011 16:27:01 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
This is quivalent to snapshot_blkdev in the human monitor, with _sync
added to the command name to
On 04/27/11 17:05, Luiz Capitulino wrote:
+Synchronous snapshot of block device, using snapshot file as target
+if provided.
It's not optional in HMP:
(qemu) snapshot_blkdev ide0-hd0
Parameter 'snapshot_file' is missing
(qemu)
The parameter is optional in HMP, however it will fail
On 04/27/11 17:05, Luiz Capitulino wrote:
+If a new image file is specified, the new image file will become the
+new root image. If format is specified, the snapshot file will be
+created in that format. Otherwise the snapshot will be internal!
+(currently unsupported).
Sorry for the
Am 28.04.2011 15:21, schrieb Jes Sorensen:
On 04/27/11 17:05, Luiz Capitulino wrote:
+If a new image file is specified, the new image file will become the
+new root image. If format is specified, the snapshot file will be
+created in that format. Otherwise the snapshot will be internal!
On 04/28/11 15:41, Kevin Wolf wrote:
Finally, what's the expect behavior when -snapshot is used? I'm getting
this:
(qemu) snapshot_blkdev ide0-hd0 snap-test
Could not open '/tmp/vl.6w8YXA'
(qemu)
What type of file system is your /tmp? You need to provide full path to
the
On Thu, 28 Apr 2011 15:21:41 +0200
Jes Sorensen jes.soren...@redhat.com wrote:
On 04/27/11 17:05, Luiz Capitulino wrote:
+If a new image file is specified, the new image file will become the
+new root image. If format is specified, the snapshot file will be
+created in that format.
On 04/28/11 16:21, Luiz Capitulino wrote:
On Thu, 28 Apr 2011 15:21:41 +0200
Jes Sorensen jes.soren...@redhat.com wrote:
On 04/27/11 17:05, Luiz Capitulino wrote:
All arguments should be mandatory in QMP, IMO.
Sorry, but there is absolutely no reason to make all arguments
mandatory. Sure
On 04/27/2011 10:05 AM, Luiz Capitulino wrote:
On Mon, 18 Apr 2011 16:27:01 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensenjes.soren...@redhat.com
This is quivalent to snapshot_blkdev in the human monitor, with _sync
added to the command name to make it explicit that the command is
On 04/28/2011 09:21 AM, Luiz Capitulino wrote:
On Thu, 28 Apr 2011 15:21:41 +0200
Jes Sorensenjes.soren...@redhat.com wrote:
On 04/27/11 17:05, Luiz Capitulino wrote:
+If a new image file is specified, the new image file will become the
+new root image. If format is specified, the snapshot
On 04/28/11 16:36, Anthony Liguori wrote:
On 04/27/2011 10:05 AM, Luiz Capitulino wrote:
On Mon, 18 Apr 2011 16:27:01 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensenjes.soren...@redhat.com
This is quivalent to snapshot_blkdev in the human monitor, with _sync
added to the command
Am 28.04.2011 15:46, schrieb Jes Sorensen:
On 04/28/11 15:41, Kevin Wolf wrote:
Finally, what's the expect behavior when -snapshot is used? I'm getting
this:
(qemu) snapshot_blkdev ide0-hd0 snap-test
Could not open '/tmp/vl.6w8YXA'
(qemu)
What type of file system is your /tmp? You need
On 04/28/11 16:42, Kevin Wolf wrote:
What type of file system is your /tmp? You need to provide full path to
the snapshot file if you don't want it created next to where your
qemu
binary is being executed.
I think the problem is that this is a temporary file, i.e. unlinked
directly
On 04/28/2011 09:38 AM, Jes Sorensen wrote:
Sorry but this is utterly bogus.
The snapshot support as is works fine, and the command is in the
monitor. We should expose it in QMP as well.
It went in for the monitor because it was considered an imperfect
command so we held up the QMP side
On 04/28/11 16:46, Anthony Liguori wrote:
On 04/28/2011 09:38 AM, Jes Sorensen wrote:
Sorry but this is utterly bogus.
The snapshot support as is works fine, and the command is in the
monitor. We should expose it in QMP as well.
It went in for the monitor because it was considered an
On 04/28/2011 09:57 AM, Jes Sorensen wrote:
On 04/28/11 16:46, Anthony Liguori wrote:
On 04/28/2011 09:38 AM, Jes Sorensen wrote:
Sorry but this is utterly bogus.
The snapshot support as is works fine, and the command is in the
monitor. We should expose it in QMP as well.
It went in for
On Mon, 18 Apr 2011 16:27:01 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
This is quivalent to snapshot_blkdev in the human monitor, with _sync
added to the command name to make it explicit that the command is
synchronous and leave space for a future async
On 04/27/11 17:05, Luiz Capitulino wrote:
On Mon, 18 Apr 2011 16:27:01 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
This is quivalent to snapshot_blkdev in the human monitor, with _sync
added to the command name to make it explicit that the command is
From: Jes Sorensen jes.soren...@redhat.com
This is quivalent to snapshot_blkdev in the human monitor, with _sync
added to the command name to make it explicit that the command is
synchronous and leave space for a future async version.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
21 matches
Mail list logo
