qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] vhost-vsock: report QMP event when setrunnin


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2] vhost-vsock: report QMP event when setrunning
Date: Thu, 19 Dec 2019 11:18:39 +0000
User-agent: Mutt/1.12.1 (2019-06-15)

On Thu, Dec 12, 2019 at 06:24:55AM -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 12, 2019 at 11:05:25AM +0000, Stefan Hajnoczi wrote:
> > On Thu, Nov 28, 2019 at 07:26:47PM +0800, address@hidden wrote:
> > > Let me describe the issue with an example via `nc-vsock`:
> > > 
> > > Let's assume the Guest cid is 3.
> > > execute 'rmmod vmw_vsock_virtio_transport' in Guest,
> > > then execute 'while true; do nc-vsock 3 1234' in Host.
> > > 
> > > Host                             Guest
> > >                                  # rmmod vmw_vsock_virtio_transport
> > > 
> > > # while true; do ./nc-vsock 3 1234; done
> > > (after 2 second)
> > > connect: Connection timed out
> > > (after 2 second)
> > > connect: Connection timed out
> > > ...
> > > 
> > >                                  # modprobe vmw_vsock_virtio_transport
> > > 
> > > connect: Connection reset by peer
> > > connect: Connection reset by peer
> > > connect: Connection reset by peer
> > > ...
> > > 
> > >                                  # nc-vsock -l 1234
> > >                                  Connetion from cid 2 port ***...
> > > (stop printing)
> > > 
> > > 
> > > The above process simulates the communication process between
> > > the `kata-runtime` and `kata-agent` after starting the Guest.
> > > In order to connect to `kata-agent` as soon as possible, 
> > > `kata-runtime` will continuously try to connect to `kata-agent` in a loop.
> > > see 
> > > https://github.com/kata-containers/runtime/blob/d054556f60f092335a22a288011fa29539ad4ccc/vendor/github.com/kata-containers/agent/protocols/client/client.go#L327
> > > But when the vsock device in the Guest is not ready, the connection
> > > will block for 2 seconds. This situation actually slows down
> > > the entire startup time of `kata-runtime`.
> > 
> > This can be done efficiently as follows:
> > 1. kata-runtime listens on a vsock port
> > 2. kata-agent-port=PORT is added to the kernel command-line options
> > 3. kata-agent parses the port number and connects to the host
> > 
> > This eliminates the reconnection attempts.
> 
> Then we'll get the same problem in reverse, won't we?
> Agent must now be running before guest can boot ...
> Or did I miss anything?

kata-runtime launches QEMU.  The QEMU guest runs kata-agent.  Therefore
it is guaranteed that kata-runtime's listen socket will be set up before
the agent executes.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]