From owner-freebsd-virtualization@freebsd.org Wed Dec 23 16:39:00 2020 Return-Path: Delivered-To: freebsd-virtualization@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 59A524C42B6 for ; Wed, 23 Dec 2020 16:39:00 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1JnH2yRZz3PGK for ; Wed, 23 Dec 2020 16:38:59 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 0BNGbfG4061592 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Dec 2020 08:37:42 -0800 (PST) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 0BNGbfCq061591; Wed, 23 Dec 2020 08:37:41 -0800 (PST) (envelope-from warlock) Date: Wed, 23 Dec 2020 08:37:41 -0800 From: John Kennedy To: Wei Hu Cc: tech-lists , "freebsd-virtualization@freebsd.org" Subject: Re: resizing a FreeBSD-12.1 vm on Azure Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D1JnH2yRZz3PGK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net X-Spamd-Result: default: False [-0.55 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[phouka.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.170.196.116:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.25)[0.251]; SPAMHAUS_ZRD(0.00)[107.170.196.116:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]; MAILMAN_DEST(0.00)[freebsd-virtualization]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 16:39:00 -0000 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@freebsd.org > virtualization@freebsd.org> On Behalf Of tech-lists > > Sent: Tuesday, December 15, 2020 11:57 AM > > To: freebsd-virtualization@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.