Luiz Capitulino wrote:
On Thu, 22 Oct 2009 10:40:54 -0500
Anthony Liguori wrote:
Luiz Capitulino wrote:
Yeah, I agree.
When testing migration, for example, I have to type 'migrate -d tcp:0:'
several times... Maybe there's a smarter way to do this, but the monitor
macros idea se
On Thu, 22 Oct 2009 10:40:54 -0500
Anthony Liguori wrote:
> Luiz Capitulino wrote:
> > Yeah, I agree.
> >
> > When testing migration, for example, I have to type 'migrate -d tcp:0:'
> > several times... Maybe there's a smarter way to do this, but the monitor
> > macros idea seems interestin
On Thu, 22 Oct 2009 17:02:29 +0200
Kevin Wolf wrote:
> Am 22.10.2009 16:40, schrieb Luiz Capitulino:
> > On Wed, 21 Oct 2009 19:35:03 +0100
> > Jamie Lokier wrote:
> >> If the monitor accepted ";" as a command separator, to put multiple
> >> commands on a single line, could just be a quoted
> >
Luiz Capitulino wrote:
Yeah, I agree.
When testing migration, for example, I have to type 'migrate -d tcp:0:'
several times... Maybe there's a smarter way to do this, but the monitor
macros idea seems interesting to me.
When we have QMP, we can create a QMP socket at a well known loca
Am 22.10.2009 16:40, schrieb Luiz Capitulino:
> On Wed, 21 Oct 2009 19:35:03 +0100
> Jamie Lokier wrote:
>> If the monitor accepted ";" as a command separator, to put multiple
>> commands on a single line, could just be a quoted
>> string which is processed as a line.
>
> Why is ";" needed?
Ho
On Wed, 21 Oct 2009 19:35:03 +0100
Jamie Lokier wrote:
> Mulyadi Santosa wrote:
> > On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa wrote:
> > > You can provide a monitor command to do that
> > >
> > > something in the lines of:
> > > - add_macro
> > > - remove_macro
> > > - list_macros
> >
Am 21.10.2009 20:08, schrieb Anthony Liguori:
> Glauber Costa wrote:
>> On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori
>> wrote:
>>
>>> Glauber Costa wrote:
>>>
Why don't we provide a mechanism to make a macro out of a sequence of
monitor commands, and let the user assign what
Mulyadi Santosa wrote:
> On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa wrote:
> > You can provide a monitor command to do that
> >
> > something in the lines of:
> > - add_macro
> > - remove_macro
> > - list_macros
>
> Please CMIIW, "command_list" here refers to at least one of monitor
> com
Glauber Costa wrote:
On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori wrote:
Glauber Costa wrote:
Why don't we provide a mechanism to make a macro out of a sequence of
monitor commands, and let the user assign whatever he wants out of that?
Really? This seems exceedingly comp
On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori wrote:
> Glauber Costa wrote:
>>
>> Why don't we provide a mechanism to make a macro out of a sequence of
>> monitor commands, and let the user assign whatever he wants out of that?
>>
>
> Really? This seems exceedingly complicated to me.
>
> Redir
On Wed, Oct 21, 2009 at 11:55 PM, Anthony Liguori wrote:
> Really? This seems exceedingly complicated to me.
>
> Redirecting the kernel output to serial and logging is a considerably better
> solution.
I'll respectfully consider everybody's thought hereinteresting
discussion so far though. m
Glauber Costa wrote:
Why don't we provide a mechanism to make a macro out of a sequence of
monitor commands, and let the user assign whatever he wants out of that?
Really? This seems exceedingly complicated to me.
Redirecting the kernel output to serial and logging is a considerably
bette
On Wed, Oct 21, 2009 at 2:44 PM, Mulyadi Santosa
wrote:
> On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa wrote:
>> You can provide a monitor command to do that
>>
>> something in the lines of:
>> - add_macro
>> - remove_macro
>> - list_macros
>
> Please CMIIW, "command_list" here refers to at
On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa wrote:
> You can provide a monitor command to do that
>
> something in the lines of:
> - add_macro
> - remove_macro
> - list_macros
Please CMIIW, "command_list" here refers to at least one of monitor
commands, right? meaning, i.e one could do:
ad
On Wed, Oct 21, 2009 at 2:04 PM, Mulyadi Santosa
wrote:
> On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa wrote:
>> Why don't we provide a mechanism to make a macro out of a sequence of
>> monitor commands, and let the user assign whatever he wants out of that?
>
> Presto! never thought about that
On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa wrote:
> Why don't we provide a mechanism to make a macro out of a sequence of
> monitor commands, and let the user assign whatever he wants out of that?
Presto! never thought about thatwhat are we supposed to do in
order to provide such mechanis
On Wed, Oct 21, 2009 at 5:27 AM, Kevin Wolf wrote:
> Am 20.10.2009 19:08, schrieb Daniel P. Berrange:
>> On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote:
>>> Am 20.10.2009 00:20, schrieb Anthony Liguori:
Mulyadi Santosa wrote:
> IMO, it would be faster if we provide keyboard sh
Am 20.10.2009 19:08, schrieb Daniel P. Berrange:
> On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote:
>> Am 20.10.2009 00:20, schrieb Anthony Liguori:
>>> Mulyadi Santosa wrote:
IMO, it would be faster if we provide keyboard shortcuts that will
stop and resume VM execution right
Hi...
On Wed, Oct 21, 2009 at 12:08 AM, Daniel P. Berrange
wrote:
> The problem with adding lots of magic key-sequences, is that the more
> you add, the more likely they are to clash with something that the
> guest OS wants to use. You may make this use case work, but break
> someone else's use c
On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote:
> Am 20.10.2009 00:20, schrieb Anthony Liguori:
> > Mulyadi Santosa wrote:
> >> IMO, it would be faster if we provide keyboard shortcuts that will
> >> stop and resume VM execution right from SDL guest interface, rather
> >> than switching
Kevin Wolf wrote:
Am 20.10.2009 00:20, schrieb Anthony Liguori:
Mulyadi Santosa wrote:
IMO, it would be faster if we provide keyboard shortcuts that will
stop and resume VM execution right from SDL guest interface, rather
than switching to console monitor first and type "s" or "c"
respe
Am 20.10.2009 00:20, schrieb Anthony Liguori:
> Mulyadi Santosa wrote:
>> IMO, it would be faster if we provide keyboard shortcuts that will
>> stop and resume VM execution right from SDL guest interface, rather
>> than switching to console monitor first and type "s" or "c"
>> respectively.
>>
>
On Tue, Oct 20, 2009 at 10:16:09AM +0700, Mulyadi Santosa wrote:
> Hi Anthony...
>
> On Tue, Oct 20, 2009 at 5:20 AM, Anthony Liguori
> wrote:
> > Mulyadi Santosa wrote:
> >>
> >> IMO, it would be faster if we provide keyboard shortcuts that will
> >> stop and resume VM execution right from SDL
On 10/20/09 05:16, Mulyadi Santosa wrote:
As these message scrolls fast, I find it more intuitive if we could
just press a key to pause the guest, giving us enough time to capture
the display and resume the execution. If we switch to qemu monitor
first, most of the time we already lost the moment
Hi Anthony...
On Tue, Oct 20, 2009 at 5:20 AM, Anthony Liguori wrote:
> Mulyadi Santosa wrote:
>>
>> IMO, it would be faster if we provide keyboard shortcuts that will
>> stop and resume VM execution right from SDL guest interface, rather
>> than switching to console monitor first and type "s" or
Mulyadi Santosa wrote:
IMO, it would be faster if we provide keyboard shortcuts that will
stop and resume VM execution right from SDL guest interface, rather
than switching to console monitor first and type "s" or "c"
respectively.
Is this really common of an operation that you would need an
IMO, it would be faster if we provide keyboard shortcuts that will
stop and resume VM execution right from SDL guest interface, rather
than switching to console monitor first and type "s" or "c"
respectively.
Note: I simply skip checking the keys in encrypted block devices when
resuming the VM. No
27 matches
Mail list logo
