I came across an ugly problem and here’s what I did:
As a host system, I use openSUSE 13.2, GNOME; On that, I have gnome-boxes as a virtualiser (in fact, it uses quemu). In this VM, besides other, I tried openSUSE tumbleweed, KDE (pretty nice btw). Now that KDE5 came out, I learned that it requires more space in the root-partition (I guess because it still has a lot of KDE4 in it, plus the new stuff); Anyway: The “/” in my VM is full. BTW: I stayed with the default settings for openSUSE, so I have a / in btrfs and /home as xfs; I already deleted all old btrfs-snapshots.
On a non-virtual machine, I would “simply” take a live-image, start GParted (or any alternative) and change the partitions’s sizes. But: I have no clue how to apply a live-image to a virtual box. And of course, I can’t use the partitioner from within the VM (it wont’ let me unmount “/” – surprise!!1!).
I am pretty sure there’s a solution to that. But I am a complete newbie to virtualisation… Can anyone give me a hint?
> On a non-virtual machine, I would “simply” take a live-image, start
> GParted (or any alternative) and change the partitions’s sizes. But: I
> have no clue how to apply a live-image to a virtual box.
Why not?
You had to boot a live image in order to install anything in any virtual
environment. So boot it again, or any other image you want…
I can’t give precise instructions with quemu, though, I don’t use it.
(replace “guestname” with the name of your virtual machine)
Then list the partitions on the virtual disk:
$ virt-filesystems --long --parts --blkdevs -h -a ~/.local/share/gnome-boxes/images/nameofdisk
(replace “nameofdisk” with the name of your virtual disk)
Now that you know which one is your root partition and what size it is, create a file at least as big as your
virtual disk+the extra space you want to increase your root partition with (using 40G as an example):
Just an additional FYI -
The original post describes running out of space on the root (/) partition, but sometimes re-sizing partitions on a diskfile isn’t sufficient.
It should be noted that <depending on the type of diskfile> there often are ways to re-size the entire diskfile itself (both “growable” dynamic and fixed size formats.
So, just something to keep in mind which isn’t an option when working with real, physical disks.
Oh, thanks, that makes sense… Unfortulately, it tells me the following:
virt-resize: libguestfs error: lvm_set_filter: aug_save: Lens not found: Can not find lens guestfs_lvm_conf.lns
Do you understand what it means? What’s a “lens”? And somehow it sounds as if it wants to do something with lvm… How come – I have not (at least afaik) used any lvm?
On 2015-05-20 15:06, pbiel wrote:
> Do you understand what it means? What’s a “lens”? And somehow it sounds
> as if it wants to do something with lvm… How come – I have not (at
> least afaik) used any lvm?
Did you install the guest with full system encryption? That implies
using LVM.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
If you value the contents of your diskfile, <never> perform major surgery on an only copy. Always copy the disk before applying disk operations against one of the copies.
It’s been a long time since I’ve attempted to modify partitions in a diskfile like what you seem to be doing with libvirt.
Your LVM issue may be related to some other LVM related posts I’ve seen in the Install/Boot forum… something about LVM installed and running even when not used(may be also totally unrelated). But, since I haven’t personally run into that yet, I haven’t dived into whatever that situation involved.
There seems to be a bug in the current package in the repositories.
Libguestfs spits out those errors when it can’t find some files that are
missing from the initramfs: https://bugzilla.novell.com/show_bug.cgi?id=908632
The bug appears to be fixed, however just a short while ago there was
a new request submitted with regards to fixing this bug: https://build.opensuse.org/request/show/308082
“- Package guestfs_lvm_conf.aug (bnc#908632)”
You could try to install the latest version of package “guestfs-data” according to
post #4 in the bug report above:
# zypper -p http://download.opensuse.org/repositories/Virtualization/openSUSE_13.2/ in guestfs-data-1.26.10-168.11.x86_64
(assuming you’re using 64-bit, else you should pick the 32-bit package)
@DanneStrat: Thanks, this solved the one issue. Now, virt-resize walk through like a charm:
Summary of changes:
/dev/sda1: This partition will be left alone.
/dev/sda2: This partition will be resized from 10,0G to 15,0G. The
filesystem btrfs on /dev/sda2 will be expanded using the
'btrfs-filesystem-resize' method.
/dev/sda3: This partition will be left alone.
**********
Setting up initial partition table on ~/.local/share/gnome-boxes/images/outdisk ...
Copying /dev/sda1 ...
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
Copying /dev/sda2 ...
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
Copying /dev/sda3 ...
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
Expanding /dev/sda2 using the 'btrfs-filesystem-resize' method ...
Resize operation completed with no errors. Before deleting the old
disk, carefully check that the resized disk boots and works correctly.
Unfortunately, the virtual machine, after reboot, seems to be not impressed:
Am I doing something wrong here?
Do I probably need to point the vm to the new disk? I mean, the old one still exists and the new (= large) might ignored… Should I do something such as
Yes, now you need to change the disk to the new one.
If you have enough disk space I would advise you to
first make a backup of the old disk before you overwrite it:
then there is a possibility the new disk type is “raw” while the old one was “qcow2” (the default format used by qemu).
To find out if this is the case do:
Boxes-WARNING **: machine.vala:576: Failed to start oS Tumbleweed: Unable to start domain: internal error: process exited while connecting to monitor: 2015-05-21T23:39:19.479393Z qemu-system-x86_64: -drive file=/home/philipp/.local/share/gnome-boxes/images/boxes-unknown,if=none,id=drive-ide0-0-0,format=qcow2,cache=none: could not open disk image /home/philipp/.local/share/gnome-boxes/images/boxes-unknown: Image is not in qcow2 format
Any idea? I mean, I did not change the format of anything willingly. ****.
Just a FYI and not intended to discourage your efforts…
I myself ran into this issue (needing to enlarge / ) on one of my VMs today, so this is what I did… The approach and utilities I used should work using any virtualization technology and even any disk format.
As I described earlier, sometimes you also need to enlarge the disk. Even if you might originally want to simply re-size some other partition to make room for enlarging the root partition, IMO it’s simpler and likely a better long term decision to just enlarge the disk so that you’re not making another partition smaller(possibly causing another future problem). In this case, I decided to simply create a new, larger disk and then to clone the old disk to the new.
I decided to use Clonezilla to do the whole disk cloning, and if necessary to use gpart-live to modify the individual partitions. Other options should also be good like using dd to block copy/clone, or using other utilities.
Create a new disk with the desired new size. Leave it attached to the vm, I found that Clonezilla requires this to “see” both disks.
Configure the Guest to boot to Clonezilla
2a. Select the “Advanced” instead of default options. Select disk to disk cloning and no NTFS options, everything else default, including options to write boot to the new disk.
2b. Select and verify sda as the source (which likely will always be the case, but doublecheck by observing the disk sizes).
Shutdown
Disable CDROM or otherwise force boot to disk
Remove the original virtual disk, leaving only the new disk.
Boot to your new disk.
Inspect and verify all is running correctly. You can use “df” to view your partitions and partition usage.
Shutdown.
Configure gparted-live in the Guest CDROM
Boot to gparted-live, like myself despite authorizing Clonezilla to auto expand to fill the disk, it didn’t happen and you’ll find unformatted/unpartitioned disk space
Re-size / to fill the empty space
12 Shutdown
Boot to your system and verify the success of your operations by running “df” again.
It complains about the image not being in “qcow2” format (see the highlighted text in the error message I quoted).
Try to convert the disk to “qcow2” as I described in my previous post.