Re: [Qemu-devel] [RFC] libqblock OOM issue

[Wenchao Xia <xiawenc@linux.vnet.ibm.com>]

 > On Wed, Nov 14, 2012 at 11:50:06AM +0800, Wenchao Xia wrote:
>>    In order to resolve OOM issue, I am trying wrap all APIs using
>> sunrpc, need some suggestion before coding.
>
> Is the client/server approach really necessary or can you write a
> library that invokes qemu-nbd/qemu-img?
>
> If there is a startup cost problem with qemu-img it may be possible to
> add an interactive mode (like qemu-io) where qemu-img stays open and
> responds to commands (maybe in JSON encoding).
>
> The difference between this and the RPC approach is that you can write a
> relatively thin NBD and qemu-img library with the tools that already
> exist today.
>
> Stefan
>

   I understand your reason about using qemu-img and qemu-nbd and
appreciate for the suggestion. Currently libqblock already have the
capabilities of r/w images as qemu-nbd, and have info retrieving
capabilities as qemu-img. So the difference will be:
   using qemu-img qemu-nbd, it needs nbd client/json parser code, 
modification for qemu-img is needed for each new function added in
libqblock.
   using rpc plus native lib, it needs good framework to transparently
pass the information to client side for every API.
   IMHO, considering now libqblock have all the capabilities required
except OOM, it is not hard to get same effect as using qemu-img and
qemu-nbd, by wrapping read/write/info retrieve APIs if I keep the
file stays open in server side and make server/client not mirrored.
How to write a good enough framework which can wrap different API in an
unified style, and keep this layer as simple, as transparent as
possible, whether I should break the mirror between client/server, are
some question I am not quite sure.



-- 
Best Regards

Wenchao Xia