resizing a FreeBSD-12.1 vm on Azure

[John Kennedy]

On Wed, Dec 23, 2020 at 01:48:09PM +0000, Wei Hu via freebsd-virtualization wrote:
> Hello,
> 
> You can use resize option on Azure portal to increase the CPU and RAM of your VM. I believe you don't need to shut down the VM. Once you start the resizing, Azure will take care of rebooting the VM for you. The public IP will not change after the resizing.
> 
> If you want to grow the disk size, you will have to shut  down the VM. Find the disk for your VM on the portal. It should have option to grow the size. You may need to increase the FreeBSD filesystem size manually once the guest boots up again. I have not done this. I just heard from someone who has done this for Linux VM on Azure.

  I don't have a FreeBSD azure host, but I do have linux azure hosts.  Yes, you
can try to resize on the fly but there is a big banner up top that says:

	"If the virtual machine is currently running, changing its size will cause it to be restarted. Stopping the virtual machine may reveal additional sizes."

  My general experience with other hypervisors (HyperV, VMWare) and linux is
that you can't resize CPU and memory without rebooting the host.  For disks
though, I've done that a lot.  All my resizes on azure have, so far, required
reboots.  To be fair, I'm usually starting out with something small and
then resizing it something appropriate (like a D2s_v3 -> DS3_v2), so there
might be some resizing that wouldn't require a reboot.

  If you've got the VM tools installed on linux, it looks like it hooks the
systemd process for orderly shutdown.  Not sure what the equivalent for
FreeBSD would be, but if "shutdown -r now" does an orderly shutdown for you
(be careful...  some things like databases interpret that as a request to
do a quick-crash-stop), you're probably Ok.

> > -----Original Message-----
> > From: owner-freebsd-virtualization at freebsd.org <owner-freebsd-
> > virtualization at freebsd.org> On Behalf Of tech-lists
> > Sent: Tuesday, December 15, 2020 11:57 AM
> > To: freebsd-virtualization at freebsd.org
> > Subject: resizing a FreeBSD-12.1 vm on Azure
> > 
> > Hello,
> > 
> > Has anyone ever resized a freebsd vm on Azure? I don't mean just the disks.
> > Really the whole point is to have more CPU and RAM. I have the option to do
> > this via their portal, just select whats required and hit 'resize' but I'm a bit
> > hesitant. I guess it'll work on a windows VM but anything else?
> > 
> > If you did manage to do this, did you need to shut the VM down before resizing
> > it? Was your external IP preserved or did it force you to have another one? Did
> > you have to run anything else, like growfs?
> > 
> > The author of https://forums.freebsd.org/threads/azure-vm.62440/ tried to do
> > this in 2017 but wasn't able to at the time.

  All the IPs seem to survive reboots and even extended shutdown as long as
you don't delete the network interface.  If you delete the network interface,
azure acts like it is throwing it back into the free pool and your chances
of getting the same IP back are probably pretty slim.  I've staticly assigned
private IPs via the portal (which it'll let you do as long as nobody else has
it assigned), but never tried that with a public IP.

  If you're just trying to play with RAM+CPU for some temporary workload and
you don't want to play with disk at all because you're going to reduce it later
then you won't need to worry about disk at all.  If not...


  On linux, when I resize disk without rebooting, I try to set it up so that
my disks are just XFS with no partitions on anything I know will grow.  A non-
issue with HyperV and VMWare where I can have lots of individual disks.  In
azure, you're sort of motivated to have everything on one disk, both for IOPS
(you get more as the disk size goes up) and cost (you're charged in ^2 size
ranges).  That means partitions.

  For linux, I just lump everything dynamic into the last partition on the
disk.  When I resize live, I delete the entire partition (aiugh!), then
recreate it making sure the type and start match up to what it used to be.
If you haven't rebooted, you may need to partprobe or done your SCSI rescan
tricks to get the OS to notice that you have more space, extra disks, etc.
Then you grow the filesystem (xfs_growfs doesn't require reboot) and you're
good!  If your heart still isn't in your teeth for deleting a live partition
while the OS is using it.

  For FreeBSD, I'm almost always using ZFS.  In the cloud, I'm not using an
encrypted GELI disk.  That has been a show-stopper for me in home testing
because you somehow need to resize that before resizing.  For my Digital
Ocean VM, I think I just tracked down the auto-resize on boot option and
things generally worked.  In Azure, it seems like you would want to make
sure that is disabled.  With new native-ZFS-encryption, maybe non-issue?

  I don't think azure in any way bundles CPU+RAM sizing with disk, so I don't
thing you have to worry about any irreversible upsizing issues.