5:14 p.m.
Hi,
Thanks for libvirt. It is a life saver. I am in the process of writing some
custom wrappers for libvirt so that it can be easily accessed from nodejs
using the nodejs-ffi interfacing (basically describes a way to convert
nodejs to c calls). I did write the wrapper on the lines of the examples
provided. But I am unable to see my new functions in the libvirt.so file
(which nodejs interfacing needs). Which means that my wrappers under
<libvirt>/wrappers/ are not getting into libvirt.so like the ones at
<libvirt>/examples
Can you please guide me as to where I am going wrong? I was able to do a
successful configure + make and I thought this will regenerate the new
libvirt.so (which it does, but I cant see my new wrapper methods in it).
Much appreciated,
Thanks,
vik.
2:19 a.m.
Hello Vik,
On Thu, 2014-02-20 at 15:14 -0800, vikhyath reddy wrote:
Thanks for libvirt. It is a life saver. I am in the process of
writing
some custom wrappers for libvirt so that it can be easily accessed
from nodejs using the nodejs-ffi interfacing (basically describes a
way to convert nodejs to c calls). I did write the wrapper on the
lines of the examples provided. But I am unable to see my new
functions in the libvirt.so file (which nodejs interfacing needs).
Which means that my wrappers under <libvirt>/wrappers/ are not getting
into libvirt.so like the ones at <libvirt>/examples
I don't quite get what you are doing. Why would you need to modify
libvirt to wrap it in a nodejs-based script? What is that
libvirt/wrappers folder you are mentioning? there is no such thing in
the libvirt repository.
From what I understood from the nodejs-ffi page, you should mostly
write
javascript code similar to this:
------------ %< ------------
var ref = require('ref');
var ffi = require('ffi');
var virConnect = ref.types.void;
var virConnectPtr = ref.refType(virConnect);
var libvirt = ffi.Library('libvirt', {
'virInitialize': [ 'int', [ ] ],
'virConnectOpen': [virConnectPtr, [ string ]],
...
});
------------ %< ------------
I'm pretty sure generating this could be automated by a small program or
script or even a clang plugin, using include/libvirt/libvirt.h.in as
input.
Can you please guide me as to where I am going wrong? I was able to
do
a successful configure + make and I thought this will regenerate the
new libvirt.so (which it does, but I cant see my new wrapper methods
in it).
I case you really want to modify libvirt, then you should proceed as
mentioned on this page:
http://libvirt.org/compiling.html
Regards,
--
Cedric
9:30 a.m.
Thanks for the reply Cedric,
wrappers is a dir that I made similar to examples which wraps the libvirt c code. The
reason why I am doing this is to simplify the usage of virConnectOpenAuth - it's
arguments and callbacks from JavaScript. Using ffi, I am unable to create the right
callbacks and have it pass the correct arguments.
I also followed a different approach of having my wrappers turned into a shared object
(.so) and linking libvirt.so as a dependency.
My environment is esx requiring authentication.
Much appreciated,
Vik.
On Feb 21, 2014, at 12:19 AM, Cedric Bosdonnat
<cbosdonnat(a)suse.com> wrote:
Hello Vik,
> On Thu, 2014-02-20 at 15:14 -0800, vikhyath reddy wrote:
> Thanks for libvirt. It is a life saver. I am in the process of writing
> some custom wrappers for libvirt so that it can be easily accessed
> from nodejs using the nodejs-ffi interfacing (basically describes a
> way to convert nodejs to c calls). I did write the wrapper on the
> lines of the examples provided. But I am unable to see my new
> functions in the libvirt.so file (which nodejs interfacing needs).
> Which means that my wrappers under <libvirt>/wrappers/ are not getting
> into libvirt.so like the ones at <libvirt>/examples
I don't quite get what you are doing. Why would you need to modify
libvirt to wrap it in a nodejs-based script? What is that
libvirt/wrappers folder you are mentioning? there is no such thing in
the libvirt repository.
From what I understood from the nodejs-ffi page, you should mostly write
javascript code similar to this:
------------ %< ------------
var ref = require('ref');
var ffi = require('ffi');
var virConnect = ref.types.void;
var virConnectPtr = ref.refType(virConnect);
var libvirt = ffi.Library('libvirt', {
'virInitialize': [ 'int', [ ] ],
'virConnectOpen': [virConnectPtr, [ string ]],
...
});
------------ %< ------------
I'm pretty sure generating this could be automated by a small program or
script or even a clang plugin, using include/libvirt/libvirt.h.in as
input.
> Can you please guide me as to where I am going wrong? I was able to do
> a successful configure + make and I thought this will regenerate the
> new libvirt.so (which it does, but I cant see my new wrapper methods
> in it).
I case you really want to modify libvirt, then you should proceed as
mentioned on this page:
http://libvirt.org/compiling.html
Regards,
--
Cedric
7 a.m.
Hey,
On Fri, Feb 21, 2014 at 07:30:08AM -0800, Vikhyath Reddy wrote:
Thanks for the reply Cedric,
wrappers is a dir that I made similar to examples which wraps the libvirt
c code. The reason why I am doing this is to simplify the usage of
virConnectOpenAuth - it's arguments and callbacks from JavaScript. Using
ffi, I am unable to create the right callbacks and have it pass the
correct arguments.
Depending on what parts of libvirt API you need to use from javascript,
libvirt-glib may be an option as it already makes some parts of libvirt API
accessible from javascript, see
http://libvirt.org/git/?p=libvirt-glib.git;a=blob;f=examples/conn-test.js...
for example. I don't know if this would be usable from nodejs?
If this is a good fit for what you need, patches extending the libvirt API
wrapped by libvirt-glib are very welcome ;)
Christophe
6:09 p.m.
Thanks for the replies guys, libvirt-glib sure sounds interesting. On the
other hand I was able to leave libvirt.so alone and write my own wrapper
(based on libvirt/examples) for easy calls from NodeJS. I can get to list
VMs, their config etc. from node but not able to list the operating system
running on the VM (ubuntu, win7, etc.). I can get the os_type though (hvm
in my case) but that does not tell me whether it is running a windows or a
linux distro.
On Mon, Feb 24, 2014 at 5:00 AM, Christophe Fergeau <cfergeau(a)redhat.com>wrote:
Hey,
On Fri, Feb 21, 2014 at 07:30:08AM -0800, Vikhyath Reddy wrote:
> Thanks for the reply Cedric,
>
> wrappers is a dir that I made similar to examples which wraps the libvirt
> c code. The reason why I am doing this is to simplify the usage of
> virConnectOpenAuth - it's arguments and callbacks from JavaScript. Using
> ffi, I am unable to create the right callbacks and have it pass the
> correct arguments.
Depending on what parts of libvirt API you need to use from javascript,
libvirt-glib may be an option as it already makes some parts of libvirt API
accessible from javascript, see
http://libvirt.org/git/?p=libvirt-glib.git;a=blob;f=examples/conn-test.js...
for example. I don't know if this would be usable from nodejs?
If this is a good fit for what you need, patches extending the libvirt API
wrapped by libvirt-glib are very welcome ;)
Christophe
8:03 p.m.
On 02/24/2014 05:09 PM, vikhyath reddy wrote:
[Please don't top-post on technical lists]
Thanks for the replies guys, libvirt-glib sure sounds interesting. On
the
other hand I was able to leave libvirt.so alone and write my own wrapper
(based on libvirt/examples) for easy calls from NodeJS. I can get to list
VMs, their config etc. from node but not able to list the operating system
running on the VM (ubuntu, win7, etc.). I can get the os_type though (hvm
in my case) but that does not tell me whether it is running a windows or a
linux distro.
Libvirt can't tell you what the guest is running. For that, you need
higher-level software, such as libguestfs. virt-manager is an example
of a program that uses libguestfs to probe which OS is running in the guest.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3:41 p.m.
Libvirt can't tell you what the guest is running. For that, you
need
higher-level software, such as libguestfs. virt-manager is an example
of a program that uses libguestfs to probe which OS is running in the
guest.
Awesome! you guys are of so much help. And sorry for top posting.
Ran into something else today, why are calls like
a) virConnectListAllNetworks(...)
b) virConnectListAllStoragePools(...)
return "not supported by connection driver". I am running ESX with
libvirt-1.2.1. But I can use
a) virConnectListStoragePools(...)
b) virConnectListNetworks(...)
without any problems. Do you guys think I have libvirt configured
incorrectly at my end?
Thanks,
Vik.
On Mon, Feb 24, 2014 at 6:03 PM, Eric Blake <eblake(a)redhat.com> wrote:
> On 02/24/2014 05:09 PM, vikhyath reddy wrote:
>
> [Please don't top-post on technical lists]
>
> > Thanks for the replies guys, libvirt-glib sure sounds interesting. On the
> > other hand I was able to leave libvirt.so alone and write my own wrapper
> > (based on libvirt/examples) for easy calls from NodeJS. I can get to list
> > VMs, their config etc. from node but not able to list the operating
> system
> > running on the VM (ubuntu, win7, etc.). I can get the os_type though (hvm
> > in my case) but that does not tell me whether it is running a windows or
> a
> > linux distro.
>
Libvirt can't tell you what the guest is running. For that, you
need
higher-level software, such as libguestfs. virt-manager is an example
of a program that uses libguestfs to probe which OS is running in the
> guest.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
4:42 p.m.
On 02/25/2014 02:41 PM, vikhyath reddy wrote:
a) virConnectListAllNetworks(...)
b) virConnectListAllStoragePools(...)
return "not supported by connection driver". I am running ESX with
libvirt-1.2.1. But I can use
That merely means no one has written the patches for ESX to support
those APIs. To see the full matrix of which drivers support which
calls, see http://libvirt.org/hvsupport.html
If you are interested in submitting a patch, we're all ears; it should
be particularly easy to patch the ListAll* commands when there is
already the older List* API to borrow from.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3925
days inactive
3930
days old
7 comments
5 participants
participants (5)
-
Cedric Bosdonnat -
Christophe Fergeau -
Eric Blake -
Vikhyath Reddy -
vikhyath reddy