Re: [Qemu-discuss] Qemu Socket Backend Reliablility / Retry

[Mike Lovell]

On 05/21/2014 07:54 PM, Josh Powers wrote:
> Hello All,
>
> I am fairly new to the QEMU world but I have been using it for a few
> weeks now and it is amazing, solving a lot of problems for me.
>
> However I have encountered one problem I haven't found a good solution
> around. I am spinning up QEMU instances automatically then configuring
> their network backend to connect over a socket at run time through the
> QEMU console.  I have noticed however that occationally if I startup
> the listen end and too quickly start up the connect end it will fail
> to connect, presumably the listen end isnt initialized yet.
>
> At any rate I have "solved" this problem by adding an arbitrary delay
> to my tool that is spinning the vm's up but that is not a good
> perminant solution.  I have been diging around trying to figure out if
> there is some way to get the connect end to continue to retry if it
> fails to connect or to get an easy to parse verification that the
> listen end is ready for the connect end.
>
> Any ideas?  I had considered using multicast as a side note since the
> order of the connections dont matter however I have restrictions that
> prevent me from using multicast.  The virtual machines are being spun
> up on different servers (or at least can be) so as far as I know my
> backend does need to be a socket not one of the other options. Also I
> am intending to connect the two instances directly "as though by a
> wire" so I dont want to use the other options like tap etc.
>
> Thanks in advance for your time,
> Josh Powers

have you looked at using udp sockets instead of the listen/connect 
socket options? udp unicast sockets aren't supported in older versions 
of qemu. i think 1.1 or later is required. the udp socket mode uses the 
sendto() call to send a udp packet to the remote address and the packet 
just gets dropped if the other side isn't ready for it. this isn't a 
connected tcp session so packets aren't guaranteed to be delivered but 
it shouldn't be a problem since this is encapsulating ethernet frames 
and ethernet doesn't guarantee delivery.

for example, lets assume you have host1 at 1.2.3.4 using port udp/9001 
and host2 at 1.2.3.5 using port udp/9002. you would need to specify 
something like "-net socket,udp=1.2.3.5:9002,localaddr=1.2.3.4:9001" on 
host1. then you would use "-net 
socket,udp=1.2.3.4:9001,localaddr=1.2.3.5:9002" on host2. it is a little 
more complicated than the listen/connect config but not too bad. you do 
have to specify the local and remote address on both qemu processes.

it might not be a good solution for you but something you might want to 
experiment with. i just did a quick look through the libvirt 
documentation and it doesn't look like libvirt has support for qemu udp 
unicast sockets so this might not be an option if you are using libvirt.

mike