[Libguestfs] running libguestfs as a service?

[T Johnson]

On Thu, May 5, 2011 at 10:59 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Thu, May 05, 2011 at 12:44:38PM -0400, T Johnson wrote:
>> I've been strapped for time to work on this lately, but have a couple
>> updates. I have been using the updated RHEL 6.1 packages, so
>> unfortunately that doesn't seem to solve the problem yet.
>>
>> I'm still having some trouble capturing all the output, but I have
>> manged to collect this verbose output after aborting a "stalled"
>> request:
>>
>> [   35.206396] end_request: I/O error, dev vda, sector 2048
>> [   35.207363] Buffer I/O error on device vda1, logical block 0
>> [   35.207384] lost page write due to I/O error on vda1
>> [   35.207384] Buffer I/O error on device vda1, logical block 1
>> [   35.207384] lost page write due to I/O error on vda1
>> [   35.207384] end_request: I/O error, dev vda, sector 1574912
>> [   35.207384] Buffer I/O error on device vda1, logical block 196608
>> [   35.207384] lost page write due to I/O error on vda1
>> [   35.207384] end_request: I/O error, dev vda, sector 1575624
>> [   35.207384] Buffer I/O error on device vda1, logical block 196697
>> [   35.207384] lost page write due to I/O error on vda1
>> check_for_daemon_cancellation_or_eof: 0x1786f80 g->state = 3, fd = 66
>> child_cleanup: 0x1786f80: child process died
>>
>> I should probably note that this is being done over NFS mounted
>> images. I'm fairly sure there aren't NFS problems though, as the NFS
>> mounts are quite stable and otherwise seem to respond just fine
>> against the same mounts at the same time this problem occurs.
>>
>> I'm hoping the above might trigger some ideas but I'm still working on
>> trying to figure out the lack of verbose data to stderr otherwise.
>
> There seem to be a number of different things going on, but I really
> don't have enough detail to be able to fix this.  This error seems to
> be unrelated to the Python issues you were having before.
>
> The I/O errors above would be because the underlying disk is somehow
> read-only to qemu.
>

By this you mean the uid the process is running as and not the actual
'qemu' uid, right? Just making sure..

> For NFS I guess this could be because of root_squash-ing.
>

Hmm, ok. I will keep plugging away and update the thread if I discover
something.

One thing that's curious is I've also played with just using
command-line `virt-X` and `guestfish` to upload new files to the same
images and haven't had the same write problems and/or process hangs.
Secondly, the changes *do* get written to the images so it's certainly
not a flat-out permission denied issue.

Anyway, thanks for the feedback.

TJ