search for: guestfs_pread

As part of a new virt-v2v feature, I've been thinking about how to write data to an arbitrary block device in the appliance. I need to be able to write arbitrary chunks of data to specific places on the device. This will need a new API, as guestfs_pread can't open a block device. While I'm at it, I'd like to create a new family of APIs which operate on a file handle: int guestfs_open_device(g, path); Open a block device. Return a handle. int guestfs_open_file(g, path); Open a file from the guest's filesystem. Return a han...

...pwrite(2)> system call, and like -that system call it may not write the full data requested. The -return value is the number of bytes that were actually written -to the file. This could even be 0, although short writes are -unlikely for regular files in ordinary circumstances. - See also C<guestfs_pread>."); ("resize2fs_size", (RErr, [Device "device"; Int64 "size"]), 248, [], -- 1.7.2.2

Thanks a lot. I was trying to copy on local disk and guestfs_download () solved my problem. Now I am trying to modify source code of guestfs_download () to extract file in memory. Can you guide me what should i do to achieve that. Mohsin On Fri, Feb 10, 2017 at 2:13 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Thu, Feb 09, 2017 at 03:24:53PM +0500, MUHAMMAD MOHSIN wrote:

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

https://bugzilla.redhat.com/show_bug.cgi?id=755729 This bug reports that the error message printed by the resize2fs API calls (which comes directly from the resize2fs command) says: Please run 'e2fsck -f /dev/vda1' first. That command is not possible from guestfish (where it would be 'e2fsck-f' or 'e2fsck ... forceall:true'). Fixing that bug caused this bug:

Nothing new in the virt-tail command itself, but the second commit includes a simple test. Rich.

...0) { /* grew a lot */ + goto show_tail; + } + else if (stat->st_size > file[i].size) { /* grew a bit */ + int count = stat->st_size - file[i].size; + size_t r; + guestfs_push_error_handler (g, NULL, NULL); + content = guestfs_pread (g, argv[i], count, file[i].size, &r); + guestfs_pop_error_handler (g); + if (content) { + size_t j; + for (j = 0; j < r; ++j) + putchar (content[j]); + } + } + else if (stat->st_size <= file[i]...

This adds a new tool which does a follow operation (ie. tail -f) on one or more log/text files inside the guest. I've only done limited testing, but it works for me for tailing various long-running builds inside guests which I'm doing at the moment. There are no tests at present. Rich.

...0) { /* grew a lot */ + goto show_tail; + } + else if (stat->st_size > file[i].size) { /* grew a bit */ + int count = stat->st_size - file[i].size; + size_t r; + guestfs_push_error_handler (g, NULL, NULL); + content = guestfs_pread (g, filename, count, file[i].size, &r); + guestfs_pop_error_handler (g); + if (content) { + size_t j; + for (j = 0; j < r; ++j) + putchar (content[j]); + } + } + else if (stat->st_size <= file[i...

...goto show_tail; > + } > + else if (stat->st_size > file[i].size) { /* grew a bit */ > + int count = stat->st_size - file[i].size; > + size_t r; > + guestfs_push_error_handler (g, NULL, NULL); > + content = guestfs_pread (g, argv[i], count, file[i].size, &r); > + guestfs_pop_error_handler (g); > + if (content) { > + size_t j; > + for (j = 0; j < r; ++j) > + putchar (content[j]); > + } > + } > +...

Since v2: - Fix the things that Pino mentioned, except the recursion. - Implement Windows support. For Windows support to be sane, I had to inline the add_and_mount code. Rich.

This version doesn't crash or cause hung processes or stuck mountpoints, so that's an improvement. Rich.

This is a follow-up to the other generator changes in: https://www.redhat.com/archives/libguestfs/2017-February/msg00217.html Rich.

This patch is just for review. It enables FUSE support in the API via two new calls, 'guestfs_mount_local' and 'guestfs_umount_local'. FUSE turns out to be very easy to deadlock (necessitating that the machine be rebooted). Running the test from the third patch is usually an effective way to demonstrate this. However I have not yet managed to produce a simple reproducer that

This changes the proposed API slightly. Previously 'mount-local' generating a 'mounted' event when the filesystem was ready, and from the 'mounted' event you had to effectively do a fork. Now, 'mount-local' just initializes the mountpoint and you have to call 'mount-local-run' to enter the FUSE main loop. Between these calls you can do a fork or whatever

...quot;], []; + style = RBufferOut "content", [String (Pathname, "path"); Int "count"; Int64 "offset"], []; protocol_limit_warning = true; tests = [ InitISOFS, Always, TestResult ( @@ -5082,7 +5082,7 @@ See also C<guestfs_pwrite>, C<guestfs_pread_device>." }; { defaults with name = "part_init"; added = (1, 0, 78); - style = RErr, [Device "device"; String "parttype"], []; + style = RErr, [String (Device, "device"); String (PlainString, "parttype")], []; tests = [...

Very large but mechanical change to the generator. Rich.

If we want to permit more than 255 drives to be added, then we will have to add the disks to the same virtio-scsi target using different unit (LUN) numbers. Unfortunately SCSI LUN enumeration in the Linux is not deterministic (eg. two disks with target=0, lun=[0,1] can be enumerated as /dev/sda or /dev/sdb randomly). Dealing with that will require some very complex device name translation on the

Split up the huge generator/actions.ml into several smaller files. Rich.

https://bugzilla.redhat.com/show_bug.cgi?id=1477623 The first two patches are cleanups. The third patch changes the way that we handle Device and Dev_or_Path parameters so that a parameter marked as such can really only contain a block device name (and not, for instance, a chardev). Using a chardev here caused hangs in the API. The next two patches fix API usage to conform to this new stricter