Anthony Liguori wrote:
Hollis Blanchard wrote:
On Wed, 2009-04-08 at 13:34 -0500, Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In
order to support
asynchronous notification of events, I would like to introduce a
'wait' command
that waits for an event
On Wed, 2009-04-08 at 13:34 -0500, Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In order to
support
asynchronous notification of events, I would like to introduce a 'wait'
command
that waits for an event to occur. This implies that we need an
Hollis Blanchard wrote:
On Wed, 2009-04-08 at 13:34 -0500, Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In order to support
asynchronous notification of events, I would like to introduce a 'wait' command
that waits for an event to occur. This implies
Jamie Lokier wrote:
Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allow end users to access the monitor of a VM
libvirt is
Hi,
Personally, I think relying on asynchronous events to provide reliable
status is a bad idea. Management connections can and will get
disconnected, buffers will get filled and event notifications will be
dropped.
I somehow like the idea from someone (Jamie?) somewhere in this thread
to
On Sun, Apr 12, 2009 at 07:42:17PM +0100, Jamie Lokier wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
At the end of the day, I want to be able to run a QEMU instance from
the command line, and have virt-manager be able to see it remotely and
connect to it. That means multiple monitors
On Tue, Apr 14, 2009 at 12:15:23PM +0300, Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allow end users to access the monitor of a
Jan Kiszka wrote:
That is true, but we'd still be considering direct monitor access to
be a 'expert' user mode of use. If they wish to shoot themselves in
the foot by triggering a migration at same time they are hotplugging
I'm fine if their whole leg gets blown away.
...while there is
Daniel P. Berrange wrote:
On Tue, Apr 14, 2009 at 12:15:23PM +0300, Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allow end users
Daniel P. Berrange wrote:
On Tue, Apr 14, 2009 at 12:15:23PM +0300, Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allow end
Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allow end users to access the monitor of a VM
libvirt is managing. We just need to
Gerd Hoffmann wrote:
Management apps don't need new parsers, the existing info foo
parser(s) will do just fine.
And QEMU doesn't need new printers. Less code to go wrong :-)
-- Jamie
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Avi Kivity wrote:
If you want things to work reliably, you have to follow the chain of
command.
Or use locks and/or transactions like everything else :-)
-- Jamie
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Zachary Amsden wrote:
| 24H 100M 82V
You pierce the beastly fido's heart, you heartbreaker you...
The beastly fido is dead!
You receive 8 experience points.
Your blood freezes as you hear the beastly fido's death cry.
| 24H 100M 82V
The green gelatinous blob has arrived.
The janitor
Avi Kivity wrote:
Anthony Liguori wrote:
At the end of the day, I want to be able to run a QEMU instance from
the command line, and have virt-manager be able to see it remotely and
connect to it. That means multiple monitors and it means that all
commands that change VM state must
Anthony Liguori wrote:
Avi Kivity wrote:
(qemu) notify vnc on
... time passes, we want to allow members of group x to log in
(qemu) vnc_set_acl group:x
OK
(qemu)
notification: vnc connect aliguori
(qemu)
with a single monitor, we can be sure that the connect happened the
vnc_set_acl. If
Anthony Liguori wrote:
What's the established practice? Do you know of any protocol that is
line based that does notifications like this?
Actually there is one line oriented protocol that does asynchronous
notifications.
http://faqs.org/rfcs/rfc1459.html
--
Do not meddle in the
Avi Kivity wrote:
Anthony Liguori wrote:
IMHO, multiple monitors is a critical feature to support in the long
term.
Multiple monitors are nice to have (for developers), but I don't see
them as critical.
If you live in a world where there is a single management application
that provides
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
IMHO, multiple monitors is a critical feature to support in the long
term.
Multiple monitors are nice to have (for developers), but I don't see
them as critical.
If you live in a world where there is a single management
Avi Kivity wrote:
I disagree, I think requiring multiple sessions for controlling a single
application is clumsy. I can't think of one protocol which uses it. I
don't think IMAP requires multiple sessions (and I don't think commands
from one session can affect the other, except through the
Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In order to support
asynchronous notification of events, I would like to introduce a 'wait' command
that waits for an event to occur. This implies that we need an additional
monitor session to allow commands to
Avi Kivity wrote:
Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In order
to support
asynchronous notification of events, I would like to introduce a
'wait' command
that waits for an event to occur. This implies that we need an
additional
monitor session
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In
order to support
asynchronous notification of events, I would like to introduce a
'wait' command
that waits for an event to occur. This implies that we need an
Avi Kivity wrote:
hotplug disk
-ENOSPC on disk
It's true that events don't correlate directly to commands, but they
do correlate to the state of the system and that is affected by commands.
events are time stamped. In non-human mode, I think command responses
should be time stamped too
On 04/09/09 16:03, Avi Kivity wrote:
I don't want multiplexed monitor sessions, at all.
I'm very happy to finally see them. Finally one can run vms with
libvirt and *still* access the monitor for debugging and development
purposes.
I want async
notifications added to a single monitor
Gerd Hoffmann wrote:
On 04/09/09 16:03, Avi Kivity wrote:
I don't want multiplexed monitor sessions, at all.
I'm very happy to finally see them. Finally one can run vms with
libvirt and *still* access the monitor for debugging and development
purposes.
Right, I like them for that
Anthony Liguori wrote:
Timestamping doesn't help since the command could have been delayed
in the monitor socket.
Further, we're now so deep down the complexity spiral that it has now
become the most complicated piece of code in the entire system.
You certainly cannot believe that, can
Avi Kivity wrote:
(qemu) notify enospace on
(qemu) notify vnc-connect on
(qemu)
notification: vnc connection ...
(qemu) notify migration-completion on
(qemu) migrate -d ...
notification: enospc on ide0-0
(qemu) migrate_cancel
notification: migration cancelled
(qemu) migrate -d ...
(qemu)
Anthony Liguori wrote:
Avi Kivity wrote:
(qemu) notify enospace on
(qemu) notify vnc-connect on
(qemu)
notification: vnc connection ...
(qemu) notify migration-completion on
(qemu) migrate -d ...
notification: enospc on ide0-0
(qemu) migrate_cancel
notification: migration cancelled
(qemu)
Avi Kivity wrote:
Gerd Hoffmann wrote:
On 04/09/09 16:03, Avi Kivity wrote:
I don't want multiplexed monitor sessions, at all.
I'm very happy to finally see them. Finally one can run vms with
libvirt and *still* access the monitor for debugging and development
purposes.
Right, I like
Avi Kivity wrote:
I'd make everything line-oriented. Anything from the user up to \n is
buffered and ignored until the \n arrives.
Once the \n arrives, the command is acted upon atomically, either
completing fully or launching an async notification.
So the rules are: whenever the monitor
Anthony Liguori wrote:
Avi Kivity wrote:
I'd make everything line-oriented. Anything from the user up to \n
is buffered and ignored until the \n arrives.
Once the \n arrives, the command is acted upon atomically, either
completing fully or launching an async notification.
So the rules
Jan Kiszka wrote:
Avi Kivity wrote:
Gerd Hoffmann wrote:
On 04/09/09 16:03, Avi Kivity wrote:
I don't want multiplexed monitor sessions, at all.
I'm very happy to finally see them. Finally one can run vms with
libvirt and *still* access the monitor for debugging and
Avi Kivity wrote:
I'm sorry, I don't see why. It's just like a shell session.
Compare with:
Monitor 1:
(qemu) notify enospace on
(qemu) notify vnc-connect on
(qemu) notify migration-completion on
(qemu) migrate -d ...
(qemu) migrate_cancel
(qemu) migrate -d ...
Monitor 2:
(qemu) wait
vnc
Avi Kivity wrote:
Jan Kiszka wrote:
Avi Kivity wrote:
Gerd Hoffmann wrote:
On 04/09/09 16:03, Avi Kivity wrote:
I don't want multiplexed monitor sessions, at all.
I'm very happy to finally see them. Finally one can run vms with
libvirt and *still* access the
Anthony Liguori wrote:
Avi Kivity wrote:
I'm sorry, I don't see why. It's just like a shell session.
Compare with:
Monitor 1:
(qemu) notify enospace on
(qemu) notify vnc-connect on
(qemu) notify migration-completion on
(qemu) migrate -d ...
(qemu) migrate_cancel
(qemu) migrate -d ...
Avi Kivity wrote:
I'm not sure I understand your questions. Multiple monitor sessions are
like multiple shell sessions. I don't think a control program should
use more than one session, but it should allow a developer to connect to
issue 'info registers' and 'x/20i' commands. Of course
Avi Kivity wrote:
(qemu) notify vnc on
... time passes, we want to allow members of group x to log in
(qemu) vnc_set_acl group:x
OK
(qemu)
notification: vnc connect aliguori
(qemu)
with a single monitor, we can be sure that the connect happened the
vnc_set_acl. If the notification arrives
Avi Kivity wrote:
Oh. If the command generates no output (like most), you can't tell when
it completes. I suppose we could have qemu print OK after completing a
command.
FWIW, OpenVPN's monitor interface resolves this by prefixing all
notification lines with ''.
--
Libvir-list mailing
39 matches
Mail list logo
