[PATCH v2 0/3] Fix OVA import with libvirt backend
by Tomáš Golembiovský
v2:
- 1/3: same as in previous version
- 2/3: add check for libvirt version
- 3/3: restore the disabled test
The libvirt patch [2] that should fix our problem with 'raw' driver that
is mentioned in [1] was merged.
To realy fix things, there is at least one thing we have to change on our side.
We have to be explicit about the driver in the JSON we generate.
[1] https://www.redhat.com/archives/libguestfs/2017-February/msg00101.html
[2] https://www.redhat.com/archives/libvir-list/2017-February/msg00575.html
Tomáš Golembiovský (3):
v2v: ova: fix generated JSON for libvirt support
v2v: ova: check libvirt version before OVA import
v2v: tests: restore disabled OVA test
v2v/Makefile.am | 4 ++--
v2v/input_ova.ml | 4 +++-
v2v/test-v2v-i-ova-subfolders.expected2 | 2 +-
v2v/test-v2v-i-ova-tar.expected2 | 2 +-
v2v/test-v2v-i-ova-two-disks.expected2 | 4 ++--
v2v/test-v2v-i-ova.sh | 4 +---
v2v/utils.ml | 14 ++++++++++++++
v2v/utils.mli | 5 +++++
8 files changed, 29 insertions(+), 10 deletions(-)
--
2.11.1
8 years, 1 month
[PATCH] inspect: ignore /dev/cdN devices in /etc/fstab
by Pino Toscano
Non-Linux Unix guests may have static devices for CDs, so make sure to
skip them when reading /etc/fstab. This is the same as done for
/dev/fdN devices, i.e. floppy devices.
---
lib/inspect-fs-unix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/inspect-fs-unix.c b/lib/inspect-fs-unix.c
index 7e940d6..9b6bfbf 100644
--- a/lib/inspect-fs-unix.c
+++ b/lib/inspect-fs-unix.c
@@ -1305,6 +1305,7 @@ check_fstab (guestfs_h *g, struct inspect_fs *fs)
* discs.
*/
if ((STRPREFIX (spec, "/dev/fd") && c_isdigit (spec[7])) ||
+ (STRPREFIX (spec, "/dev/cd") && c_isdigit (spec[7])) ||
STREQ (spec, "/dev/floppy") ||
STREQ (spec, "/dev/cdrom") ||
STRPREFIX (spec, "/dev/iso9660/"))
--
2.9.3
8 years, 1 month
Re: [Libguestfs] not able to 'make quickcheck'
by Richard W.M. Jones
On Tue, Feb 21, 2017 at 11:19:10PM -0800, amita4581 wrote:
> Hi
> i am trying to install libguestfs on linux distro (ubuntu 15.10). and following the below link
> http://libguestfs.org/guestfs-building.1.html
> - at make stage it suggest below command and retry 'make'
> rm po-docs/podfiles; make -C po-docs update-po
> - i run above command and re 'make' successfully. however i am not able to get ' make quickcheck' through. the error output is attached with this query.
>
> any help will be appreciated.
[The attachment showed ...
supermin: kernel: picked kernel vmlinuz-4.2.0-42-generic
cp: cannot open '/boot/vmlinuz-4.2.0-42-generic' for reading: Permission denied
supermin: cp -p '/boot/vmlinuz-4.2.0-42-generic' '/home/mnit/libguestfs/tmp/.guestfs-1000/appliance.d.60xjvo2z/kernel': command failed, see earlier errors
libguestfs: error: /usr/bin/supermin exited with error status 1, see debug messages above
]
This is a bug in Ubuntu, please read:
http://libguestfs.org/guestfs-faq.1.html#where-can-i-get-the-latest-binar...
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
8 years, 1 month
Fwd: nbdkit async
by Richard W.M. Jones
----- Forwarded message -----
Date: Sat, 18 Feb 2017 22:21:19 -0500
Subject: nbdkit async
Hello,
Hope this is the right person to contact regarding nbdkit design.
I have a high latency massively parallel device that I am currently
implementing as an nbdkit plugin in c++ and have run into some design
limitations due to the synchronous callback interface nbdkit requires.
Nbdkit is currently designed to call the plugin
pread/pwrite/trim/flush/zero ops as synchronous calls and expects when the
plugin functions return that it can then send the nbd reply to the socket.
It's parallel thread model is also not implemented as of yet but the
current design still mandates a worker thread per parallel op in progress
due to the synchronous design of the plugin calls.
I would like to modify this to allow for an alternative operating mode
where nbdkit calls the plugin functions and expects the plugin to callback
to nbdkit when a request has completed rather than responding right after
the plugin call returns to nbdkit.
If you are familiar with fuse low level api design, something very similar
to that.
An example flow for a read request would be as follows:
1) nbdkit reads and validates the request from the socket
2) nbdkit calls handle_request but now also passing in the nbd request
handle value
3) nbdkit bundles the nbd request handle value, bool flush_on_update, and
read size into an opaque ptr to struct
4) nbdkit calls my_plugin.pread passing in the usual args + the opaque ptr
5) my_plugin.pread makes an asynchronous read call with a handler set on
completion to call nbdkit_reply_read(conn, opaque ptr, buf) or on error
nbdkit_reply_error(conn, opaque_ptr, error)
6) my_plugin.pread returns back to nbdkit without error after it has
started the async op but before it has completed
7) nbdkit doesn't send a response to the conn->sockout beause when the
async op has completed my_plugin will callback to nbdkit for it to send the
response
8) nbdkit loop continues right away on the next request and it reads and
validates the next request from conn->sockin without waiting for the
previous request to complete
*) Now requires an additional mutex on the conn->sockout for writing
responses
The benefit of this approach is that 2 threads (1 thread for reading
requests from the socket and kicking off requests to the plugin and 1
thread (or more) in a worker pool executing the async handler callbacks)
can service 100s of slow nbd requests in parallel overcoming high latency.
The current design with synchronous callbacks we can provide async in our
plugin layer for pwrites and implement our flush to enforce it but we can't
get around a single slow high latency read op blocking the entire pipe.
I'm willing to work on this in a branch and push this up as opensource but
first wanted to check if this functionality extension is in fact something
redhat would want for nbdkit and if so if there were suggestions to the
implementation.
Initial implementation approach was going to be similar to the
fuse_low_level approach and create an entirely separate header file for the
asynchronous plugin api because the plugin calls now need an additional
parameter (opaque ptr to handle for nbdkit_reply_). This header file
nbdkit_plugin_async.h defines the plugin struct with slightly different
function ptr prototypes that accepts the opaque ptr to nbd request handle
and some additional callback functions nbdkit_reply_error, nbdkit_reply,
and nbdkit_reply_read. The user of this plugin interface is required to
call either nbdkit_reply_error or nbdkit_reply[_read] in each of the
pread/pwrite/flush/trim/zero ops.
If you got this far thank you for the long read and please let me know if
there is any interest.
Thank you,
- Shaun McDowell
----- End forwarded message -----
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
8 years, 1 month
[PATCH 1/3] dib: unset all temporary dirs envvars in fake-sudo
by Pino Toscano
The real sudo does it as well, and leaving them when preserving the
environment (-E) maybe breaks the applications, as e.g. chroot will have
a TMPDIR path pointing outside of it.
---
dib/dib.ml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/dib/dib.ml b/dib/dib.ml
index df83ba1..d15cd19 100644
--- a/dib/dib.ml
+++ b/dib/dib.ml
@@ -301,6 +301,11 @@ if [ -z \"$preserve_env\" ]; then
esac
done
fi
+# TMPDIR needs to be unset, regardless of -E
+unset TMPDIR
+# ... and do that also to the other \"TMPDIR\"-like variables
+unset TMP
+unset TMP_DIR
cmd=$1
shift
--
2.9.3
8 years, 1 month
[PATCH v3 0/7] Feature: Yara file scanning
by Matteo Cafasso
Rebase patches on top of 1.35.25.
No changes since last series.
Matteo Cafasso (7):
daemon: expose file upload logic
appliance: add yara dependency
New API: yara_load
New API: yara_destroy
New API: internal_yara_scan
New API: yara_scan
yara_scan: added API tests
appliance/packagelist.in | 4 +
configure.ac | 1 +
daemon/Makefile.am | 4 +-
daemon/cleanups.c | 9 +
daemon/cleanups.h | 2 +
daemon/daemon.h | 3 +
daemon/upload.c | 70 +++----
daemon/yara.c | 301 +++++++++++++++++++++++++++++++
generator/actions.ml | 64 +++++++
generator/structs.ml | 9 +
gobject/Makefile.inc | 8 +-
java/Makefile.inc | 1 +
java/com/redhat/et/libguestfs/.gitignore | 1 +
lib/MAX_PROC_NR | 2 +-
lib/Makefile.am | 1 +
lib/yara.c | 127 +++++++++++++
m4/guestfs_daemon.m4 | 14 ++
tests/yara/Makefile.am | 26 +++
tests/yara/test-yara-scan.sh | 72 ++++++++
19 files changed, 684 insertions(+), 35 deletions(-)
create mode 100644 daemon/yara.c
create mode 100644 lib/yara.c
create mode 100644 tests/yara/Makefile.am
create mode 100755 tests/yara/test-yara-scan.sh
--
2.11.0
8 years, 1 month
[PATCH 0/8] Miscellaneous cleanups to Windows registry code.
by Richard W.M. Jones
A very miscellaneous set of cleanups to how we handle the Windows
registry in virt-v2v, firstboot, and inspection code. This should all
be straightforward non-controversial refactoring. Some highlights:
- Add a new mllib Registry module containing various utility
functions that are currently scattered all around.
- Only compute the software/system hive paths once during inspection,
and make those paths available to the tools through new APIs.
- Simplify parameter passing inside virt-v2v so we pass around fewer
long lists of parameters.
Rich.
8 years, 1 month
