similar to: getting guestfs_rsync_out to work

Richard- >>> Per this page >>> >>> https://rwmj.wordpress.com/2013/04/22/using-rsync-with-libguestfs/ >>> >>> We are trying to get the libguestfs API guestfs_rsync_out to work. We’ve tried combinations similar to: >>> >>> guestfs_rsync_out(g, “/HostShared”, “rsync://root@10.0.1.90:2999/backup/ -av”, -1) >>> >>>

On Sat, Feb 07, 2015 at 05:19:42PM -0600, Jeff Brower wrote: > All- > > Per this page > > https://rwmj.wordpress.com/2013/04/22/using-rsync-with-libguestfs/ > > We are trying to get the libguestfs API guestfs_rsync_out to work. We’ve tried combinations similar to: > > guestfs_rsync_out(g, “/HostShared”, “rsync://root@10.0.1.90:2999/backup/ -av”, -1) > >

Update: Using mount (read-only) and unmount commands in a script that loops continuously, we are able to see near instantaneous file modifications (less than 0.5 sec) performed on a Win7 live guest. We have to use the sync.exe utility (technet.microsoft.com/en-us/sysinternals/bb897438.aspx), otherwise changes are not visible for 10-20 sec. We tested sync.exe with our libguestfs test program

Richard- > On Sun, Feb 08, 2015 at 12:11:37PM -0600, Jeff Brower wrote: >> With continuous loop testing, what we found is that we have to shut >> down and re-launch the image handle to see changes on the Win7 live >> guest. Unfortunately image re-launch takes time, 3-5 sec (the image >> size is 50 GByte). I'm assuming this is because libguestfs makes an >>

Richard- > On Mon, Feb 09, 2015 at 08:01:31AM -0600, Jeff Brower wrote: >> Richard- >> >> > On Sun, Feb 08, 2015 at 12:11:37PM -0600, Jeff Brower wrote: >> >> With continuous loop testing, what we found is that we have to shut >> >> down and re-launch the image handle to see changes on the Win7 live >> >> guest. Unfortunately image

Richard- > On Mon, Feb 09, 2015 at 08:27:22AM -0600, Jeff Brower wrote: >> Yes we know that it doesn't know. We'd be ok to re-launch the image >> to pick up changes except for the time it takes (if we could get >> into 1 to 10 msec range it would be ok). > > There's no feasible way to start a Linux kernel in under about 1-2 > seconds. It just takes

On Mon, Feb 09, 2015 at 08:01:31AM -0600, Jeff Brower wrote: > Richard- > > > On Sun, Feb 08, 2015 at 12:11:37PM -0600, Jeff Brower wrote: > >> With continuous loop testing, what we found is that we have to shut > >> down and re-launch the image handle to see changes on the Win7 live > >> guest. Unfortunately image re-launch takes time, 3-5 sec (the image

On Sun, Feb 08, 2015 at 12:11:37PM -0600, Jeff Brower wrote: > With continuous loop testing, what we found is that we have to shut > down and re-launch the image handle to see changes on the Win7 live > guest. Unfortunately image re-launch takes time, 3-5 sec (the image > size is 50 GByte). I'm assuming this is because libguestfs makes an > internal copy of filesystem, and

On Mon, Feb 09, 2015 at 08:27:22AM -0600, Jeff Brower wrote: > Yes we know that it doesn't know. We'd be ok to re-launch the image > to pick up changes except for the time it takes (if we could get > into 1 to 10 msec range it would be ok). There's no feasible way to start a Linux kernel in under about 1-2 seconds. It just takes that long for the kernel to initialize

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

Add new api xfs_admin to change parameters of an XFS filesystem. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/xfs.c | 78 ++++++++++++++++++++++++++++++++++++++++++ generator/generator_actions.ml | 21 ++++++++++++ gobject/Makefile.inc | 6 ++-- guestfs-release-notes.txt | 1 + po/POTFILES | 1 + src/MAX_PROC_NR

An experimental series that adds support for rsync. Rich.

Add a new api xfs_repair for repairing an XFS filesystem. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/xfs.c | 116 +++++++++++++++++++++++++++++++++++++++++ generator/generator_actions.ml | 23 ++++++++ gobject/Makefile.inc | 6 ++- po/POTFILES | 1 + src/MAX_PROC_NR | 2 +- 5 files changed, 145

Hello to everybody here, We have a strange problem with ext3. df reports 28 of 30 GB to be used (rest may be slack) which it calls 100% used. But with du we can only find 13 GB, most of it actually in pretty large files (archives). Where are the other 17 GB gone? Thanks Michael -- Hostsharing eG / Boytinstr. 10 / D-22143 Hamburg phone+fax:+49/700/HOSTSHARI(ing) (= +49/700/46787427)

Thank you. The clipboard sharing working now. Do you have any idea for the mount issue? I suppose there is a way to share a specific directory between the guest and host like I did with vbox for example What exact modules needed for this function? The error message I've got this: mount -t 9p -o trans=virtio,version=9p2000.L hostshare /tmp/hostfiles mount: special device hostshare does not

Hi, I'm almost give up again because for a day I try to access my windows kvm guest from FC20 :) I've tried everything including virtio mapping mount -t 9p -o trans=virtio,version=9p2000.L hostshare /tmp/hostfiles where I get the following messages mount: special device hostshare does not exist --- --- to be honest clipboard sharing would be enough for me, so I googled why it is not

The spice-vdagent should be running in the guest. Have you installed the spice guest tools in your windows guest? Download them here: http://www.spice-space.org/download.html That should get clipboard sharing working. ----- Original Message ----- > From: "Laszlo Pal" <vlad@vlad.hu> > To: libvirt-users@redhat.com, virt-tools-list@redhat.com > Sent: Thursday, March 20,

Thank you. It is clear now, so it was user error and I should read more documentation :) Unfortunately drag and drop isn't working. Is there any prerequisite? My host is FC20 and guest is Win2k8 server Thank you Vlad On Thu 20 Mar 2014 05:42:40 PM CET, Jonathon Jongsma wrote: > ----- Original Message ----- >> From: "Laszlo Pal (private)" <vlad@vlad.hu> >>

Hi Is there some definitive guide for upload progress plugin ? We have in this mailing list a lot of testimonials, bug reports, bug fixes, but there are still people like me who cannot use it correctly. Here is my config: - mongrel 1.0RC and upload progress plugin 0.2.1 - a 6 mongrels cluster - config/mongrel_upload_progress.conf: uri "/", :handler =>

R-help, I have the following file I want to import to R (some lines removed) Calibrated CTD data for station:00280001 Calibrated:23/8 2001, Salinity Unsmoothed, Fluorescence Uncalibrated Maximum observed depth: 36 m QUAL has one digit for each of pressure, temp., sal. and fluor. QUAL=1:Uncal., QUAL=2:OK, QUAL=6:Interp., QUAL=9:No data