similar to: [PATCH] daemon: lvm: Pass --yes option to force pvresize (RHBZ#1460577).

Hi, I'm needing to expand a LUN on my EMC CX4-120 SAN. (Well I already had done it). On this LUN I had a PV of a cLVM VG. Know I need to run pvresize on it. Has anybody done this on a cLVM PV ? I'm trying to rescan the devices, but I can't "see" the new size. And, googling on it I can only find RHEL5.2 responses. Thanks in advance,

guestfsd calls many different tools. Keeping track of all of them is error prone. This patch introduces a new helper macro to put the command string into its own ELF section: GUESTFSD_EXT_CMD(C_variable, command_name); This syntax makes it still possible to grep for used command names. The actual usage of the collected list could be like this: objcopy -j .guestfsd_ext_cmds -O binary

guestfsd calls many different tools. Keeping track of all of them is error prone. This patch introduces a new helper macro to put the command string into its own ELF section: GUESTFS_EXT_CMD(C_variable, command_name); This syntax makes it still possible to grep for used command names. The actual usage of the collected list could be like this: objcopy -j .guestfs_ext_cmds -O binary

GUESTFSD_EXT_CMD was used by OpenSUSE to track which external commands are run by the daemon and package those commands into the appliance. It is no longer used by recent SUSE builds, so remove it. Thanks: Pino Toscano, Olaf Hering. --- daemon/9p.c | 3 +- daemon/available.c | 7 +-- daemon/base64.c | 6 +-- daemon/blkid.c | 10 ++---

GUESTFSD_EXT_CMD is used by OpenSUSE to track which external commands are run by the daemon and package those commands into the appliance. However because this uses linker trickery it won't work from OCaml code. Replace it with a [nearly] standard C mechanism. Files still have to declare the external commands they will use, eg: DECLARE_EXTERNAL_COMMANDS ("btrfs",

Hello, I have a CentOS VM with only one disk on a Xenserver. The disk has 2 partitions: /dev/xvda1 -> /boot /dev/xvda2 -> a physical volume for LVM I added 5GB to this disk via Xencenter to extend /dev/xvda2. Usually I just have to do "pvresize /dev/xvda" to have the additional space added to the disk. But for some reason it does not work for this disk. [root ~]# pvresize

I should have added the output of pvs: [root ~]# pvs PV VG Fmt Attr PSize PFree /dev/xvda2 cl_vm731611 lvm2 a-- 9.00g 0 PFree still show 0. It should show 5g. Also: [root ~]# pvdisplay /dev/xvda2 --- Physical volume --- PV Name /dev/xvda2 VG Name cl_vm731611 PV Size 9.00 GiB / not usable 2.00 MiB Allocatable

Hi. I added a disk to a hardware raid 5 array and now i want to expand the LVM physical volume. There are now 4 sas 146GB disks in the server. The virtual disk /dev/sdb from the raid controller has been resized successfully with the server management software osma. [root at srv1 ~]# fdisk -l /dev/sdb Disk /dev/sdb: 438.4 GB, 438489317376 bytes 255 heads, 63 sectors/track, 53309 cylinders

Hi, I was wondering if there was a way to extend (ie: grow) a PV that is part of a Volume Group? I currently have a partition on my HD that is being used as a PV for my Volume Group, but would like to make it larger. I have the space on my drive to extend my partition, but using standard tools (ex: gparted, Partition Magic, etc) would likely end up corrupting the data on in the Logical Volumes

Hello, Today a virtual server under my administration ran out of disk space, so I had to get extra space to it.. while it was running, because it's an important web server without any kind of HA/Load Balancing (don't do that, kids). So what happened, is that after another administrator had extended the disk from VMWare, I tried to extend it from the OS side. Everything went well,

The appliance has no LVM system ID set, which means that lvm commands will ignore VGs with a system ID set to anything. Since we want to work with them, pass --foreign at least when listing them to see them. See also lvmsystemid(7). --- daemon/lvm.c | 10 ++++++---- generator/daemon.ml | 1 + 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/daemon/lvm.c b/daemon/lvm.c

How do you resize the partition without loosing data? gparted does not support LVM. On Wed, Feb 22, 2017 at 8:37 AM, SysAdmin <admin at s-s.network> wrote: > Hi, > > you need to resize partition /dev/xvda2, afterwards resize pv. > > Regards, > Holger > > > -----Urspr?ngliche Nachricht----- > > Von: CentOS [mailto:centos-bounces at centos.org] Im Auftrag

When virtio-blk device is resized from host (using block_resize from QEMU) emit KOBJ_CHANGE uevent to notify guest about such change. This allows user to have custom udev rules which would take whatever action if such event occurs. As a proof of concept I've created simple udev rule that automatically resize filesystem on virtio-blk device. ACTION=="change", KERNEL=="vd*",

When virtio-blk device is resized from host (using block_resize from QEMU) emit KOBJ_CHANGE uevent to notify guest about such change. This allows user to have custom udev rules which would take whatever action if such event occurs. As a proof of concept I've created simple udev rule that automatically resize filesystem on virtio-blk device. ACTION=="change", KERNEL=="vd*",

It looks like older versions of lvm2 (recent enough to have selectors) do not recognize '1' (and '0') as boolean values. Switch to 'yes', which seems to be supported. Updates commit 7367945647e774aec4b93c3bf13181212d3c6430. --- daemon/lvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/lvm.c b/daemon/lvm.c index a270b13..c186a5a 100644 ---

Currently lvmetad is started in init, and thus using the system (= appliance) configuration of lvm. Later on, in the daemon, a local copy of the lvm configuration is setup, and set it for use using the LVM_SYSTEM_DIR environment variable: this means only the programmes executed by the daemon will use the local lvm configuration, and not lvmetad. Thus manually start lvmetad from the daemon, right

Hi All. Looking for some guidance/experience with LVM and pvmove. I have a LUN/PV being presented from a iscsi SAN. The LUN/PV is presented to 5 servers as a shared VG they all have LV's they use for data, they are all connected via iSCSI. As the SAN I am using is being replaced I need to move onto a new unit. My migration strategy at this time is to 1. Present a new LUN from the new SAN

lvm2 2.02.107 adds the -S/--select option used in lvs to filter out only public LVs (see RHBZ#1278878). To make this work again with versions of lvm2 older than that, only on old versions filter out thin layouts and compose the resulting device strings ourselves. The filtering done is much simplier than what "-S lv_role=public" will do, but should be good enough for our need. ---

lvm2 2.02.107 adds the -S/--select option used in lvs to filter out only public LVs (see RHBZ#1278878). To make this work again with versions of lvm2 older than that, only on old versions filter out thin layouts and compose the resulting device strings ourselves. The filtering done is much simplier than what "-S lv_role=public" will do, but should be good enough for our need. ---

OK folks, I'm back at it again. Instead of taking my J4400 ( 24 x 1T disks) and making a big RAID60 out of it which Linux cannot make a filesystem on, I'm created 4 x RAID6 which each are 3.64T I then do : sfdisk /dev/sd{b,c,d,e} <<EOF ,,8e EOF to make a big LVM partition on each one. But then when I do : pvcreate /dev/sd{b,c,d,e}1 and then pvdisplay It shows each one as