Hi,
For those who are interested, I have posted the notes from the 2011
Linux Plumbers Virtualization micro conference here:
http://wiki.linuxplumbersconf.org/2011:virtualization
Slides can be found by clicking on the presentation and going onto the
Plumbers abstracts.
Cheers,
Jes
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/25/11 12:06, Stefan Hajnoczi wrote:
+#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type
+#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type
Does this mean we need to duplicate the type name for each allocation?
struct foo *f;
...
f = qemu_malloc(sizeof(*f));
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
oslib-posix.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/oslib-posix.c b/oslib-posix.c
index 3a18e86..196099c 100644
--- a/oslib-posix.c
+++ b/oslib-posix.c
On 07/25/11 17:15, Anthony Liguori wrote:
On 07/25/2011 10:10 AM, Jes Sorensen wrote:
On 07/25/11 12:06, Stefan Hajnoczi wrote:
+#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type
+#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type
Does this mean we need to duplicate
On 07/25/11 17:20, Avi Kivity wrote:
On 07/25/2011 06:17 PM, Jes Sorensen wrote:
Using the commands consistently does have an impact, and at least with
qemu_malloc() it is obvious what they are and how they behave. The
proposed macros on the other hand requires everybody to go look up
On 07/25/11 17:24, Avi Kivity wrote:
On 07/25/2011 06:21 PM, Jes Sorensen wrote:
On 07/25/11 17:20, Avi Kivity wrote:
On 07/25/2011 06:17 PM, Jes Sorensen wrote:
Using the commands consistently does have an impact, and at least
with
qemu_malloc() it is obvious what they are and how
On 07/23/11 18:10, Anthony Liguori wrote:
qga/guest-agent-commands.c: In function ‘qmp_guest_fsfreeze_freeze’:
qga/guest-agent-commands.c:443: error: ‘FIFREEZE’ undeclared (first
use in this function)
qga/guest-agent-commands.c:443: error: (Each undeclared identifier is
reported only once
On 07/19/11 18:46, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
For fd-passing perhaps we have an opportunity to use a callback
mechanism (QEMU request: filename - libvirt response: fd) and do all
the image format parsing in QEMU.
The reason why
On 07/19/11 18:14, Anthony Liguori wrote:
As nice as that sentiment is, it will never fly, because it would be a
regression in current behavior. The whole reason that the virt_use_nfs
SELinux bool exists is that some people are willing to make the partial
security tradeoff. Besides, the use
On 07/19/11 18:47, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote:
On 07/19/11 16:24, Eric Blake wrote:
Besides, I feel that having a well-documented file format, so that
independent applications can both parse the same file with the same
semantics
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the problem. In a sane world we would simply
say 'no NFS, no selinux', but as you say that will never happen.
My suggestion of a callback mechanism where
On 07/18/11 16:08, Stefan Hajnoczi wrote:
On Fri, Jul 15, 2011 at 3:58 PM, Jes Sorensen jes.soren...@redhat.com wrote:
I have been updating the live snapshot wiki for qemu to try and cover
the commands we will want for async snapshot handling too.
http://wiki.qemu.org/Features/Snapshots
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qemu-img-cmds.hx |4 ++--
qemu-img.texi|6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index 2b70618..1299e83 100644
On 07/19/11 15:23, Stefan Hajnoczi wrote:
On Tue, Jul 19, 2011 at 8:24 AM, Jes Sorensen jes.soren...@redhat.com wrote:
On 07/18/11 16:08, Stefan Hajnoczi wrote:
On Fri, Jul 15, 2011 at 3:58 PM, Jes Sorensen jes.soren...@redhat.com
wrote:
I have been updating the live snapshot wiki for qemu
On 07/19/11 15:58, Eric Blake wrote:
On 07/19/2011 07:27 AM, Jes Sorensen wrote:
Eric, what happens if libvirt in an selinux environment tells QEMU to
launch using an image file that is backed by backing file(s)?
Before starting qemu, libvirt first parses all the image files, to see
if any
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
Urgh, libvirt parsing image files is really unfortunate, it really
doesn't give me warm fuzzy feelings :( libvirt really should not know
about internals of image formats.
But even
Hi,
I have been updating the live snapshot wiki for qemu to try and cover
the commands we will want for async snapshot handling too.
http://wiki.qemu.org/Features/Snapshots
Cheers,
Jes
On 07/11/11 22:35, Luiz Capitulino wrote:
Sorry that is no go, you just broke the hmp implementation - you cannot
change the hmp behavior like that.
HMP uses positional arguments, so changing argument names makes no
difference. And, apart from some exceptions, it's not an stable interface,
On 07/09/11 00:24, Ahmed M. Azab wrote:
Hi All,
Is there a way to take a live memory snapshot of a running VM without
freezing or stopping this VM?
I explored the Qemu code and documentation and I found two ways to
take a snapshot:
What you are talking about is called a 'checkpoint', not
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off
On 07/11/11 18:35, Luiz Capitulino wrote:
On Fri, 8 Jul 2011 14:00:13 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous
On 07/11/11 22:24, Luiz Capitulino wrote:
On Mon, 11 Jul 2011 20:01:09 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous
From: Jes Sorensen jes.soren...@redhat.com
Hi,
I discussed the issue of a QMP command for live snapshot with Anthony,
and we have agreed that it is fine to have a QMP command that matches
the current human monitor command. This doesn't preclude that in the
future someone may want to add support
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off
On 07/07/11 09:30, Avi Kivity wrote:
On 07/07/2011 10:14 AM, Gerd Hoffmann wrote:
Can't we just implicitly fail migration whenever there's a device in
the tree that doesn't have VMSTATE?
There are cases where the device doesn't need to save state, so that
alone doesn't cut it.
It should
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
hw/usb-bus.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 2abce12..6e082ab 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -145,8
On 06/14/11 03:22, Andreas Färber wrote:
In 821601ea5b02a68ada479731a4d3d07a9876632a (Make VNC support optional)
cocoa.o was moved from ui-obj-$(CONFIG_COCOA) to vnc-obj-$(CONFIG_COCOA),
adding a dependency on $(CONFIG_VNC). That must've been unintentional.
Cc: Jes Sorensen jes.soren
On 05/24/11 06:31, Marcelo Tosatti wrote:
To query whether migration is active.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
ACK
Jes
On 05/20/11 14:19, Stefan Hajnoczi wrote:
I'm interested in what the API for snapshots would look like.
I presume you're talking external snapshots here? The API is really what
should be defined by libvirt, so you get a unified API that can work
both on QEMU level snapshots as well as enterprise
On 05/20/11 14:49, Stefan Hajnoczi wrote:
On Fri, May 20, 2011 at 1:39 PM, Jes Sorensen jes.soren...@redhat.com wrote:
On 05/20/11 14:19, Stefan Hajnoczi wrote:
I'm interested in what the API for snapshots would look like.
I presume you're talking external snapshots here? The API is really
On 05/09/11 15:40, Dor Laor wrote:
Summary:
* We need Marcelo's new (to come) block copy implementation
* should work in parallel to migration and hotplug
* General copy on read is desirable
* Live snapshot merge to be implemented using block copy
* Need to utilize a remote block
On 05/09/11 17:23, Anthony Liguori wrote:
* Live snapshots and live snapshot merge
Live snapshot is already incorporated (by Jes) in qemu (still need
qemu-agent work to freeze the guest FS).
Live snapshot is unfortunately not really live. It runs a lot of
operations synchronously which
On 05/09/11 13:50, Juan Quintela wrote:
Please send in any agenda items you are interested in covering.
From last week, we have already:
- import kvm headers into qemu, drop #ifdef maze (Jan)
Thanks, Juan.
Since we haven't received any further agenda items. In addition Anthony
is
On 05/06/11 17:10, Markus Armbruster wrote:
Jes Sorensen jes.soren...@redhat.com writes:
What you add is a delta, which is relative to the max. We can change the
argument name of the function to be delta instead if that makes it
easier to follow.
Here's my try:
/*
* Report progress
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qemu-common.h |2 +-
qemu-progress.c | 24 +---
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/qemu-common.h b/qemu-common.h
index f9f705d..78b7a4a
From: Jes Sorensen jes.soren...@redhat.com
Hi,
Two small patches cleaning up the progress printing code - adding
documentation and removing some unneeded paranthesis. Also know as the
'happy markus' patch series
This is relative to the block branch.
Jes
Jes Sorensen (2):
Add
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qemu-progress.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu-progress.c b/qemu-progress.c
index a4894c0..70928d6 100644
--- a/qemu-progress.c
+++ b/qemu
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qemu-img.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index e825123..1da5484 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -785,7 +785,7
On 05/06/11 12:40, Brad Hards wrote:
On Fri, 6 May 2011 07:39:10 PM jes.soren...@redhat.com wrote:
+/*
+ * Add delta to current state, and print the output if the current
+ * state has progressed more than min_skip since the last value was
+ * printed. 'max' specifies the relative percentage,
. Please apply. Thanks,
A memory size can obviously not be bigger than the maximum physical
address, so I find it really hard to see how this could overflow.
It seems fair to use it for the size here.
Acked-by: Jes Sorensen jes.soren...@redhat.com
On 05/05/11 17:18, Michael S. Tsirkin wrote:
A memory size can obviously not be bigger than the maximum physical
address, so I find it really hard to see how this could overflow.
For example, a 4G size does not fit in 32 bits.
That is the only corner case - you can handle that by -1 if you
On 05/05/11 17:38, Michael S. Tsirkin wrote:
On Thu, May 05, 2011 at 05:36:04PM +0200, Jes Sorensen wrote:
On 05/05/11 17:18, Michael S. Tsirkin wrote:
A memory size can obviously not be bigger than the maximum physical
address, so I find it really hard to see how this could overflow
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
On 04/21/11 15:55, Michael Roth wrote:
Did you do anything with the fsfreeze patches, or were they dropped in
the migration to qapi?
They were pending some changes required on the agent side that weren't
really addressed/doable until this patchset, namely:
1) server-side timeout mechanism
On 05/03/11 15:04, Jan Kiszka wrote:
On 2011-05-03 12:21, Juan Quintela wrote:
Please send in any agenda items you are interested in covering.
Provided there will be more topics:
- import kvm headers into qemu, drop #ifdef maze
Otherwise, we can also discuss this based on the patch I'm
On 05/03/11 15:53, Michael Roth wrote:
IMHO it is better to disable the commands rather than just logging, but
either way should allow it to drop in.
Kinda agree, but logging seems to be the real dependency. With the
server-side timeouts now in place even doing stuff like fopen/fwrite is
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
On 04/27/11 18:14, Markus Armbruster wrote:
+static void progress_simple_init(void)
+{
+state.print = progress_simple_print;
+state.end = progress_simple_end;
+}
+
+#ifdef CONFIG_POSIX
+static void sigusr_print(int signal)
+{
+printf((%3.2f/100%%)\n, state.current);
From: Jes Sorensen jes.soren...@redhat.com
Change the signal handling to indicate a signal is pending, rather
then printing directly from the signal handler.
In addition make the signal prints go to stderr, rather than stdout.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qemu
From: Jes Sorensen jes.soren...@redhat.com
Change the signal handling to indicate a signal is pending, rather
then printing directly from the signal handler.
In addition make the signal prints go to stderr, rather than stdout.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qemu
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
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
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
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous. In
the future async commands may be added with the name _async/-async.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
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/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
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/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
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-progress.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/qemu-progress.c b/qemu-progress.c
index b4b751c..e1feb89
From: Jes Sorensen jes.soren...@redhat.com
This introduces support for dd-style progress reporting on POSIX
systems, if the user hasn't specified -p to report progress. If sent a
SIGUSR1, qemu-img will report current progress for commands that
support progress reporting.
Signed-off-by: Jes
From: Jes Sorensen jes.soren...@redhat.com
This introduces support for dd-style progress reporting, if the user
hasn't specified -p to report progress. If sent a SIGUSR1, qemu-img
will report current progress for commands that support progress
reporting.
v2 fixes the mingw32 build problems
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
On 04/21/11 22:58, Michael Roth wrote:
On 04/21/2011 09:10 AM, Jes Sorensen wrote:
On 04/18/11 17:02, Michael Roth wrote:
One thing I cannot seem to figure out with this tree - the agent
commands do not seem to show up in the monitor? What am I missing?
Hmm, for some reason this email never
On 04/26/11 11:24, Juan Quintela wrote:
Please, send in any agenda items you are interested in covering.
From last week:
Tools for resource accounting the virtual machines.
Luis Antonio Galindo Castro (FunkyM0nk3y) funkymons...@gmail.com
- Status of glib tree - next steps?
Jes
On 04/25/11 14:27, Ian Molton wrote:
On Fri, 2011-04-22 at 13:51 +0200, Jes Sorensen wrote:
Hiding things you miss when reading the code, it's a classic for
people to do if(foo) bleh(); on the same line, and whoever reads
the code will expect the action on the next line, especially if foo
On 04/26/11 15:09, Anthony Liguori wrote:
On 04/26/2011 06:47 AM, Jes Sorensen wrote:
On 04/26/11 11:24, Juan Quintela wrote:
Please, send in any agenda items you are interested in covering.
From last week:
Tools for resource accounting the virtual machines.
Luis Antonio Galindo
On 04/26/11 16:27, Michael Roth wrote:
On 04/26/2011 01:57 AM, Jes Sorensen wrote:
Yeah it was the conclusion I came to on Thursday when I was working on
porting the freeze patches over. After fighting the json %#$%#$%#$ I
ended up with something I couldn't test in the end :(
I actually
From: Jes Sorensen jes.soren...@redhat.com
This patch adds the following QMP commands:
qga-guest-fsfreeze:
- Freezes all local file systems in the guest. Command will return
the number of file systems that were frozen.
qga-guest-fsthaw:
- Thaws all local file systems in the guest. Command
On 04/22/11 11:23, Ian Molton wrote:
On Thu, 2011-04-21 at 08:21 -0500, Michael Roth wrote:
+switch (level G_LOG_LEVEL_MASK) {
+case G_LOG_LEVEL_ERROR: return error;
+case G_LOG_LEVEL_CRITICAL: return critical;
+case G_LOG_LEVEL_WARNING: return warning;
+
);
if (err) {
This one really should go into the tree asap, even if the rest of the
virt agent patches are still pending.
Reviewed-by: Jes Sorensen jes.soren...@redhat.com
On 04/18/11 17:02, Michael Roth wrote:
diff --git a/qmp-core.c b/qmp-core.c
index 9f3d182..dab50a1 100644
--- a/qmp-core.c
+++ b/qmp-core.c
@@ -937,7 +937,15 @@ void qmp_async_complete_command(QmpCommandState *cmd,
QObject *retval, Error *er
qemu_free(cmd);
}
+extern QmpProxy
On 04/18/11 17:02, Michael Roth wrote:
diff --git a/qga/guest-agent-worker.c b/qga/guest-agent-worker.c
new file mode 100644
index 000..e3295da
--- /dev/null
+++ b/qga/guest-agent-worker.c
@@ -0,0 +1,173 @@
+/*
+ * QEMU Guest Agent worker thread interfaces
+ *
+ * Copyright IBM Corp.
On 04/18/11 17:02, Michael Roth wrote:
+static const char *ga_log_level_str(GLogLevelFlags level)
+{
+switch (level G_LOG_LEVEL_MASK) {
+case G_LOG_LEVEL_ERROR: return error;
+case G_LOG_LEVEL_CRITICAL: return critical;
+case G_LOG_LEVEL_WARNING: return
On 04/18/11 17:02, Michael Roth wrote:
These apply on top of Anthony's glib tree, commit
03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained
from:
git://repo.or.cz/qemu/mdroth.git qga_v2
Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index a7c1503..bebe3bd 100644
--- a/Makefile
+++ b/Makefile
@@ -301,6 +301,7 @@ distclean
On 04/21/11 15:15, Michael Roth wrote:
On 04/21/2011 03:44 AM, Jes Sorensen wrote:
and again I'll stop. Basically there really should be no references
to pthread_*
This is on the guest side of things where I'm trying to use GLib
wherever possible to keep things somewhat portable
On 04/18/11 17:02, Michael Roth wrote:
These apply on top of Anthony's glib tree, commit
03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained
from:
git://repo.or.cz/qemu/mdroth.git qga_v2
Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider
| 20
1 files changed, 16 insertions(+), 4 deletions(-)
Looks good to me.
Acked-by: Jes Sorensen jes.soren...@redhat.com
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
---
qmp
From: Jes Sorensen jes.soren...@redhat.com
This is an old patch I am resurrecting, adding a QMP command for live
snapshot support. I have tried to address the comments received in the
previous emails around March 9th. Please let me know if you have
further issues with this.
Jes Sorensen (1
Hi,
With the success of last year's Virtualization micro-conference track
at Linux Plumbers 2010, I have accepted to organize a similar track
for Linux Plumbers 2011 in Santa Rosa. Please see the official Linux
Plumbers 2011 website for full details about the conference:
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qemu-progress.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/qemu-progress.c b/qemu-progress.c
index 6498161..f3ce974 100644
--- a/qemu-progress.c
+++ b/qemu
From: Jes Sorensen jes.soren...@redhat.com
This introduces support for dd-style progress reporting, if the user
hasn't specified -p to report progress. If sent a SIGUSR1, qemu-img
will report current progress for commands that support progress
reporting.
Signed-off-by: Jes Sorensen jes.soren
On 04/08/11 22:45, Blue Swirl wrote:
Move generic or OS related function declarations and macro
TFR to qemu-common.h.
While moving, also add #include winsock2.h to fix a
recent mingw32 build breakage.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
qemu-common.h | 21
On 04/04/11 19:26, Peter Maydell wrote:
On 4 April 2011 15:53, Jes Sorensen jes.soren...@redhat.com wrote:
I understand that what you are proposing seems to work well enough for
your problem at hand. What I am saying is that adding a mechanism like
that, can cause problems for adding a more
On 04/04/11 18:54, Blue Swirl wrote:
On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen jes.soren...@redhat.com wrote:
I understand that what you are proposing seems to work well enough for
your problem at hand. What I am saying is that adding a mechanism like
that, can cause problems for adding
On 04/12/11 16:09, Amit Shah wrote:
diff --git a/hw/ide/core.c b/hw/ide/core.c
index dafc049..209d8e6 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1084,6 +1084,49 @@ static int ide_dvd_read_structure(IDEState *s, int
format,
}
}
+static unsigned int
On 04/12/11 17:13, Kevin Wolf wrote:
Am 12.04.2011 17:03, schrieb Jes Sorensen:
Shouldn't you verify that you don't exceed max_len in this?
Not necessary (the buffer is always 2048 bytes), but it looks like the
max_len parameter is unused now, so it could be removed.
Kevin
That works
handling (tray open / close / new media)
overall for the block layer, but this is a good first step in being
spec-compliant and at the same time making guests work.
v5 looks good.
Acked-by: Jes Sorensen jes.soren...@redhat.com
Jes
On 03/30/11 16:07, Peter Maydell wrote:
On 30 March 2011 14:56, Anthony Liguori anth...@codemonkey.ws wrote:
On 03/30/2011 08:22 AM, Peter Maydell wrote:
Not really, typically they're just filled up in some particular
order (main RAM in one place and expansion RAM elsewhere).
Since the board
On 04/04/11 16:42, Peter Maydell wrote:
On 4 April 2011 15:29, Jes Sorensen jes.soren...@redhat.com wrote:
Yes, I agree, so we shouldn't try to specify some complicated
set of static data that still won't be good enough.
I'm trying to make it easy for boards to avoid crashing horribly
when
through this, and it looks perfectly reasonable to me.
Reviewed-by: Jes Sorensen jes.soren...@redhat.com
On 03/25/11 20:47, Michael Roth wrote:
This is the actual guest daemon, it listens for requests over a
virtio-serial/isa-serial/unix socket channel and routes them through
to dispatch routines, and writes the results back to the channel in
a manner similar to Qmp.
This is currently horribly
On 03/31/11 13:49, Stefan Hajnoczi wrote:
On Thu, Mar 31, 2011 at 12:38 PM, Kevin Wolf kw...@redhat.com wrote:
Am 31.03.2011 13:15, schrieb Jes Sorensen:
On 03/31/11 12:38, Kevin Wolf wrote:
I have been a little reluctant to do this because it will break the ABI
for tools running qemu-img
On 03/31/11 12:38, Kevin Wolf wrote:
Am 30.03.2011 14:16, schrieb jes.soren...@redhat.com:
From: Jes Sorensen jes.soren...@redhat.com
This adds the basic infrastructure for supporting progress output
on the command line, as well as progress support for qemu-img commands
'rebase' and 'convert
On 03/29/11 12:55, Bin (Bin) Shi wrote:
Can QEMU run on QNX ?
My machine is
Cpu - arm11
Os - qnx6.5
Does QEMU support my machine ?
Hi,
Do you mean if QEMU can emulate ARM11 and boot QNX that way, or do you
want to run QEMU on a QNX box?
I don't think QEMU has been ported to QNX,
On 03/29/11 16:08, Peter Maydell wrote:
This primary aim of this patchset is to add a new 'max_ram' field to the
QEMUMachine structure so that a board model can specify the maximum RAM it
will accept. We can then produce a friendly diagnostic message when the
user tries to start qemu with a
1 - 100 of 894 matches
Mail list logo
