similar to: Standalone guestfs

On Sat, Jun 01, 2013 at 02:27:50PM +0000, Gabriel de Perthuis wrote: > Hello, > As I understand it guestfs appliances normally work as servers > and run high-level commands from some external channel. This is the normal architecture when you're using libguestfs to access a VM or disk image: http://libguestfs.org/guestfs.3.html#architecture > But it might be possible to bundle

On Sat, 01 Jun 2013 20:54:15 +0100, Richard W.M. Jones wrote: > On Sat, Jun 01, 2013 at 02:27:50PM +0000, Gabriel de Perthuis wrote: >> Hello, >> As I understand it guestfs appliances normally work as servers >> and run high-level commands from some external channel. > > This is the normal architecture when you're using libguestfs to access > a VM or disk image:

On Sat, Jun 01, 2013 at 10:05:20PM +0200, Gabriel wrote: > On Sat, 01 Jun 2013 20:54:15 +0100, Richard W.M. Jones wrote: > > On Sat, Jun 01, 2013 at 02:27:50PM +0000, Gabriel de Perthuis wrote: > >> Hello, > >> As I understand it guestfs appliances normally work as servers > >> and run high-level commands from some external channel. > > > > This is

If we're given an ISO image as the source of virtio windows drivers, and the backend supports hot-adding drives, reuse the same guestfs handle that is open for accessing the guest being inspected, rather than creating a new one (which would run another virtual machine instance and is fairly resource-intensive). Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- changes since v1: -

What with the impending release and a now fixed bug nagging me, I''m testing puppet [2556] from subversion. There have been changes in packages, I used to have Package { provider => "aptitude", } in my default.pp, but that doesn''t work anymore, and changing package to type or removing the declaration doesn''t help. How do package providers work now?

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

Only do this if running as root and if the backend is set to libvirt. --- v2v/input_ova.ml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/v2v/input_ova.ml b/v2v/input_ova.ml index 4f848e2..bb9cb1b 100644 --- a/v2v/input_ova.ml +++ b/v2v/input_ova.ml @@ -104,6 +104,19 @@ object (* Exploded path must be absolute (RHBZ#1155121). *) let exploded = absolute_path exploded

Hi, I''ve observed a rather strange behaviour while trying to mount two identical copies of the same image to different mount points. Each modification to one image is also performed in the second one. Example: dd if=/dev/sda? of=image1 bs=1M cp image1 image2 mount -o loop image1 m1 mount -o loop image2 m2 touch m2/hello ls -la m1 //will now also include a file calles "hello"

Hi, On Wed, November 16, 2016 5:39 pm, Richard W.M. Jones wrote: > On Wed, Nov 16, 2016 at 05:30:55PM -0500, Derek Atkins wrote: >> Hi, >> >> On Wed, November 16, 2016 5:15 pm, Richard W.M. Jones wrote: >> > On Wed, Nov 16, 2016 at 05:09:56PM -0500, Derek Atkins wrote: >> > >> > I'll try to reproduce the issue here, but you can also do >>

I didn't see what are the main differences in http://libguestfs.org/guestfs.3.html#backend Specifically, I'm interested in what is faster (direct sounds faster to me), and if there are any major restrictions (networking?) Here's an example command we are running (sorry, Python'ish, but you'll get it): ['virt-sysprep', '--connect', 'qemu:///system',

Hey list, I wonder if it is possible to deduplicate read-only snapshots. Background: I''m using an bash/rsync script[1] to backup my whole system on a nightly basis to an attached USB3 drive into a scratch area, then take a snapshot of this area. I''d like to have these snapshots immutable, so they should be read-only. Since rsync won''t discover moved files but

Libvirt >= 2.1.0 now allows you to open files which have a "json:" QEMU pseudo-URL as backingfile, whereas previously it would fail hard in this case (RHBZ#1134878). When virt-v2v performs conversions from Xen (over SSH) or vCenter (over HTTPS) it uses these pseudo-URLs as backingfiles. We had to tell people to use LIBGUESTFS_BACKEND=direct to avoid libvirt in this situation. This

Le 18/11/2014 16:11, Richard W.M. Jones a écrit : > On Tue, Nov 18, 2014 at 03:06:44PM +0100, Nicolas Ecarnot wrote: > [...] >> Then I PXE-boot my source physical machine (well, at present, at >> test time, another VM but whatever), when getting the graphical >> prompt to connect to the conversion server, I get >> "Failed to start virt-v2v-server on remote

Updates commit f87f254b2bcda09713d908451f29512ec4286626. --- v2v/input_libvirt_xen_ssh.ml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/v2v/input_libvirt_xen_ssh.ml b/v2v/input_libvirt_xen_ssh.ml index a1b1dfa1e..545a8f5da 100644 --- a/v2v/input_libvirt_xen_ssh.ml +++ b/v2v/input_libvirt_xen_ssh.ml @@ -34,16 +34,16 @@ class input_libvirt_xen_ssh password

Use the common open_guestfs to open Guestfs handles, so we get debugging, tracing, and other common options set. --- v2v/convert_windows.ml | 4 +--- v2v/input_disk.ml | 2 +- v2v/input_libvirt_other.ml | 2 +- v2v/input_ova.ml | 2 +- v2v/output_glance.ml | 2 +- v2v/output_null.ml | 2 +- v2v/output_rhev.ml | 2 +- v2v/output_vdsm.ml | 2 +-

Greetings I am trying to create quick fedora20 vm's and using virt-builder for it. Currently when i run virt-builder on Fedora 21 it fails with below errors: <snip> [juno@dhcp207-208 ~]$ virt-builder fedora-20 --cache ~/.cache/virt-builder [ 1.0] Downloading: http://libguestfs.org/download/builder/fedora-20.xz [ 1.0] Planning how to build this image [ 1.0] Uncompressing [ 9.0]

Hi, On Wed, November 16, 2016 5:15 pm, Richard W.M. Jones wrote: > On Wed, Nov 16, 2016 at 05:09:56PM -0500, Derek Atkins wrote: > > I'll try to reproduce the issue here, but you can also do > the following command directly on the guest disk image if you > want to test something: > > time LIBGUESTFS_BACKEND=direct guestfish --ro -a fc21-64.qcow2 -i > selinux-relabel

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]

On 16.09.14 15:09, Richard W.M. Jones wrote: > On Tue, Sep 16, 2014 at 05:06:57PM +0300, Shahar Havivi wrote: > > I am using upstream qemu while using this local variables: > > export PATH=/home/shahar/git/qemu:$PATH > > export LIBGUESTFS_HV=/home/shahar/git/qemu/x86_64-softmmu/qemu-system-x86_64 > > > > Is that sufficient? > > Yup, upstream qemu should

On Tue, Mar 14, 2023 at 04:06:18PM +0200, Andrey Drobyshev wrote: > Speaking of "make check": could you point out, for future reference, > which particular sub-target you're referring to here? I can see these: > check-am, check-recursive, check-slow, check-TESTS, check-valgrind. And > none of them seems to refer to checking docs integrity. Yet running > entire