Hi,
On 8 May 2013, at 12:32, "Richard W.M. Jones" wrote:
> On Wed, Apr 24, 2013 at 11:39:02AM +0100, David Scott wrote:
>> Hi,
>>
>> Here are my latest patches which add OCaml bindings for the libvirt event
>> API. I'm pretty happy with them now: my t
On 01/05/13 09:46, Ian Campbell wrote:
I would suggest that libvirt+libxl expose the version as the "emulator"
option and not the path. Just leave the path as the default in the
normal case. You may also want to provide an extra
emulator-path-override tag/attribute/XML for advanced users, but tha
Hi,
[added xen-devel: FYI this is about how to properly set the libxl
device_model_version when the user has provided a manual device_model
override (aka a path to a qemu) in the libvirt domain XML.]
On 30/04/13 16:10, Jim Fehlig wrote:
David Scott wrote:
The emulator path supplied can be
a wrapper script to (eg)
adjust the arguments of the old qemu during development, you will
have to ensure the wrapper script also has the name "qemu-dm", by
placing it in a separate directory.
Signed-off-by: David Scott
---
src/libxl/libxl_conf.c | 44 +
Jim, Daniel, thanks for all the feedback!
On 29/04/13 20:02, Jim Fehlig wrote:
[ snip ]
As mentioned in my other response [1], your original patch (with a check
to verify the requested emulator exists) should be sufficient.
OK, I'll send an emulator-only patch shortly.
Cheers,
Dave
--
libvir
We cross-check the given path against the capabilties, and translate
it into a libxl_device_model_version.
Signed-off-by: David Scott
---
src/libxl/libxl_conf.c | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/src/libxl
are built. We examine the filesystem for the emulators
at runtime and expose them as separate "domains" within the same
"guest" architecture.
Signed-off-by: David Scott
---
src/libxl/libxl_conf.c | 87 ---
1 files change
Hi,
These patches expose multiple xen device model options in the
capabilities XML and allow the user to select a specific device
model via the domain XML's tag.
It is important to control the device model per VM, since the
default is changing from xen-4.2 "qemu traditional" to xen-4.3
"qemu ups
Hi Jim,
Thanks for the explanation about the capabilities.
On 27/04/13 00:44, Jim Fehlig wrote:
Do you have time for an upstream libvirt patch to expose the possible
emulators in the capabilities, along with this patch allowing the user
to specify one?
I'll have a go and send you (cc'ing the
pplying the int64 value.
The OCaml function can then find the right callback in the Hashtbl
and call it.
The client can deregister the callback with:
E.deregister_any conn id;
Signed-off-by: David Scott
---
libvirt/generator.pl| 2 +
libvirt/li
This one is a 'one-off' but it ought to be possible to use the generator
to create the function (it has signature 'conn, int, int : int')
This function first appeared in libvirt version 0.9.8.
Signed-off-by: David Scott
---
libvirt/libvirt.ml | 2 ++
libvirt/libv
Signed-off-by: David Scott
---
.gitignore| 1 +
Makefile.in | 1 +
examples/Makefile.in | 13 -
examples/domain_events.ml | 145 ++
4 files changed, 159 insertions(+), 1 deletion(-)
create mode 100644
Hi,
Here are my latest patches which add OCaml bindings for the libvirt event
API. I'm pretty happy with them now: my test programs have been running
for long periods of time without incident.
Changes from the previous submission (sent 2013-04-17)
* added a patch which removes the backwards com
i.e. all of these:
On Wed, Apr 17, 2013 at 11:16 AM, David Scott wrote:
[snip]
> + case VIR_DOMAIN_EVENT_ID_IO_ERROR_REASON:
>
+cb = VIR_DOMAIN_EVENT_CALLBACK(s_s_i_s_callback);
> +break;
> + case VIR_DOMAIN_EVENT_ID_CONTROL_ERROR:
> +cb = VIR_DOMAIN_EVENT_CALL
The info.capacity was being overwritten with the info.allocation.
Signed-off-by: David Scott
---
libvirt/libvirt_c_oneoffs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libvirt/libvirt_c_oneoffs.c b/libvirt/libvirt_c_oneoffs.c
index 80e1c03..01985f5 100644
--- a/libvirt
l check.
The functions
virConnectDomainEvent{Register,Deregister}Any
virEventRegisterDefaultImpl
virEventRunDefaultImpl
were present in libvirt 0.9.1 so we always assume the symbols are
present.
Signed-off-by: David Scott
---
config.h.in | 6 +
configure.ac| 2
Signed-off-by: David Scott
---
.gitignore| 1 +
Makefile.in | 1 +
examples/.depend | 14 +++--
examples/Makefile.in | 13 -
examples/domain_events.ml | 145 ++
5 files changed, 167 insertions(+), 7
This one is a 'one-off' but it ought to be possible to use the generator
to create the function (it has signature 'conn, int, int : int')
This function first appeared in libvirt version 0.9.8.
Signed-off-by: David Scott
---
config.h.in | 3 +++
configure.ac
Hi,
I've made an improved set of ocaml bindings for the libvirt event
mechanism which I'm now reasonably happy with. Improvements since
my first submission:
1. it's possible to deregister callbacks with 'deregister_any'
2. the callback to ocaml now re-acquires the heap lock *before*
creating a
int64 value.
The OCaml function can then find the right callback in the Hashtbl
and call it.
Signed-off-by: David Scott
---
config.h.in |9 +
configure.ac|3 +
libvirt/libvirt.ml | 714 +++
libvirt/lib
Signed-off-by: David Scott
---
.gitignore|1 +
Makefile.in |1 +
examples/.depend | 14 ++---
examples/Makefile.in | 13 -
examples/domain_events.ml | 124 +
5 files changed, 146 insertions
Hi,
I've made an prototype set of ocaml bindings for the libvirt event
mechanism -- here is what I've got so far.
It's possible to register for all the types supported by
virConnectDomainEventRegisterAny
I've not tested each type of event yet, but the basics are all working.
For every distin
This one is a 'one-off' but it ought to be possible to use the generator
to create the function (it has signature 'conn, int, int : int')
Signed-off-by: David Scott
---
config.h.in |3 +++
configure.ac|1 +
libvirt/.depen
On Wed, Mar 6, 2013 at 5:01 PM, Richard W.M. Jones wrote:
> On Wed, Mar 06, 2013 at 04:18:02PM +0000, David Scott wrote:
> > These patches fix a couple of minor issues I encountered while
> > trying to manipulate storage pools and volumes from an OCaml
> > program.
> &g
These patches fix a couple of minor issues I encountered while
trying to manipulate storage pools and volumes from an OCaml
program.
If you're interested, the OCaml client code is a simple adapter
to allow an XCP host to use libvirt (for storage only atm, more
later). The client code (so far) is h
This corrects a mismatch between the generated C stubs and the .ml
interface.
Signed-off-by: David Scott
---
libvirt/libvirt.ml |2 +-
libvirt/libvirt.mli |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libvirt/libvirt.ml b/libvirt/libvirt.ml
index 443b22b
all:
Pool.set_autostart
Volume.create_xml
Volume.delete
Signed-off-by: David Scott
---
libvirt/libvirt.ml |6 +++---
libvirt/libvirt.mli |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libvirt/libvirt.ml b/libvirt/libvirt.ml
index 07542a9..443b22b 100644
--- a/libv
This affects the following functions:
virStoragePoolBuild
virStoragePoolDelete
virStorageVolDelete
Previously a call to virStorageVolDelete would succeed returning 0, which
was interpreted as false, causing us to raise an exception with
VIR_ERR_NONE.
Signed-off-by: David Scott
28 matches
Mail list logo