similar to: [PATCH] lib: allow to specify physical/logical block size for disks

From: Nikolay Ivanets <stenavin@gmail.com> Nowadays there are hard drives and operating systems which support "4K native" sector size. In this mode physical and logical block size exposed to the operating system is equal to 4096 bytes. GPT partition table (as a known example) being created in this mode will place GPT header at LBA1 which is 4096 bytes. libguetfs is unable to

On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > From: Nikolay Ivanets <stenavin@gmail.com> > > I faced with situation where libguestfs cannot recognize partitions on a > disk image which was partitioned on a system with "4K native" sector > size support. > > In order to fix the issue we need to allow users to specify desired > physical

From: Nikolay Ivanets <stenavin@gmail.com> I faced with situation where libguestfs cannot recognize partitions on a disk image which was partitioned on a system with "4K native" sector size support. In order to fix the issue we need to allow users to specify desired physical and/or logical block size per drive basis. It is definitely not a complete patch but rather a way to

Parse the query string from URLs, and pass it as new add_drive optarg; use it when building the file= URL for qemu. Accept query string only for http and https protocols, for now. --- Possibly it looks like an ad-hoc solution for http(s), although I'm not sure how it could possibly be generalized somehow (maybe "extra params" which would be the query string for http(s)?).

пн, 10 лют. 2020 о 10:53 Richard W.M. Jones <rjones@redhat.com> пише: > > On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > > From: Nikolay Ivanets <stenavin@gmail.com> > > > > I faced with situation where libguestfs cannot recognize partitions on a > > disk image which was partitioned on a system with "4K native" sector > >

Allow `launch` call to accept an optional argument, called `blocksize`. Example: $ guestfish --listen -a raw.img $ guestfish --remote -- launch blocksize:4096 The actual qemu command is: [...] -device virtio-scsi-ccw,id=scsi -drive file=raw.img,cache=writeback,id=hd0,if=none -device scsi-hd,drive=hd0,physical_block_size=4096,logical_block_size=4096 [...] Signed-off-by: Tuan Hoang

Add a new launch command for direct backend, which allows specifying the blocksize to the disks. The name is `launch_blocksize`, accompanied alias is `run-blocksize`. Example: $ guestfish --listen -a raw.img $ guestfish --remote -- launch_blocksize 4096 The actual qemu command is: [...] -device virtio-scsi-ccw,id=scsi -drive file=raw.img,cache=writeback,id=hd0,if=none -device

Move the list_filesystems API into the daemon, reimplementing it in OCaml. Since this API makes many other API calls, it runs a lot faster in the daemon. --- daemon/Makefile.am | 2 + daemon/ldm.ml | 3 + daemon/ldm.mli | 2 + daemon/listfs.ml | 156 +++++++++++++++++++++++++++++ daemon/listfs.mli | 19 ++++ daemon/lvm.ml | 3 +

Previously we had lots of types like String, Device, StringList, DeviceList, etc. where Device was just a String with magical properties (but only inside the daemon), and DeviceList was just a list of Device strings. Replace these with some simple top-level types: String StringList and move the magic into a subtype. The change is mechanical, for example: old

When --blocksize <val> is provided, qemu command line would add physical_block_size=<val>,physical_logical_size=<val> to -device directive. Example: qemu-kvm \ -drive file=raw.img,cache=writeback,id=hd0,if=none \ -device scsi-hd,drive=hd0,physical_block_size=4096,logical_block_size=4096 \ Signed-off-by: Tuan Hoang <tmhoang@linux.ibm.com> --- fish/fish.c |

пн, 10 лют. 2020 о 15:48 Kevin Wolf <kwolf@redhat.com> пише: > > Am 10.02.2020 um 12:43 hat Richard W.M. Jones geschrieben: > > On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > > > From: Nikolay Ivanets <stenavin@gmail.com> > > > > > > I faced with situation where libguestfs cannot recognize partitions on a > > > disk

From: "Richard W.M. Jones" <rjones@redhat.com> We were dropping the add_drive copyonread flag when using the libvirt backend. This resulted in significant performance degradation (2x-3x slower) when running virt-v2v against VMware servers. Thanks: Kun Wei. --- lib/launch-libvirt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/launch-libvirt.c

On Mon, Feb 10, 2020 at 02:28:08PM +0200, Nikolay Ivanets wrote: > пн, 10 лют. 2020 о 13:43 Richard W.M. Jones <rjones@redhat.com> пише: > > > > On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > > > From: Nikolay Ivanets <stenavin@gmail.com> > > > > > > I faced with situation where libguestfs cannot recognize partitions on a

In some places when generating XML output in C code we use some clever macros: start_element ("memory") { attribute ("unit", "MiB"); string ("%d", g->memsize); } end_element (); This commit which is mostly refactoring moves the repeated definitions of these macros into a common header file. I also took this opportunity to change / clean up

пн, 10 лют. 2020 о 13:43 Richard W.M. Jones <rjones@redhat.com> пише: > > On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > > From: Nikolay Ivanets <stenavin@gmail.com> > > > > I faced with situation where libguestfs cannot recognize partitions on a > > disk image which was partitioned on a system with "4K native" sector > >

Am 10.02.2020 um 12:43 hat Richard W.M. Jones geschrieben: > On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > > From: Nikolay Ivanets <stenavin@gmail.com> > > > > I faced with situation where libguestfs cannot recognize partitions on a > > disk image which was partitioned on a system with "4K native" sector > > size support. >

On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > From: Nikolay Ivanets <stenavin@gmail.com> > > I faced with situation where libguestfs cannot recognize partitions on a > disk image which was partitioned on a system with "4K native" sector > size support. Do you have a small test case for this? > In order to fix the issue we need to allow users

On Mon, Feb 10, 2020 at 02:22:01PM +0200, Nikolay Ivanets wrote: > Here are what they do stand for: > physical_block_size: The physical block size the disk will report to > the guest OS. For Linux this would be the value returned by the > BLKPBSZGET ioctl and describes the disk's hardware sector size which > can be relevant for the alignment of disk data. We don't have an

New api mke2fs for full configuration of filesystem. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/ext2.c | 452 +++++++++++++++++++++++++++++++++++++++++ generator/generator_actions.ml | 18 ++ gobject/Makefile.inc | 6 +- src/MAX_PROC_NR | 2 +- 4 files changed, 475 insertions(+), 3 deletions(-) diff --git

Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index c28905d..23bd708 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -60,19 +60,9 @@ let rec main () = let overlays = create_overlays source.s_disks in let targets = init_targets overlays source