Tag Archives: lvm

Upgrading to Fedora 33: Removing Your Old Swap File on EFI Machine

4 Replies

Fedora 33 adds a compressed-memory-based swap device using zram. Cool! Now you can remove your old swap device, if you were a curmudgeon like me and even had one in the first place.

If you are NOT on an EFI system or not using LVM, be aware of this and make changes to these steps as needed. (Specifically, the path given in step 6 will be different.)

  1. After upgrading to Fedora 33, run free. Notice that swap size is the sum of the 4G zram device plus your previous disk-based swap device. Try zramctl and lsblk commands for more info.
  2. Stop swapping to the swap device we’re about to remove. If using LVM, expect the VG and LV names to be different.
    swapoff /dev/vg0/swap
  3. If LVM, remove the no-longer-needed logical volume.
    lvremove /dev/vg0/swap
  4. Edit /etc/fstab and remove (or comment out) the line for your swap device.
  5. Edit /etc/default/grub.
    In the GRUB_CMDLINE_LINUX line, remove the “resume=” part referring to the now-gone swap partition, and the "rd.lvm.lv=” part that also refers to it.
  6. Apply above changes to actual GRUB configuration:
    grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Reboot and your system should come back up. Enjoy using that reclaimed disk space for more useful things — it’s now unused space in the LVM volume group. If you want to actually use it, look into lvextend, and also resize2fs or xfs_growfs.

Plumbing needs an API: “libification”

1 Reply

Here are my slides and video from my talk “All Plumbing needs an API” from Linux Plumbers Conference 2012.

My thesis is we would improve the quality of our platform if we recognize the flaws in excessive use of other commandline tools by other tools, and worked towards more APIs and libraries for low-level parts of the Linux platform. There are many reasons given in the talk I don’t want to rehash; here are some more thoughts since I gave the talk:

First, this is not a push for every single instance of one program being called by another to be replaced by an API. But on the spectrum of cmdline-parsing vs libraries, I think we are too far towards the former, and should make an effort to shift dramatically towards the latter.

Second, we can take a “pave the cowpaths” approach toward this — we should first libify those tools most commonly parsed by other tools. I’ve been helping out on liblvm, a library for LVM (whose tools are unquestionably over-parsed.) There are also many other network, storage, and system configuration tools that are candidates for libification.

The move towards virtualization & cloud computing has led to many tools formerly configured directly by the sysadmin now being configured by other tools. Broadening the coverage of our system-level management APIs will improve Linux’s flexibility and reliability as a virtualized OS.

targetd: remote administration of a Linux storage appliance

5 Replies

targetd is a new service that will make it easier to configure Linux machines to export block-based volumes over iSCSI or other protocol.

The Why

Virtual machines need disk images to run from. While you can put the disk image on the local storage of the machine executing the VM, there are many benefits to centralizing disk images — this lets you seamlessly migrate the VM’s execution between machines, is easier to manage, and can be more space-efficient when many of the disk images are almost the same, which is pretty common.

However, it hasn’t been nearly as easy to provision a new storage volume on the central storage box as it could be. High-end storage appliances have tools for this, but the normal way using only open-source tools has been to ssh into the machine, create the new volume and export it using command–line tools, and then go back to however you’re creating the new VM and tell it about the new volume you created.

targetd is a step towards making this process a little easier.

The What

The remote API is based on jsonrpc-2.0 over HTTP. The Python standard library does much of the work towards implementing our API server, what’s left is the actual implementation of functionality and the jsonrpc error handling.

This API will let targetd eventually tie into existing storage management tools. One such under development is libstoragemgmt, a framework by my colleague Tony Asleson, which will give virtualization tools like oVirt or OpenStack a common API for management of the many proprietary storage appliances, and also open-source appliances like targetd.

Linux has had reliable LVM-based volume management for a long time, and now has an excellent kernel-based storage target subsystem called LIO. targetd uses both of these heavily. In configuring a machine for a storage appliance role, give targetd a volume group to allocate volumes from, set user/password for access, and you’re just about done.

There is one coding pet peeve of mine that I’ve ranted about before that targetd avoids completely. targetd uses libraries to interface with LVM and LIO instead of the all-too-common alternative of passing commands to command-line tools, and parsing the output. Much of the time spent towards targetd was improving these libraries. I believe proper error propagation, reduced text parsing, and better library APIs make this bottom-up approach a long-term win.

Current state and future plans

Today’s announcement is a pre-alpha 0.1 release. I’m really hoping to get to 1.0 for Fedora 18. There is a manpage to write and SSL support to add, but much more important than the source code of  targetd is the layout of the remote API itself. I’d love to get some more review of that, as well as the code, before 1.0. I have been working from what I believe are some common use-cases, but more feedback on how admins configure and use storage appliances would be most welcome too!

Please see the project on github for more info.