Hi Eric,
Thanks for your response.
I like to know how test driver works.
In the libvirt.org for test driver it is mentioned as "It can start with a pre-configured default config, or be given a path to an alternate config".
Is the config is an xml file where we mentioned some dummy data so that the test driver will return it as response. If yes then where can I find this dummy file?
As mentioned earlier my intention is to mock qemu calls. so it test driver works then I'm planning to remove the qemu driver and register "test" driver as "qemu" driver and take the fake data from the config file. Please let me know which are the files I need to look into to register "test" as "qemu" and make its operations to work.
Thanks In Advance,
Arun V
On Wed, Sep 11, 2013 at 12:14 AM, Eric Blake <eblake@xxxxxxxxxx> wrote:
On 09/10/2013 12:03 PM, Arun Viswanath wrote:Rather than trying to write your own RPC handler, have you considered
> Hi All,
> I'm need to simulate libvirt API's say to mock the libvirt API
> responses. (Actually I need to simulate qemu API's response). Because of my
> project needs I need to write this simulated libvirt server in Java. I
> believe the simulated libvirt can be written as java RPC which should
> capable to receive the client RPC request calls and by dispatcher we can
> dispatch to the simulated java functions. I searched for .x file to be used
> for generating server stubs but unfortunately .x files like
> "remote_protocol.x", "virnetprotocol.x", "qemu_protocol.x" and
> "lxc_monitor_protocol.x" are not containing any procedure for libvirt API's
> that exposed. Please let me know which files will have these exposed
> procedures and how can I use it in java,
using the existing libvirt-java bindings and just targetting the
test:/// URI connection? This will give you a fairly reliable exposure
to the libvirt APIs, without actually needing a working qemu.
The .x files implement the driver API; so also does the test driver.
Basically, src/libvirt.c is the public API, which then delegates to the
appropriate driver based on what URI you connected to; if the URI is
remote (as qemu:/// and all other stateful drivers are), then libvirt.so
passes it to src/remote/remote_driver.c to be bundled up into RPC calls
which mirror the semantics of the public API. If you want to install
your own mock driver, it may be easier to build a new URI and implement
the same C interface as the test driver (see src/test/test_driver.c)
than it is to implement your own RPC parser.
Again, instead of trying to write your own RPC server, I'd instead focus
>
> Also I'm not sure how to implement the ssl layer support for the
> libvirt server in java. I need to write a java server in such a way that
> python client should capable to create a connection with uri
> "qemu+tls://systemip:port?no_tty=1". Also with the created connection
> object it should able to call the libvirt API's like getCapabilities, etc.
on utilizing the existing test:/// driver as your point of mocked calls.
As this is mostly development-related, I've set the reply-to to
libvir-list (we can drop libvirt-users from the rest of this thread).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list