similar to: [PATCH] v2v: rework free space check in guest mountpoints

Enough free space in a filesystem does not imply available inodes to create/modify files on that filesystem. Hence, require at least 100 available inodes on filesystems that can provide inode counts. Related to: RHBZ#1764569 --- docs/virt-v2v.pod | 3 +++ v2v/v2v.ml | 13 +++++++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/docs/virt-v2v.pod b/docs/virt-v2v.pod

Enough free space in a filesystem does not imply available inodes to create/modify files on that filesystem. Hence, require at least 100 available inodes on filesystems that can provide inode counts. --- v2v/v2v.ml | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index 03590c9e..b5b2da08 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -375,6

On Mon, Nov 06, 2017 at 03:45:14PM +0100, Pino Toscano wrote: > - move the space needed by mountpoint mapping to an own function, > outside of the checking loop > - remove the minimum limit of 100M on partitions, since existing > partitions that we check (e.g. /boot) may be smaller than that > - in case /boot is not on a separate mountpoint, enforce the space check > on the

Factor the size checks out to separate functions. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 53 ++++++++++++++++++++++++++++------------------------- 1 file changed, 28 insertions(+), 25 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index 4257b8d..a2b6f52 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -80,32 +80,9 @@ let rec main () = message

This series is a second attempt to add a mode of virt-v2v operation where it leaves the config and disk image conversion, rollback on errors, registering with the destination hypervisor, etc. to a third-party toolset, and performs only tuning of the guest OS to run in the KVM-based hypervisor. The first 14 patches are just refactoring and rearrangement of the code, factoring the implementation

This option prints the estimated size of the data that will be copied from the source disk. For interest, the test prints: 3747840 ../test-data/phony-guests/windows.img Estimate: 3710976 --- v2v/Makefile.am | 2 ++ v2v/cmdline.ml | 17 ++++++++++-- v2v/cmdline.mli | 2 ++ v2v/test-v2v-print-estimate.sh | 47 +++++++++++++++++++++++++++++++++

This series is an attempt to add a mode of virt-v2v operation where it leaves the config and disk image conversion, rollback on errors, registering with the destination hypervisor, etc. to a third-party toolset, and performs only tuning of the guest OS to run in the KVM-based hypervisor. Roman Kagan (3): v2v: add --in-place mode v2v: document --in-place v2v: add test for --in-place ---

NFS server (b39): bash-3.00# zfs get quota nfs-s5-s8/d5201 nfs-s5-p0/d5110 NAME PROPERTY VALUE SOURCE nfs-s5-p0/d5110 quota 600G local nfs-s5-s8/d5201 quota 600G local bash-3.00# bash-3.00# df -h | egrep "d5201|d5110" nfs-s5-p0/d5110 600G 527G 73G 88% /nfs-s5-p0/d5110

On Tue, Aug 14, 2018 at 8:29 PM Richard W.M. Jones <rjones@redhat.com> wrote: > This option prints the estimated size of the data that will be copied > from the source disk. > > For interest, the test prints: > > 3747840 ../test-data/phony-guests/windows.img > Estimate: 3710976 > Why not use qemu-img measure on the overlay? It gives a conservative estimate that

Here are 3 patches to avoid undesired aborts of mkfs.btrfs. These are based on top of Chris''s btrfs-progs.git: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git Thanks, H.Seto Hidetoshi Seto (3): btrfs-progs: error if device for mkfs is too small btrfs-progs: error if device have no space to make primary chunks btrfs-progs: calculate available

hi guys,   happy new year!!!  I encountered  a problem when we used virt-df command to display my guest disks useage. the virt-df command from pkg libguestfs-tools-c-1.36.3-6.el7_4.3.x86_64,version is  virt-df --version : virt-df 1.36.3rhel=7,release=6.el7_4.3,libvirt the output in guest with the method referred in http://libguestfs.org/virt-df.1.html#STATVFS NUMBERS is:

hi Jones, Thanks for your reply. At 2018-01-04 19:41:27, "Richard W.M. Jones" <rjones@redhat.com> wrote: >On Thu, Jan 04, 2018 at 12:58:40PM +0800, Chen Fan wrote: >[In guest] >> python -c 'import os; s = os.statvfs ("/"); print s' >> posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5886149, >> f_bfree=4802342, f_bavail=4802342,

This option prints the estimated size of the data that will be copied from the source disk. Currently this overestimates by the size of the qcow2 header, but for real disk images that doesn't matter much. For example: $ virt-builder fedora-27 $ virt-v2v -i disk fedora-27.img -o null --machine-readable --print-estimate [...] virt-v2v: This guest has virtio drivers installed. [ 44.0] Mapping

In this mode, converting of the VM configuration, setting up the rollback path for error cases, transforming the VM storage and so on is taken care of by a third-party toolset, and virt-v2v is only supposed to tune up the guest OS directly inside the source VM, to enable it to boot and run under the input hypervisor. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/cmdline.ml | 7

Per my previous email: https://www.redhat.com/archives/libguestfs/2017-September/msg00203.html I'd like to talk about requiring a more modern version of the OCaml compiler. These commits show some of the code changes which would be possible with OCaml >= 3.12 [which it turns out we already require by accident] and also with OCaml >= 4.02. The latter is my favoured option. Rich.

[Jim, as coreutils developer, this might interest you] In libguestfs we run some quite detailed checks of the output of the statvfs system call for our tool "virt-df". I noticed that the output of virt-df changed slightly. Narrowing it down, the difference only happens between: Fedora kernel 3.2.0-0.rc0.git4.1.fc17 (3rd Nov) Fedora kernel 3.2.0-0.rc1.git2.1.fc17 (11th Nov) With

v2 -> v3: - Drop gnulib fallback.

It started out as "this'll be just a simple fix ..." and turned into something a bit over-engineered in the end. Here it is anyway. Rich.

v1 -> v2: - Removed the f_type field from StatVFS.statvfs structure. - New function StatVFS.filesystem_is_remote, written in C. [Thinking about it, this should probably be called ?is_network_filesystem?, but I can change that before pushing]. - Use statvfs instead of fstatvfs, and statfs instead of fstatfs. - Rejigged the comments in builder/builder.ml to make them simpler

If you have a struct containing ?field?, eg: type t = { field : int } then previously to pattern-match on this type, eg. in function parameters, you had to write: let f { field = field } = (* ... use field ... *) In OCaml >= 3.12 it is possible to abbreviate cases where the field being matched and the variable being bound have the same name, so now you can just write: let f {