gwj / at91sam9263 · Commits

  • Allow monitor interaction when using migrate -exec ...
    8a43b1ea 
    All,
     I've recently been playing around with migration via exec.  Unfortunately,
when starting the incoming qemu process with "-incoming exec:cmd", it suffers
the same problem that -incoming tcp used to suffer; namely, that you can't
interact with the monitor until after the migration has happened.  This causes
problems for libvirt usage of -incoming exec, since libvirt expects to be able
to access the monitor ahead of time.  This fairly simple patch allows you to
access the monitor both before and after the migration has completed using exec.

(note: developed/tested with qemu-kvm, but applies perfectly fine to qemu)

Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    Chris Lalancette authored
     
    Browse File »
  • monitor: Rework API (Jan Kiszka) ...
    376253ec 
    Refactor the monitor API and prepare it for decoupled terminals:
term_print functions are renamed to monitor_* and all monitor services
gain a new parameter (mon) that will once refer to the monitor instance
the output is supposed to appear on. However, the argument remains
unused for now. All monitor command callbacks are also extended by a mon
parameter so that command handlers are able to pass an appropriate
reference to monitor output services.

For the case that monitor outputs so far happen without clearly
identifiable context, the global variable cur_mon is introduced that
shall once provide a pointer either to the current active monitor (while
processing commands) or to the default one. On the mid or long term,
those use case will be obsoleted so that this variable can be removed
again.

Due to the broad usage of the monitor interface, this patch mostly deals
with converting users of the monitor API. A few of them are already
extended to pass 'mon' from the command handler further down to internal
functions that invoke monitor_printf.

At this chance, monitor-related prototypes are moved from console.h to
a new monitor.h. The same is done for the readline API.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6711 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »
  • Fix handling of disk-only snapshots (Kevin Wolf) ...
    2d22b18f 
    When creating a snapshot with multiple qcow2 disks attached, the current
behaviour is that qemu creates a disk snapshot on all of them and
chooses one to write the VM state to.

Despite having the state only in one image, loadvm tries to restore the
VM state from the middle of nowhere if you run qemu a second time with
only one of the other images attached. In the lucky case it will fail
because there simply is no state, but it also can happen that it loads
the state of a different snapshot (the one this new one is based upon).

The fix is to write a zero VM state size to the images which don't
contain the state, and check this in loadvm.

I agree that you probably have to provoke such things intentionally to
get in a state like this with qemu itself. However, with my second patch
that adds snapshot support to qemu-img it could become a reasonable use
case to have snapshots with and without VM states on the same image.

Signed-off-by: Kevin Wolf <kwolf@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>



git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5985 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »