search for: lvrenaming

I'd like to rename my existing volume groups and logical volumes (I picked names a long time ago I no longer like :-). I recently stumbled across the lvrename and vgrename commands, but when I tried the former to rename the logical volume that my root partition resides on, the system became unbootable. In addition to renaming the LV (and VG if I decide to to that as well), what

Hi, I want to rename some volume groups and logical volumes. I was not surprised when it would not let me rename active volumes. So I booted up the system using the CentOS 5.5 LiveCD, but the LiveCD makes the logical volumes browsable using Nautilus, so they are still active and I can't rename them. Tried: /usr/sbin/lvchange -a n VolGroup00/LogVol00 but it still says: LV

This lays the groundwork for setting Root and RootBackup onto individual partitions for multiple disk installations in the future. Install, removal, upgrade testing has been performed and all seems to work at this point. --- scripts/ovirt-config-boot | 15 ++++++++------- scripts/ovirt-config-storage | 28 +++++++++++++++------------- scripts/ovirt-config-uninstall | 2 ++

rebased it against current next-devel --- scripts/ovirt-config-boot | 15 ++++++++------- scripts/ovirt-config-storage | 28 +++++++++++++++------------- scripts/ovirt-config-uninstall | 2 ++ scripts/ovirt-functions | 8 +++++--- 4 files changed, 30 insertions(+), 23 deletions(-) diff --git a/scripts/ovirt-config-boot b/scripts/ovirt-config-boot index ed2bb9f..01c1821

Hi, A short while ago I renamed two VMs by shutting them down, lvrenaming the storage devices and adjusting the storage path and vm name using "virsh edit". This works fine so far and "virsh list" shows them correctly however virt-manager has gone bonkers and still shows them with the old names and alternating between the status "Shutoff"...

Hello, I'm using a LVM storage pool. I renamed a guest and I would like to change the LV name to match to avoid future confusion. How do i do this? There is no vol-edit command (fully updated RHEL6). Thanks, Dax Kelson

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

From: "Richard W.M. Jones" <rjones at redhat.com> Callers are supposed to use the availability API to check for functions that may not be available in particular builds of libguestfs. If they don't do this, currently they tend to get obscure error messages, eg: libguestfs: error: zerofree: /dev/vda1: zerofree: No such file or directory This commit changes the error

I'm currently working on gobject bindings for libguestfs. I haven't got as far as compiling anything yet, but I've attached the C header for initial review. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -------------- next part -------------- An embedded and

This is a follow-up to the other generator changes in: https://www.redhat.com/archives/libguestfs/2017-February/msg00217.html Rich.

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

This is a simpler patch that removes GUESTFSD_EXT_CMD completely.

Replace GUESTFSD_EXT_CMD with a command line option ‘./guestfsd --print-external-commands’

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

Very large but mechanical change to the generator. Rich.

Split up the huge generator/actions.ml into several smaller files. Rich.

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