similar to: [PATCH v3 RESEND] direct, fish: add blocksize as optional argument for launch command

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

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 |

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

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

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

пн, 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

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

пн, 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 > >

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

пн, 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 > >

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

On Tue, 2020-07-21 at 11:05 +0000, Damien Le Moal wrote: > On 2020/07/21 19:53, Maxim Levitsky wrote: > > Kernel block layer has never supported logical block > > sizes less that SECTOR_SIZE nor larger that PAGE_SIZE. > > > > Some drivers have runtime configurable block size, > > so it makes sense to have common helper for that. > > ...common helper to

Kernel block layer has never supported logical block sizes less that SECTOR_SIZE nor larger that PAGE_SIZE. Some drivers have runtime configurable block size, so it makes sense to have common helper for that. Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com> --- block/blk-settings.c | 18 ++++++++++++++++++ include/linux/blkdev.h | 1 + 2 files changed, 19 insertions(+) diff

I think performance is not just about your xml, the host system will have a bigger impact. Maybe you can see this link: Https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html-single/virtualization_tuning_and_optimization_guide/index >Date: Wed, 8 Aug 2018 17:35:11 +0000 >From: Matt Schumacher <matt.s@aptalaska.com> >To: "libvirt-users@redhat.com"

List, I have a number of Windows 2016 servers I am deploying, but I’m having some I/O performance issues. I have done all of the obvious things like virtio drivers, but am finding there is more performance to be found with hyper-v extensions, how we virtualize the hardware clock, and iothreads. I’m using ZVOLs to back the VM, and I’m using 4k block sizes, which seems to offer the best 4k random

Ancient qemu 1.5 (in RHEL 7) does not understand the file.file.filename= and file.driver= parameters. Go back to using the old-style file= and format= parameters when we're not trying to set the file.backing.file.locking=off parameter. Fixes commit 9fe592808ccfd9ed184b88ca9c6cad2e1798dee3. Thanks: Yongkui Guo, Václav Kadlčík. --- lib/launch-direct.c | 31 +++++++++++++++++++++---------- 1

On Tuesday, 12 September 2017 14:29:16 CEST Richard W.M. Jones wrote: > @@ -255,11 +256,13 @@ add_drive_standard_params (guestfs_h *g, struct backend_direct_data *data, > } > else { > /* Writable qcow2 overlay on top of read-only drive. */ > - append_list_format ("file=%s", drv->overlay); > + append_list_format ("file.file.filename=%s",

--- lib/launch-direct.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index 9f85013f9..00cb25077 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -66,6 +66,7 @@ struct backend_direct_data { pid_t recoverypid; /* Recovery process PID. */ struct version qemu_version; /* qemu version (0 if