NhOK6xR21ov6BQnKRnmhBVINPXMjxxATPSQbh1McEi81Tc3C/u0qn6HcsKoMgAC50D47 5aFSOBvpokc8HiQMHh7tjYZJCaDT3eWbwPO7dbF8wzS4gJX2HNfsZQCcw7eNymjNBujX zAS798OqzEdiUD/O5bZ8aEgyOqNaIL+0rjWB/8hd1KD0QwFhoAU1rwTLJLiFcWpbW8c1 PGEvm/NicOD/q5JHu0/Svc18uSva4fTM1Wbw2RD4NdQGXPsIscchxEehGl4SeYPXPsNa 7Tug== X-Gm-Message-State: AOJu0YzRyVi36w516gPP6LkBDZGWJ8JE5jeJYVC1xNE1QZmQrHfYBZco PB2fSlVorTx3GO4CxRqlQRDeZuCCDiMnn3najMgIn8n46PC+5AyxrMCiH6u7pTdTnb+41ZusRnU n7R0jO3W/9jeyG4JeEDWYT0ZsYXjfjns= X-Gm-Gg: ASbGnct46gEPjJjiQnvXfA4LiIU2hXs01KkZvkWup4+H63+1Nkk2JsJAecN96lSYQit pU9RAnVuxHFp7jnK6SyX6GOm1te5BMYc4bTOm+xG3mkfu5GW0pN3hPM02/xeVtt3KEoQ7NdoVgi cHrm/dnBZDN4070RIN5yolHJT5wDFCI1CYiriwPMrZCbp198L7/hYOEjd1Cm0NAUJ0DAgk2WD5Z hJYhuGI4QG0229UcSfqUuw9p99puMwYEu0Crw/DuqqCRmh9WQd5VmBo29fWNWfunWV4TW8Z8s0H Bk5KGA7oVFQrC7bZTcqGrqq1Qnm3hjHiU7QmnWIbZspPfxDbWog5XoNptosJP/lfkMNO7dKHNdb tlyWz X-Google-Smtp-Source: AGHT+IFTHqtkXGe0HcO2hofdOd6Zh8JLiL7SUtOD4kjcMGE9R8TUEsxatzAj/ECSDnKtP3edXbjlj0MML01NbKR4G1Y= X-Received: by 2002:a05:6e02:96f:b0:434:a7ce:da4a with SMTP id e9e14a558f8ab-434a7de20damr48175805ab.30.1763407857546; Mon, 17 Nov 2025 11:30:57 -0800 (PST) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Freddie Cash Date: Mon, 17 Nov 2025 11:30:45 -0800 X-Gm-Features: AWmQ_blq_FWQTMbL3Us_BDoYBrm_nrqLiYG4JfDFi7EvVqnVqL57TgqtEvM7aHo Message-ID: Subject: Re: FreeBSD guest online disk resize To: Alexandre Biancalana Cc: Freebsd fs Content-Type: multipart/alternative; boundary="000000000000f179550643cf6295" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d9Hsg2lpCz3BnL --000000000000f179550643cf6295 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 17, 2025 at 11:01=E2=80=AFAM Alexandre Biancalana wrote: > I am using bhyve with several VMs where the VM disks (NVMe) are stored > on an NFS server and exported to the hypervisor. Occasionally, I need > to expand the disks due to space constraints. I perform this expansion > by resizing the VM disk files using the truncate command. > > On Linux guests, the disk resize is immediately recognized, and the > filesystem can be expanded online without issues. > > However, on FreeBSD guests, while the NVMe layer recognizes the disk > resize (confirmed by the appearance of the asynchronous event message > in dmesg): > > nvme2: async event occurred (type 0x2, info 0x00, page 0x04) > > and `nvmecontrol devlist` correctly shows the new disk size, there is a > problem. > > The VM disk has no partition table and is formatted entirely with UFS > and has a ufs label, hence geom_label is in use. Unfortunately, glabel > list does not recognize the disk resize and still shows the old disk > size. > Are you using UFS filesystem volume labels (-L option to newfs/tunefs) or GEOM labels create via glabel? They're two different things. One saves a label within the filesystem metadata, the other stores a label in the last sector of the disk or partition. The latter can cause issues when you try to resize disks/partitions/filesystems as you'll overwrite the label and need to recreate it. These days, glabel isn't really needed as most filesystems support volume labels, and the GPT partition scheme supports partition labels. glabel is still used for viewing labels, through, regardless of where in the GEOM stack they're created, including filesystem labels. > Ideally, I would like to perform a disk resize that FreeBSD recognizes > without requiring a system reboot. > > Am I missing a step, or is there a recommended procedure to make > geom_label recognize the resized disk size dynamically on FreeBSD > guests? > I've never managed to resize virtual disks in any hypervisor, regardless if it's on Windows, Linux, or FreeBSD, without power cycling the VM. Could be a configuration issue on my side, but I've always found it to be more reliable to treat the VM like physical hardware, where it's almost impossible to increase the size of a disk (aka replace with a larger one) without powering it off first. :) --=20 Freddie Cash fjwcash@gmail.com --000000000000f179550643cf6295 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 17, 2025 at 11:01=E2=80=AFAM = Alexandre Biancalana <biancalana= @gmail.com> wrote:
I am using bhyve wit= h several VMs where the VM disks (NVMe) are stored
on an NFS server and exported to the hypervisor. Occasionally, I need
to expand the disks due to space constraints. I perform this expansion
by resizing the VM disk files using the truncate command.

On Linux guests, the disk resize is immediately recognized, and the
filesystem can be expanded online without issues.

However, on FreeBSD guests, while the NVMe layer recognizes the disk
resize (confirmed by the appearance of the asynchronous event message
in dmesg):

nvme2: async event occurred (type 0x2, info 0x00, page 0x04)

and `nvmecontrol devlist` correctly shows the new disk size, there is a pro= blem.

The VM disk has no partition table and is formatted entirely with UFS
and has a ufs label, hence geom_label is in use. Unfortunately, glabel
list does not recognize the disk resize and still shows the old disk
size.

Are you using UFS filesystem volu= me labels (-L option to newfs/tunefs) or GEOM labels create via glabel? The= y're two different things.

One saves a label w= ithin the filesystem metadata, the other stores a label in the last sector = of the disk or partition. The latter can cause issues when you try to resiz= e disks/partitions/filesystems as you'll overwrite the label and need t= o recreate it.

These days, glabel isn't really= needed as most filesystems support volume labels, and the GPT partition sc= heme supports partition labels.

glabel is still us= ed for viewing labels, through, regardless of where in the GEOM stack they&= #39;re created, including filesystem labels.
=C2=A0
Ideally, I would like to perform = a disk resize that FreeBSD recognizes
without requiring a system reboot.

Am I missing a step, or is there a recommended procedure to make
geom_label recognize the resized disk size dynamically on FreeBSD
guests?

I've never managed to resiz= e virtual disks in any hypervisor, regardless if it's on Windows, Linux= , or FreeBSD, without power cycling the VM. Could be a configuration issue = on my side, but I've always found it to be more reliable to treat the V= M like physical hardware, where it's almost impossible to increase the = size of a disk (aka replace with a larger one) without powering it off firs= t. :)


--
Freddie Cash
fjwcash@gmail.com
--000000000000f179550643cf6295--