similar to: Another possible bug in the preview version of virt-v2v for RHEL/CentOS 7.1

Hi, Thank you Richard for your work, but I have also like Jeff Forbes a new issue : libguestfs: trace: hivex_node_set_value = 0 libguestfs: trace: upload "/usr/share/virtio-win/drivers/amd64/Win2008/viostor.sys" "/Windows/Drivers/VirtIO" libguestfs: trace: upload = -1 (error) libguestfs: trace: hivex_close libguestfs: trace: hivex_close = 0 virt-v2v: error: libguestfs error:

Hi Thank you for your quick response, do you know when the build 1.27.53 will be available ? Alain Alain VONDRA Chargé d'exploitation des Systèmes d'Information Direction Administrative et Financière +33 1 44 39 77 76 UNICEF France 3 rue Duguay Trouin 75006 PARIS www.unicef.fr -----Message d'origine----- De : Richard W.M. Jones [mailto:rjones@redhat.com] Envoyé : mardi 23

Hi, I am running virt-v2v under CentOS 7, I use the new libguestfs-1.27.48-1.1, and when I try to import my Windows 2008 (running perfectly using virt-manager) in my cloud oVirt, I encounter this issue : ........ libguestfs: trace: mkdir_p = 0 libguestfs: trace: case_sensitive_path "/Windows/system32/drivers/viostor.sys" libguestfs: trace: case_sensitive_path =

[This email is either empty or too large to be displayed at this time]

Hi Rich, While I was looking at hivex today I ran coverity on it. It spotted one problem but missed a similar one nearby. The following are from Hivex.xs: (generated by generator.ml) void node_set_values (h, node, values) hive_h *h; int node; pl_set_values values = unpack_pl_set_values (ST(2)); PREINIT: int r; PPCODE: r = hivex_node_set_values (h, node,

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

--- lib/hivex.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lib/hivex.c b/lib/hivex.c index 13d7556..8a774de 100644 --- a/lib/hivex.c +++ b/lib/hivex.c @@ -543,6 +543,9 @@ hivex_close (hive_h *h) free (h->filename); free (h); + if (h->msglvl >= 1) + fprintf (stderr, "hivex_close\n"); + return r; } -- 1.7.2.1

As noted by Pino in another patch, the logic passes the first member of the struct which happens to be the right address to the callback function. This will break the callback if order of the members of the struct will change. As the callback is using the entire struct, better to pass the pointer to the struct itself. Signed-off-by: Matteo Cafasso <noxdafox@gmail.com> --- daemon/upload.c

I'm not entirely sure the generator/generator.ml changes are as correct as they could be. I'm not very familiar with Caml. The hivex_node_set_value call builds up a list of hive_set_values by walking the existing values at the node, adding or replacing the passed hive_set_value as necessary, then shoving the list at hivex_node_set_values. Not included: Perl or OCaml binding glue.

Parallels proprietary hypervisor uses RDPMC as the hypercall instruction. As this instruction is supported since early P6 family, the drivers didn't even bother to check for the presence of the corresponding feature in CPUID. In QEMU/KVM, however, this instruction triggers #GP unless the VM is run with PMU (performance monitoring unit) enabled, which is often not the case (due to its impact

Round 3 -- this time with working OCaml bindings. (I'm not on the list, please copy me on replies, thanks.) --- generator/generator.ml | 77 ++++++++++++++++++++++++++++++++++++++++- lib/hivex.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++ perl/t/201-setvalue.t | 54 ++++++++++++++++++++++++++++ 3 files changed, 219 insertions(+), 2 deletions(-) create mode 100644

The error message: hivex_close: do_hivex_close: you must call 'hivex-open' first to initialize the hivex handle This is the process flow: g = guestfs_create (); guestfs_add_drive_opts (g, diskFile,GUESTFS_ADD_DRIVE_OPTS_FORMAT, "raw",-1); guestfs_launch (g) char **roots = guestfs_inspect_os (g); guestfs_inspect_os returns NULL, guestfs_last_error(g) returns

2015-05-27 15:21 GMT+03:00 Richard W.M. Jones <rjones@redhat.com>: > On Wed, May 27, 2015 at 09:38:38AM +0300, NoxDaFox wrote: > > * RuntimeError: file receive cancelled by daemon - On r = > > libguestfsmod.checksums_out (self._o, csumtype, directory, sumsfile) > > * RuntimeError: hivex_close: do_hivex_close: you must call 'hivex-open' > > first to

On Tue, Apr 05, 2016 at 01:47:29PM +0200, Cédric Bosdonnat wrote: > The output of the first boot scripts is available in the guest as > -F<C:\Program Files\Red Hat\Firstboot\log.txt>. > +F<C:\Program Files\Guestfs\Firstboot\log.txt>. Changing this path is fine, but let's split it into a separate patch. > + let services = ["rhsrvany.exe";

This adds most of the hivex APIs directly to the libguestfs API, so that you can read and write Windows Registry hive files from libguestfs without needing to download and upload hive files from the guest. This is analogous to how Augeas APIs are exposed already (guestfs_aug_*) Also, inspection is now done using the new APIs, which fixes the following bug:

Greetings, I am suffering of several weird errors which show randomly and make me suspect some concurrency issue. Libguestfs version is 1.28.1, linux kernel 3.16, libvirt 1.2.9 and qemu 2.1. What I'm trying to do is comparing the disk state at two different point of a guest execution. Disk snapshots are taken through libvirt in different moments (I am aware of caching issue), from such

There's a new syntax check rule from gnulib. It requires that you write e.g., exit (EXIT_SUCCESS), not exit (0). And the same for 1/EXIT_FAILURE and any other constants. There were a lot of violations, including a few false positives, so I started with the exemptions (see the .x-sc file below). Then I converted the vast majority automatically, with this: maint: use EXIT_SUCCESS and

Hi, I've made several attempts to boot syslinux from the harddisk. I have a win 98 startdiskette with syslinux and copybs. I strictly follow the procedure in the syslinux documentation. Yet, the result of the boot is not that linux is starting. Instead, the Microsoft windows screen flashes for a couple of seconds and is then replaced by a Dos prompt. Syslinux is V2.04. The PC is an IBM Aptiva

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

[This email is either empty or too large to be displayed at this time]