Increase size of bhyve VM

[leveraction]

I have recently started working with bhyve setting up virtual servers in my office. So far it works great.

Now that it I see how well it works I am regretting not making my file server larger. Is there any way I can just "append" the VM disk file and make it bigger without having to build and configure a whole new VM? Thanks.

 

[aragats]

I would simply dd to a new file to be on the safe side:

truncate -s 100G <new_vm_img>
dd if=<old_vm_img> of=<new_vm_img> conv=notrunc

Then you should resize the filesystem in your guest OS.

 

[leveraction]

Aragats...I tried your solution and the file size was increased, but when I tried to boot the image it wanted to reinstall. Obviously, something is not quite right.

 

[aragats]

What's your guest OS?

[EDIT] Also, if it's GPT, you probably want to recover the geometry, take a look here.

 

[leveraction]

The guest is FreeBSD 11.1-RELEASE, same as host. I will take a look at your link and the one posted by Phishfry as well.

 

[leveraction]

OK, I looked at the section on growfs. The instructions appear to deal with a situation where you have a drive where the partitions do not fully use the available space so it shows how to increase the size of a target partition.

In my case, from inside the VM, there is no available space. (that is the problem) From the host, there is plenty of room of course. I already attempted to dd my way to a larger disk image, but that causes the VM OS to attempt a reinstall on the next boot. I am not sure why that is.

It seems like, barring a special utility written just for this purpose, I would need to safely increase the disk image size, then boot into the VM and go through the standard growfs routine described in the page aragats linked to.

Of course, at this point I don't know how to safely increase the disk image size without triggering the OS reinstall.

 

[aragats]

From the link above:
If the disk was formatted with the GPT partitioning scheme, it may show as “corrupted” because the GPT backup partition table is no longer at the end of the drive. Fix the backup partition table with gpart:

# gpart recover ada0
ada0 recovered

That's exactly your situation: when you increased your file size the GPT backup partition table is no longer at the end.

 

[SirDice]

What kind of disk did you attach to the VM? truncate(1) works for file based images, not for ZVOLs.

 

[leveraction]

I used truncate to create the disk image. I tried gpart recover as in gpart recover ./my_image.img and got Invalid Argument error. I think it is expecting a device name but of course, that is not what I have. Strange that VMs are even mentioned on the FBSD Handbook page you referenced above, but it doesn't actually tell you how to work with them. I wish they would have included an example.

 

[aragats]

I tried gpart recover as in gpart recover ./my_image.img and got Invalid Argument error.
I think it is expecting a device name but of course, that is not what I have.

You can create a device node by running mdconfig my_image.img.

 

[leveraction]

OK, so I created the device node with mdconfig my_image.img and then was able to 'recover' it with gpart. Then I started the VM and attempted to follow the instructions on growfs.
I ran into problems though because I cannot use the device found by looking in /var/run/dmesg.boot as described in the instructions.
My disk device appears to be called vtblk0. When I run gpart show vtblk0 I get "gpart: No such geom: vtblk0". Note that the dmesg output lists the vtblk0 device at the larger size and not it original size at creation.
I should note that the host and guest systems in this case are both running ZFS.
Anyway have any thoughts on what the next step is from here?