[PATCH v5 0/3] Import directly from OVA tar archive if possible
by Tomáš Golembiovský
v5:
- rebase, patches 1,3,5 were merged
- 1/3: we still need to discuss whether to detect compressed discs
- 2/3:
- renamed argument noempty to keep_empty
- tests were not run
- 3/3:
- using JSON module to generate JSON (as suggested by Pino)
- all the other comments raised by Pino
v4:
- rebase to more recent master
- 1/6: using just "quote" instead of "Filename.quote"
- 2/6: reformated block of code according to Richards suggestion
- 4/6: added tests for nsplit
v3: Addressed Pino's comments, namely:
- input_ova.ml
- untar takes list of paths
- renamed untar_partial to untar_metadata
- replaced uggly regex with nsplit
- tests
- test changes are part of the main commit
- renamed test-data/guestfs-hashsums.sh to test-data/test-utils.sh
- renamed qemu_version to qemu_is_version and moved it to
test-data/test-utils.sh
- normalize paths in expect files
v2:
- rewritten the tar invocations, the output processing is now done in
OcaML rather than with a shell code; it turned out to be easier and
more readable than I have feared.
- added QEMU version check
- addressed Pino's comments
- changed tests; the expected result is now based on the QEMU used
during testing
This series is related to the problem of inefficient import of OVA
files. The needed enhancements of QEMU were merged into the codebase and
should be available in QEMU 2.8. From there we can use 'size' and
'offset' options in raw driver to tell QEMU to use only subset of a file
as an image.
The patch set is more or less complete. The only outstanding issue is
the missing detection of sparse files inside tar. But this can be done
in a separate patch. As pointed out before I didn't find a way how to
detect that by using the tar tool only and would probably require use of
some external library.
Tomáš Golembiovský (3):
v2v: ova: don't detect compressed disks, read the OVF instead
mllib: modify nsplit to take optional noempty and count arguments
v2v: ova: don't extract files from OVA if it's not needed
mllib/common_utils.ml | 13 ++-
mllib/common_utils.mli | 12 +-
mllib/common_utils_tests.ml | 30 +++++
test-data/test-utils.sh | 20 ++++
v2v/Makefile.am | 2 +
v2v/input_ova.ml | 198 +++++++++++++++++++++++++++++---
v2v/test-v2v-i-ova-formats.sh | 5 +-
v2v/test-v2v-i-ova-gz.ovf | 2 +-
v2v/test-v2v-i-ova-subfolders.expected2 | 18 +++
v2v/test-v2v-i-ova-subfolders.sh | 13 ++-
v2v/test-v2v-i-ova-tar.expected | 18 +++
v2v/test-v2v-i-ova-tar.expected2 | 18 +++
v2v/test-v2v-i-ova-tar.ovf | 138 ++++++++++++++++++++++
v2v/test-v2v-i-ova-tar.sh | 72 ++++++++++++
v2v/test-v2v-i-ova-two-disks.expected2 | 19 +++
v2v/test-v2v-i-ova-two-disks.sh | 13 ++-
16 files changed, 561 insertions(+), 30 deletions(-)
create mode 100644 v2v/test-v2v-i-ova-subfolders.expected2
create mode 100644 v2v/test-v2v-i-ova-tar.expected
create mode 100644 v2v/test-v2v-i-ova-tar.expected2
create mode 100644 v2v/test-v2v-i-ova-tar.ovf
create mode 100755 v2v/test-v2v-i-ova-tar.sh
create mode 100644 v2v/test-v2v-i-ova-two-disks.expected2
--
2.11.0
7 years, 11 months
Re: [Libguestfs] make and make install failed for libguestfs-1.24.9 on ubuntu14.04
by Pino Toscano
Hi,
(please note the mailing list is libguestfs(a)redhat.com, and -owner@ is
the address of the mailing list administrators.)
On Wednesday, 11 January 2017 13:02:29 CET Aditya Suripeddi wrote:
> I want to avail the virt-cusomize , virt-sysprep and other
> commands for configuring of my vm instances on my ubuntu14.04 machine .
> Installing the libguestfs-1.24.9 has generated 2 FAIL TEST CASES . The
> attachements have all info including configure command's warnings.
The failures are in two of the gnulib tests, which could be due to the
combination of old gnulib in that libguestfs release plus old
distribution. It should be safe to ignore them in your case, it is
enough to pass --disable-gnulib-tests to configure to not run them at
all. Also, please refer to the building instructions on the
libguestfs.org site for a more comprehensive documentation:
http://libguestfs.org/guestfs-building.1.html
In addition, you don't really need to install libguestfs to use it --
see the section about the ./run script in the documentation I linked
above.
Furthermore, please note the version you are building is old, and thus
you might hit bugs already fixed upstream (not counting all the
improvements done in the tools you want to use). You are recommended to
use the latest stable series, with currently is 1.34.x (with 1.34.3 the
latest stable release). It should build also on that Ubuntu version,
and if not we could try making it so, if it does not turn out to be too
complex.
Thanks,
--
Pino Toscano
7 years, 11 months
IRC question about ?foo etc
by Richard W.M. Jones
14:50 < cbosdonnat> pino|work, do you know how I could get ?tar passed from one function to the other in the checksum code?
14:51 < pino|work> cbosdonnat: pass it as it is, ie ?foo
14:52 < cbosdonnat> pino|work, indeed, works better... I didn't know I could use the ? in the calling function and I used the ~ instead
14:53 < pino|work> ? is handled like an option type
This is a bit complicated, but I think it may be more obvious if
you know there are two distinct issues:
Issue 1: When calling a function, ?foo is short for ?foo:foo and
~bar is short for ~bar:bar
If you're calling a function that takes a labelled parameter ~bar
and you want to pass (eg) a string you can do:
func ~bar:"hello"
If you want to pass a variable [really: a binding] to the function, then:
let v = "hello" in
func ~bar:v
But as a special case, if the variable is called bar already, then
this works:
let bar = "hello" in
func ~bar
because ~bar is short for ~bar:bar (and the same for optional
parameters like ?foo).
This leads naturally to code that looks like:
let other_func ~foo ~bar ?baz =
func ~foo ~bar ?baz
Issue 2: Optional arguments are implemented as option types (eg. None,
Some foo), except when defaults are used
If a function is defined as:
let func ?foo ~bar () =
...
then bar is passed as an ordinary parameter, it's just that at compile
time it is given a label (the labels disappear completely at runtime).
So there is no overhead or difference for the ~bar parameter.
However ?foo is implemented as an option. If the function is called
this way:
func ~bar ()
then what actually happens is the first parameter is passed as None,
and foo is assigned to None inside the function. If it is called this
way:
func ~foo:"hello" ~bar ()
then Some "hello" is passed to the function and assigned to foo inside
the function. [And as you can see, the syntax is confusingly
inconsistent as well, welcome to OCaml.]
This works slightly differently if the optional parameter has a
default, eg:
let func ?(foo = "hello") ~bar () =
...
In this case, the implementation still passes an option (None or Some ..)
to the function (because the function still needs to have a way to
know if it was called with or without the ?foo parameter), but the
implementation also implicitly adds the following code to the
beginning of the function:
let func ?(foo = "hello") ~bar () =
let foo = match [real ?foo param] with None -> "hello" | Some x -> x in
...
so foo inside the function is not an option type in this case.
HTH,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
7 years, 11 months
[PATCH] fuse: use the configured program name
by Pino Toscano
When initializing FUSE, use the program name as set (either
automatically or manually) in the guestfs handle.
---
src/fuse.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/fuse.c b/src/fuse.c
index 0180f8f..98bbc8d 100644
--- a/src/fuse.c
+++ b/src/fuse.c
@@ -989,8 +989,7 @@ guestfs_impl_mount_local (guestfs_h *g, const char *localmountpoint,
return -1;
/* Create the FUSE 'args'. */
- /* XXX we don't have a program name */
- if (fuse_opt_add_arg (&args, "guestfs_mount_local") == -1) {
+ if (fuse_opt_add_arg (&args, g->program) == -1) {
arg_error:
perrorf (g, _("fuse_opt_add_arg: %s"), localmountpoint);
fuse_opt_free_args (&args);
--
2.7.4
7 years, 11 months
[PATCH 0/5] Introducing virt-builder-repository
by Cédric Bosdonnat
Hi all,
I wanted to provide an easy way to create or update a virt-builder
repository out of a folder of template disk image files. This is what
virt-builder-repository aims at. Some of the data are computed from
the image file, others are asked the user or extracted from an existing
index file.
So far, virt-builder-repository doesn't run libguestfs on each image
to extract the architecture, the list of available partitions and the
list of volumes. May be this should be done, but I have several concerns
with it: it will add extra running time to load the appliance in each
detected new/updated image. And the question of how to handle cases where
multiple OSes are installed on the template would need to be solved:
raise an error or ask the user which one to use?
In order to share more code, I have extracted the Yajl helpers with the
yajl OCAML wrapper code, moved the libxml2 wrapper into mllib and written
some OCAML osinfo db reading code in mllib.
Cédric Bosdonnat (5):
builder: extract Yajl helper functions to yajl.ml
mllib: factorize code to add Checksum.get_checksum function
Move xml and xpath_helpers OCAML code to mllib
mllib: add libosinfo DB reading helpers
Add a virt-builder-repository tool
.gitignore | 3 +
builder/Makefile.am | 91 ++++++-
builder/builder_repository.ml | 493 ++++++++++++++++++++++++++++++++++++
builder/simplestreams_parser.ml | 52 ----
builder/virt-builder-repository.pod | 144 +++++++++++
builder/yajl.ml | 55 ++++
builder/yajl.mli | 29 +++
docs/C_SOURCE_FILES | 2 +-
mllib/Makefile.am | 19 +-
mllib/checksums.ml | 20 +-
mllib/checksums.mli | 3 +
mllib/osinfo.ml | 64 +++++
mllib/osinfo.mli | 21 ++
mllib/osinfopath.ml | 1 +
{v2v => mllib}/xml-c.c | 0
{v2v => mllib}/xml.ml | 0
{v2v => mllib}/xml.mli | 0
{v2v => mllib}/xpath_helpers.ml | 0
{v2v => mllib}/xpath_helpers.mli | 0
v2v/Makefile.am | 17 +-
20 files changed, 932 insertions(+), 82 deletions(-)
create mode 100644 builder/builder_repository.ml
create mode 100644 builder/virt-builder-repository.pod
create mode 100644 mllib/osinfo.ml
create mode 100644 mllib/osinfo.mli
create mode 100644 mllib/osinfopath.ml
rename {v2v => mllib}/xml-c.c (100%)
rename {v2v => mllib}/xml.ml (100%)
rename {v2v => mllib}/xml.mli (100%)
rename {v2v => mllib}/xpath_helpers.ml (100%)
rename {v2v => mllib}/xpath_helpers.mli (100%)
--
2.11.0
7 years, 11 months
[PATCH v4 0/6] Import directly from OVA tar archive if possible
by Tomáš Golembiovský
v4:
- rebase to more recent master
- 1/6: using just "quote" instead of "Filename.quote"
- 2/6: reformated block of code according to Richards suggestion
- 4/6: added tests for nsplit
v3: Addressed Pino's comments, namely:
- input_ova.ml
- untar takes list of paths
- renamed untar_partial to untar_metadata
- replaced uggly regex with nsplit
- tests
- test changes are part of the main commit
- renamed test-data/guestfs-hashsums.sh to test-data/test-utils.sh
- renamed qemu_version to qemu_is_version and moved it to
test-data/test-utils.sh
- normalize paths in expect files
v2:
- rewritten the tar invocations, the output processing is now done in
OcaML rather than with a shell code; it turned out to be easier and
more readable than I have feared.
- added QEMU version check
- addressed Pino's comments
- changed tests; the expected result is now based on the QEMU used
during testing
This series is related to the problem of inefficient import of OVA
files. The needed enhancements of QEMU were merged into the codebase and
should be available in QEMU 2.8. From there we can use 'size' and
'offset' options in raw driver to tell QEMU to use only subset of a file
as an image.
The patch set is more or less complete. The only outstanding issue is
the missing detection of sparse files inside tar. But this can be done
in a separate patch. As pointed out before I didn't find a way how to
detect that by using the tar tool only and would probably require use of
some external library.
Tomáš Golembiovský (6):
mllib: compute checksum of file inside tar
v2v: ova: don't detect compressed disks, read the OVF instead
v2v: ova: move the untar function
mllib: modify nsplit to take optional noempty and count arguments
tests: rename guestfs-hashsums.sh to test-utils.sh
v2v: ova: don't extract files from OVA if it's not needed
mllib/checksums.ml | 11 +-
mllib/checksums.mli | 7 +-
mllib/common_utils.ml | 12 +-
mllib/common_utils.mli | 12 +-
mllib/common_utils_tests.ml | 26 +++
test-data/Makefile.am | 2 +-
test-data/{guestfs-hashsums.sh => test-utils.sh} | 20 +++
tests/qemu/qemu-liveness.sh | 2 +-
tests/qemu/qemu-snapshot-isolation.sh | 2 +-
v2v/Makefile.am | 1 +
v2v/input_ova.ml | 194 +++++++++++++++++++++--
v2v/test-v2v-i-ova-formats.sh | 7 +-
v2v/test-v2v-i-ova-gz.ovf | 2 +-
v2v/test-v2v-i-ova-gz.sh | 2 +-
v2v/test-v2v-i-ova-subfolders.expected2 | 18 +++
v2v/test-v2v-i-ova-subfolders.sh | 15 +-
v2v/test-v2v-i-ova-tar.expected | 18 +++
v2v/test-v2v-i-ova-tar.expected2 | 18 +++
v2v/test-v2v-i-ova-tar.ovf | 138 ++++++++++++++++
v2v/test-v2v-i-ova-tar.sh | 71 +++++++++
v2v/test-v2v-i-ova-two-disks.expected2 | 19 +++
v2v/test-v2v-i-ova-two-disks.sh | 15 +-
v2v/test-v2v-i-ova.sh | 2 +-
v2v/test-v2v-in-place.sh | 2 +-
24 files changed, 571 insertions(+), 45 deletions(-)
rename test-data/{guestfs-hashsums.sh => test-utils.sh} (73%)
create mode 100644 v2v/test-v2v-i-ova-subfolders.expected2
create mode 100644 v2v/test-v2v-i-ova-tar.expected
create mode 100644 v2v/test-v2v-i-ova-tar.expected2
create mode 100644 v2v/test-v2v-i-ova-tar.ovf
create mode 100755 v2v/test-v2v-i-ova-tar.sh
create mode 100644 v2v/test-v2v-i-ova-two-disks.expected2
--
2.10.2
7 years, 11 months