similar to: [PATCH] Generic partition creation interface.

This patch series allows you to shrink various objects, as requested in the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=585221 # resize2fs https://bugzilla.redhat.com/show_bug.cgi?id=585222 # pvresize https://bugzilla.redhat.com/show_bug.cgi?id=585223 # ntfsresize The first patch provides a consistent way to specify numbers with suffixes to guestfish, eg: truncate-size /foo

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

Back to replica 3 w/o arbiter. Two fio jobs running (direct=1 and direct=0), rebooting one node... and VM dmesg looks like: [ 483.862664] blk_update_request: I/O error, dev vda, sector 23125016 [ 483.898034] blk_update_request: I/O error, dev vda, sector 2161832 [ 483.901103] blk_update_request: I/O error, dev vda, sector 2161832 [ 483.904045] Aborting journal on device vda1-8. [ 483.906959]

Il 05 Mag 2017 19:30, "Nikolaos Milas" <nmilas at noa.gr> ha scritto: On 5/5/2017 3:45 ??, Gianluca Cecchi wrote: BTW: see also this paragraph in the provided RH EL link: > 24.7.3. Resetting and Reinstalling GRUB 2 > > But i think is not your problem.... > Yes, I have done that, without change in behavior. Also, after changing partitions flag does your fdisk

trace: >>> g.inspect_os() libguestfs: trace: inspect_os libguestfs: trace: umount_all libguestfs: trace: umount_all = 0 libguestfs: trace: list_devices libguestfs: trace: list_devices = ["/dev/vda"] libguestfs: trace: vfs_type "/dev/vda" libguestfs: trace: vfs_type = "" libguestfs: trace: mount_ro "/dev/vda" "/" libguestfs: trace:

On 5/5/2017 3:45 ??, Gianluca Cecchi wrote: > BTW: see also this paragraph in the provided RH EL link: > 24.7.3. Resetting and Reinstalling GRUB 2 > > But i think is not your problem.... Yes, I have done that, without change in behavior. > Also, after changing partitions flag does your fdisk command reflect the > change? Yes. > Is the error during boot the same as the one

With 1.9.37 the following script worked fine, with 1.9.39 it fails. Any idea what the issue is? Olaf ... mount -o /dev/vda1 /sysroot/ [ 1.396411] EXT4-fs (vda1): mounting ext2 file system using the ext4 subsystem [ 1.533090] EXT4-fs (vda1): mounted filesystem without journal. Opts: (null) guestfsd: main_loop: proc 1 (mount) took 0.45 seconds libguestfs: recv_from_daemon: 40 bytes: 20 00

Dear colleagues, I am facing a problem that has been troubling me for last week and a half. Please if you are able to help or offer some guidance. I have a non-prod POC environment with 2 CentOS7 fully updated hypervisors and an NFS filer that serves as a VM image storage. The overall environment works exceptionally well. However, starting a few weeks ago I have been trying to implement virtlock

On Fri, May 5, 2017 at 2:38 PM, Nikolaos Milas <nmilas at noa.gr> wrote: > On 5/5/2017 3:15 ??, Gianluca Cecchi wrote: > > ... >> grub2-install /dev/vda >> ... >> Was this one of the command you already tried? >> > > Yes, I have tried that multiple times, both from Troubleshooting Mode > (booting using CentOS 7 Installation CD) and from within the

When mounting a subvolume by name, mountinfo shows the name of the subvolume. When mounting a subvolume using subvolid it does not. Seems like a problem when trying to determine what is mounted. -o subvol=<name> # cat /proc/self/mountinfo | grep vda 43 34 0:29 /home /home rw,relatime shared:29 - btrfs /dev/vda1 rw,seclabel,space_cache 44 34 0:29 /boot /boot rw,relatime shared:30 - btrfs

Hi, I am having a hard time rationalizing why virt-resize would be the cause of this issue, however it appears to definitely be the trigger, hence trying this list. My environment comprises Debian 10 hosts and guests, although this issue has also been witnessed on Debian 9 hosts running Debian9/10 guests. In all cases, stable versions of libvirt, qemu-kvm, libguestfs- tools, etc running on AMD64

When fetching a storage volume over SSH, we were detecting its size with a simple 'stat -c %s'. While this works fine for files, it won't return the correct size of a block device. This patch uses the output of 'blockdev --getsize64' for block devices, and stat as before for regular files. Fixes RHBZ#620698 --- lib/Sys/VirtV2V/Transfer/SSH.pm | 16 +++++++++++++++- 1 files

I posted this problem on IRC yesterday. Here are some logs. Recap on the problem: When I do inspect_os() (from the python api) or invoke virt-inspector, I get this error: libguestfs: error: internal_parse_mountable: internal_parse_mountable_stub: /dev/vg_nestedctos1/lv_root: No such file or directory I don't have this problem when I invoke it using the OS supplied binaries (version 1.14.8).

On 30.06.2016 19:41, Erwan Velu via Syslinux wrote: > The exisiting label= option offer to boot on a gpt partition that have > a particular label. > The existing guuid= option offer to boot on a disk or partition with a > particular label. > > This new option offer to boot the disk that have a partition which > have a given label. > The label is so just a way to detect a

On 15.07.2016 17:53, Ady Ady via Syslinux wrote: > >> On 30.06.2016 19:41, Erwan Velu via Syslinux wrote: >>> The exisiting label= option offer to boot on a gpt partition that have >>> a particular label. >>> The existing guuid= option offer to boot on a disk or partition with a >>> particular label. >>> >>> This new option offer to

Hello guys! I tried to shrink a partition when resizing an image using virt-resize. The numbers and result are weird. ================BEFORE================ ><fs> blockdev-getsize64 /dev/sdc 4294967296 ><fs> part-list /dev/sdc [0] = { part_num: 1 part_start: 65536 part_end: 2193555455 part_size: 2193489920 } [1] = { part_num: 2 part_start: 2193555456

> On 30.06.2016 19:41, Erwan Velu via Syslinux wrote: > > The exisiting label= option offer to boot on a gpt partition that have > > a particular label. > > The existing guuid= option offer to boot on a disk or partition with a > > particular label. > > > > This new option offer to boot the disk that have a partition which > > have a given label. >

Hello, I've noticed a strange delay while booting a CentOS 7 guest on a CentOS 7 host with slow disks (7200RPM) with write cache off. The guest and host are freshly installed Centos 7 (host was fully patched before guest install). Guest is installed on an lvm pool residing on an md raid1 with two SATA 7200 RPM drives with their write caches off. The delay is on mounting /boot, the dmesg

This requires changing the generator so it can handle passing optional arguments all thr way through to the daemon, changing the protocol (see previous patch set), and implementing the new mkfs-opts call. At the moment there is just an optional blocksize argument, thus mimicking what you can already do with 'mkfs-b'. But this change will allow us in future to encode much of the rest of

On Fri, Aug 05, 2016 at 02:46:11PM +0000, Andre Goree wrote: > > I seem to be having trouble using guestmount to mount a Fedora 24 disk that is using XFS.  This is the error messings I get when I try: > > root@cpdev-cn5:/var/lib/libvirt/images/base# guestmount --rw -a ${disk_path}/${disk_name} -m /dev/${target}1 /tmp/fedora-master/ > libguestfs: error: mount_options: /dev/vda1 on