A NetBSD DomU (Xen) needed more disk space for its root disk. While this may not be worth mentioning with the help of cfdisk or GNU/parted in Linux land, I haven't done this yet on a NetBSD system. Hubert describes this in part on his blog, but doesn't really enlarge the partition but adds and configures another partition to the disk. So, let's describe the whole process, including the resize_ffs part.

First, we need to resize the actual device of course. We're using LVM for our PV domain:

$ lvresize --size +4G vg0/netbsd-disk0

After starting the DomU, we can see the new disk size:

netbsd: xbd0: 4096 MB, 512 bytes/sect x 8388608 sectors
netbsd: xbd0: 8192 MB, 512 bytes/sect x 16777216 sectors

These sector numbers will be important in the next step, editing the disklabel:

$ disklabel xbd0
# /dev/rxbd0:
type: unknown
disk: disk0
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 8322
total sectors: 8388608
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

16 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:   7863408         0     4.2BSD   2048 16384     0
 b:    525200   7863408       swap                   
 c:   8388608         0     unused      0     0
 d:   8388608         0     unused      0     0

We need to do a few things now:

Adjusting the total sectors
Adjusting the d partition, the full disk on x86.
adjusting the c partition, the NetBSD part of the disk. As all partitions will belong to this NetBSD installation, its size will be equal to the d partition.
Adjust the offset of the swap partition.
And finally adjust the size of our root partition, a in our case.

Let's do all that in one go:

$ disklabel -e xbd0                         
# /dev/rxbd0:
type: unknown
disk: disk0
label: 
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 8322
total sectors: 16777216
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0 

16 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:  16252016         0     4.2BSD   2048 16384     0
 b:    525200  16252016       swap                   
 c:  16777216         0     unused      0     0
 d:  16777216         0     unused      0     0

With 16777216 as a (new) total sector count, and a swap size of (unchanged) 525200 sectors, this leaves 16252016 sectors for the root disk.

In Linux, the partition table would need to be initialized and I decided to reboot the VM to make this happen. Only afterwards I learned about disklabel -i -r: "Read the on-disk label for sd0, edit it using the built-in interactive editor and reinstall in-core as well as on-disk".

Now that the disklabel has been adjusted, we still need to resize the file system:

$ resize_ffs -p -v /dev/rxbd0a
It's required to manually run fsck on file system before you can resize it

 Did you run fsck on your disk (Yes/No) ? Yes
Growing fs from 1965852 blocks to 4063004 blocks.

$ df -h /
Filesystem         Size       Used      Avail %Cap Mounted on
/dev/xbd0a         3.6G       3.4G       8.5M  99% /

Hm, still nothing. Rebooting the VM once more, but now fsck was unhappy:

Starting root file system check:
/dev/rxbd0a: BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE

/dev/rxbd0a: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
Automatic file system check failed; help!
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
[1]   Terminated              (stty status "^T...
Enter pathname of shell or RETURN for /bin/sh:

# fsck_ffs -f /dev/rxbd0a
** /dev/rxbd0a
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
** File system is already clean
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
ALTERNATE SUPERBLK(S) ARE INCORRECT
SALVAGE? [yn] y

SUMMARY INFORMATION BAD
SALVAGE? [yn] y

BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] y

158187 files, 1806197 used, 99638 free (654 frags, 12373 blocks, 0.0% fragmentation)

***** FILE SYSTEM WAS MODIFIED *****

While we're in this rescue shell, let's try resize_ffs once more:

# resize_ffs -p -v /dev/rxbd0a
It's required to manually run fsck on file system before you can resize it

 Did you run fsck on your disk (Yes/No) ? Yes
Growing fs from 1965852 blocks to 4063004 blocks.

Another reboot later and now the system is able to see its new disk space:

$ df -h /
Filesystem         Size       Used      Avail %Cap Mounted on
/dev/xbd0a         7.5G       3.4G       3.7G  48% /