Solved How to grow .img and the zfs pool inside for a bhyve VM?

loveydovey

loveydovey

I have a CSM (non-UEFI) bhyve VM installed into .img with a zroot inside - but how do I grow the disk size now?

I tried truncate -s +20G disk.img - but that hangs the VM during boot. I tried recovering gpt backup+growing the partition to the end, but that prevents VM from even loading the menu.
 
I wish I could resize from inside the VM, but it won't boot, which is why I started this thread. And then I did do resize using gpart by mounting the .img file with mdconfig, but that made bhyveload not even be able to display menu, which is another reason I started this thread.

Maybe it has to do with the fact that it's not a UEFI installation.
 
Yeah sorry, of course if it cannot boot ...
Have you tried the debug option debug=yes in your file "vm_name.conf", dmesg or any other log file. I don't know if it'll tell much but it's worth a try.
 
Have you tried booting from a live DVD to get in there so that you an resize the partition itself?

Personally, I tend to add more images for storage if I need more storage because it's a bit easier to backup. Depending upon the filesystems involved, you can even mount those outside the VM and copy the files to a new image file and then direct the VM to that new file in lieu of the old one.
 
Thank you, hedwards - I did boot a live dvd with qemu and resized it that way, same result, it won't boot. But this is a GREAT advice, to just add more images for storage... It's also good because you'll never end up with a giant .img file with nothing stored on it after the sparse image grew to a bigger size and then went down in disk usage.
 
loveydovey said:
Thank you, hedwards - I did boot a live dvd with qemu and resized it that way, same result, it won't boot. But this is a GREAT advice, to just add more images for storage... It's also good because you'll never end up with a giant .img file with nothing stored on it after the sparse image grew to a bigger size and then went down in disk usage.
Click to expand...
That's rather unfortunate.

As long as whatever data you need is still there, you at least have the plan B of mounting the image file and transferring it to a new one. I will often times mount these read only on the main system as a means of back up, when I don't need the entire system backed up.
 
I use dd and add zeros to end of image file.

Phishfry

Post in thread 'VM File sizing'

Alrighty I had a need to increase images as I am now making FreeBSD images with a custom release makefile.
Problem is I have my custom build down to 200MB but when I open the image in a VM it is out of space.
Here is what I did:
Resize VM image on host:
dd if=/dev/zero bs=1M count=400 >> /vm/freebsd1.img
So this adds 400 Megabytes of zeros at the end of my image file thus enlarging it.

Then inside the VM
gpart resize -i 2 ada0
gpart resize -i 1 ada0s2
growfs -y /dev/ufs/FreeBSD

What is really strange to me is that this image uses UEFI but uses a slice disk...
 
If you are using GPT Scheme you will need to recover MBR inside VM because end of disk has changed.
gpart recover $diskid

I don't know how ZFS would figure into this scheme.
 
You must log in or register to reply here.
Back
Top