similar to: [v2v PATCH v2] v2v: require 100 available inodes on each filesystem

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

- 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 root mountpoint instead, since it is where /boot is in that case --- v2v/v2v.ml | 55

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 +++++++++++++++++++++++++++++++++

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

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

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 {

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 ---

Opening the source VM and amending the properties in its internal representation in accordance with command-line options fit nicely into two isolated functions. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 71 +++++++++++++++++++++++++++++++++----------------------------- 1 file changed, 38 insertions(+), 33 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index

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.

On 11/27/19 11:00 AM, Pino Toscano wrote: In the subject: s/availabe/available/ also, is it necessary to stick RHBZ#... in the subject, or is that a better fit in the commit body? > 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.

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

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,

[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

common/mlutils: Unix_utils.StatVFS.statvfs: This commit implements a full-featured binding for the statvfs(3) function. We then use this to reimplement the daemon statvfs API in OCaml. Note that the Gnulib fallback is fixed in this commit. It previously referenced non-existent field names in the fs_usage struct. --- common/mlutils/unix_utils-c.c | 138 ++++++++++++++++++++++++++++---