Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port

[Anthony Liguori <anthony@codemonkey.ws>]

Gilad Ben-Yossef wrote:
> Hi Anthony,
>
> Thanks for the feedback.
>
> I'm afraid I'm to blame for the idea to this patch (but Shahar was the 
> one
> that actually did the real work, I'm just bothering him).
>
> Anthony Liguori wrote:
>
>>>
>>> The problem with the solution you suggest is that all VNC traffic 
>>> will be first sent to the unix domain socket, and then copied to the 
>>> TCP socket. This double work may be acceptable if we're talking 
>>> about one instance of qemu, but as I said, I run many concurrent 
>>> sessions which create too much load. In the solution I suggest, this 
>>> extra copying is not needed.
>>
>>
>> You're optimizing prematurely.  The overhead of the copy is 
>> negligible for something like VNC.  Under normal circumstances, we're 
>> talking about 30-100k/s.  During idle usage, the bandwidth drops to 
>> almost nothing.
>>
>
> There are also the double context switches, more file descriptors and
> extra proccess to handle the copy but you are abosutly right - we have
> no indication what so ever that this really has any measurable impact
> on perfomance.
>
> I guess it's easier to resort to perfomance as an excuse since it 
> involves
> things you can measure (even if they are meaningless) rather then trying
> to justify a design decision because it simply looks better. ;-)
>
> I'll try to do just that, anyway:
>
> Using Unix domain sockets would require adding extra code in some 
> other proccess
> that will handle the socket to socket transfer. About 15 lines of code 
> that must
> be running for as long as qemu does to handle the communication. That 
> code still
> needs to be mnaintained, seperate from qemu, by anyone that trying to 
> do something
> similar (so we have sync problems etc.)
>
> On the other hand, the change to qemu is ~5 lines (option parsing not 
> included ;-)
> It's initaliation code only (no suprises mid run) and is maintained as 
> part of qemu
> with exact same functionality.

Here are the reasons why the Unix domain socket approach is superior:

Sharing a file descriptor implies a parent/child relationship.  It also 
implies that the daemon will be running for the entire lifetime of the 
VM.  Since VM's are meant to run for very long periods of time, this is 
quite limiting.  By utilizing a domain socket, you gain the ability to 
record on disk the state of the daemon and then restart.  The layer of 
redirection also allows you to let your uses change the VNC server 
properties while the VM is running (so you change the listening vnc 
display from localhost:3 to :22 without restarting the VM).

Plus, live migration has no hope of working if you're passing file 
descriptors on the command line as they're meaningless once you've migrated.

Regards,

Anthony Liguor
> If you think users other then us will use the patch (and we believe 
> they will),
> we think it'll be useful for this to be included in qemu mainline.
>
> Anyway, thanks for reading this long email and for qemu VNC support in 
> general :-)
>
> Cheers,
> Gilad
>