Merge branch 'main' into OpenSSH

This commit is contained in:
Rowan Puttergill 2026-07-15 08:48:41 +00:00
commit f8dd9949ca
22 changed files with 64 additions and 500 deletions

4
.gitignore vendored
View file

@ -2,3 +2,7 @@ build
cache
public
preview.pid
.DS_Store
*.bak
*~
*swp

Binary file not shown.

Before

Width:  |  Height:  |  Size: 183 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 255 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 160 KiB

After

Width:  |  Height:  |  Size: 72 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 158 KiB

After

Width:  |  Height:  |  Size: 64 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 233 KiB

After

Width:  |  Height:  |  Size: 63 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 140 KiB

After

Width:  |  Height:  |  Size: 53 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 219 KiB

After

Width:  |  Height:  |  Size: 106 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 151 KiB

After

Width:  |  Height:  |  Size: 61 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 163 KiB

After

Width:  |  Height:  |  Size: 68 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 175 KiB

After

Width:  |  Height:  |  Size: 78 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 283 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 282 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 293 KiB

After

Width:  |  Height:  |  Size: 128 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 286 KiB

After

Width:  |  Height:  |  Size: 120 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 231 KiB

After

Width:  |  Height:  |  Size: 43 KiB

Before After
Before After

Binary file not shown.

View file

View file

@ -1,443 +0,0 @@
= File sharing with NFS Installation
Peter Boy (pboy);Emmanuel Seyman (eseyman); Jason Beard (cooltshirtguy); Otto Liljalaakso; Jocelyn Gould (korora)
//:page-authors: {author}
:revnumber: F43
:revdate: 2025-10-30
//:page-aliases: installation-an-introduction.adoc
[abstract]
// ------
NFS, the Network File System, is a mature protocol designed to share files between Unix-type systems over TCP/IP networks. Fedora Server Edition installs by default the kernel space NFS server, but without configuration and activation. This article describes its configuration and activation.
// ------
The objective of this guide is how to setup __NFS Server__ on a Fedora Server Edition. For information on how to setup the client part, consult your OS's documentation.
NFS is a Network service in Linux used to share the files and directories of the Server to users (clients) on the network. It allows clients to _mount_ a remote directory or complete filesystem over a network and interact with it much like local storage is accessed. It is the same principle as Map Drive in Windows Systems. One of it most used benefits is to store and access data on central location.
The NFS Protocol was first introduced by Sun Microsystem in 1984. The protocol has evolved from its origins. Over the years, new versions have been released, adding new features. Currently, NFS v4.2 is the current version. Perhaps most practically significant is the optional user identification as well as a virtual ROOT.
NFS protocol is not encrypted by default, and unlike Samba, unless you activate the optional feature it does not provide user authentication. Access to the server is restricted by the clients IP addresses or hostnames.
The kernel space NFS server features high performance and is therefore selected as default. Fedora Server also supports user space NFS server. However, this is not the subject of this article.
== Preparation
There are three packages which provide basic support for kernel space NFS:
nfs-utils::
is the main package and provides a daemon for the kernel NFS server and related tools. It also contains the _showmount_ program to query the mount daemon on a remote host for available ressources, eg listing the clients which are mounted on that host. It also contains the mount.nfs and umount.nfs programs.
libnfsidmap::
NFSv4 User and Group ID Mapping Library that handles mapping between names and ids for NFSv4.
sssd-nfs-idmap::
SSSD plug-in provides a way for rpc.idmapd to call SSSD to map UIDs/GIDs to names and vice versa. It can be also used for mapping principal (user) name to IDs(UID or GID) or to obtain groups which user are member of.
Ensure that these packages are really installed.
[source,]
----
[…]$ rpm -qa | grep nfs
libnfsidmap-2.8.4-0.fc43
sssd-nfs-idmap-2.11.1-4.fc43
nfs-utils-2.8.4-0.fc43
----
If a package missing, then a system administrator can simply reinstall it.
=== Organizing storage
In principle, NFS can share any directory on the server. However, it makes sense to concentrate at least generally shared files in a central location instead of scattering everything around.
Furthermore, it is a best practice is to use a global NFS root directory and bind mount those directories which are holding specific data at specific locations to the share mount point.
In accordance to the Filesystem Hierarchie Standard (FSH), using a /srv/nfs4 directory as the NFS root is a good choice.
Following Fedora Server storage rationale, a system administrator will create a logical volume and mount it to either `/srv` to create a Logical Volume as a pool for various services, or `/srv/nfs` to create a Logical Volume, probably thin provisioned, for each service. In case of systematic extensive utilization, a static LVM volume of fixed size is advisable. For occasional usage, a thin provisioned logical LVM volume might be the better choice.
In this guide we will demontrate the latter and create a thin provisioned LV for each service in /srv.
1. *Create a nfs export directory in /srv*
+
[source,]
----
[…]$ sudo mkdir /srv/nfs
----
+
The created directory is by default readable for everyone, but not writable.
2. *Create a user and group nfs*
+
As already stated, nfs does not provide user authentication. A common way is to either use the same UID/GID for a given user on all devices on the network or to map every client to user nobody and make the export files read- and writable for everybody, i.e. for any user of the system. The former is difficult to achieve without a central logon instance, and the latter is at best inconvenient from a security point of view. So we use a pseudo user without a home directory and without a login shell, who owns all exported files and directories by default.
+
[source,]
----
[…]$ sudo adduser -c 'nfs pseudo user' -M -r -s /sbin/nologin nfs
----
3. *Create and mount the required Logical Volumes*
+
The easiest way is to use Cockpit with its storage module. Select on the right side the root Volume Group and select "Add logical volume" in the new window.
+
image::services/nfs-server-inst-001.png[Create logical volume]
+
Fill in the form as needed. It is useful to name the LV to reflect the content or directory you want to store. Select "Pool for thinly provisioned volumes" and choose an appropriate size to accommodate all the data you plan to store.
+
In the list of logical volumes that is then displayed, the line with the newly created LV contains the option "Create thin volume". It opens a new form to create a LV to store data. We will use it for nfs exports.
+
image::services/nfs-server-inst-005.png[Create thin volume]
+
Fill in the form appropriately. Keep in mind that you are specifying the maximum value for the size of the volume. The system starts with a much smaller initial value and expands it as needed.
+
After the creation of the volume the list of logical volumes contains a new entry for the logical Volume just created with an option "Format". It opens a new form.
+
image::services/nfs-server-inst-009.png[Format the new logical volume]
+
Again, fill in the form and you are done.
+
For hardcore system administrators with mouse allergy, the whole thing via CLI.
+
[source,]
----
[…]# lvcreate -L 40G -T fedora/srv -V 30G -T fedora/srv -n nfs
[…]# lvs
[…]# mkfs.xfs /dev/fedora/nfs
[…]# mkdir -p /srv/nfs
[…]# vim /etc/fstab
...
/dev/mapper/fedora-root / xfs defaults 0 0
/dev/mapper/fedora-nfs /srv/nfs xfs defaults 0 0
...
----
+
Finallly mount the created filesystem.
+
[source,]
----
[…]# mount -a
----
4. *Create and configure the directories to share*
+
In a typical use case you may create a directory 'common' to widely share data and a directory 'project', in which a team member shares data located in the home directory with the team.
+
[source,]
----
[…]# sudo mkdir -p /srv/nfs/{common,project}
[…]# sudo chown -R nfs:nfs /srv/nfs/*
[…]# sudo mount --bind /home/USER/PROJECT /srv/nfs/project
----
+
To make the bind mount(s) permanent, add the following entries to the /etc/fstab file:
+
[source,]
----
[…]# vi /etc/fstab
/home/USER/PROJECT /srv/nfs/PROJECT none bind 0 0
----
== Optional server configuration
NFS server configuration uses 3 files
* /etc/nfs.conf
* /etc/nfsmount.conf
* /etc/idmapd.conf
The commented out lines describe the default built in configuration.
1. Configure the NFS basic directory
+
[source,]
----
[…]$ sudo vi /etc/nfs.conf
/home/USER/PROJECT /srv/nfs/PROJECT none bind 0 0
----
== Activation
1. *Firewall configuration*
+
NFS uses port 2049 which is blocked in a Fedora standard installation by defaut.
+
[source,]
----
[…]# firewall-cmd --permanent --add-service=nfs
[…]# firewall-cmd --reload
----
2. *Start NFS enabling autostart at boot time*
+
[source,]
----
[…]# systemctl enable nfs-server --now
[…]# systemctl status nfs-server
----
+
This starts the NFS server only, but not the NFS client. Therefore, the server can not mount file ressources provided by another server. If required, additionally execute at first _`systemctl enable nfs-client.target --now`_. For additional details you may look at _`man 7 nfs.systemd`_.
3. Check availabe NFS capabilities
+
Fedora enables versions 3 and 4.x, version 2 is disabled. The latter is pretty old now. Every machine should provide at least version 3.
+
[source,]
----
[…]# cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2
----
+
So the NFS server supports versions 3 and all version 4 capabilities.
== File resource configuration
//====
//**Possible/intended topics**
//* Create configuration file
//* (optionally) configure password authentification (NFS 4)
//* (optionally) deactivate rpcbind
//+
//Set 'vers3=n' in the '[nfsd]' section of
// /etc/nfs.conf, mask the RPC services, and restart NFS:
//+
//systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
//systemctl restart nfs-server
//+
//(see https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/configuring-an-nfsv4-only-server_exporting-nfs-shares[Configuring an NFSv4-only server] )
//
//See for some additional ideas:
//
//* https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/exporting-nfs-shares_deploying-different-types-of-servers[Exporting NFS shares]
//* or https://www.tecmint.com/install-nfs-server-on-centos-8/[How to Set Up NFS Server and Client on CentOS 8]
//
//====
NFS provides 2 options to configure which directores and files to share
/etc/exports::
the "traditional" grand all-in-one configuration file
/etc/exports.d::
the new way, a directory to collect a set of specific configuration files, which is read file by file at startup. These files must have the extension *.exports. The format is the same as the grand configuration file.
You can use both options in parallel with the grand configuration file read in first. We will use the modern form only.
=== Configuration by example
Example 1::
Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
+
[source,]
----
[…]$ sudo vi /etc/exports.d/common.exports
<i(nsert)>
/srv/nfs/common *(rw,sync)
----
Example 2::
Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
+
[source,]
----
[…]$ sudo vi /etc/exports.d/common.exports
<i(nsert)>
/srv/nfs/common *(rw,sync)
----
Example 3::
Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
+
[source,]
----
[…]$ sudo vi /etc/exports.d/common.exports
<i(nsert)>
/srv/nfs/common *(rw,sync)
----
Example 4::
Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
+
[source,]
----
[…]$ sudo vi /etc/exports.d/common.exports
<i(nsert)>
/srv/nfs/common *(rw,sync)
----
Example 6::
Export the directory /srv/nfs/projects with all users of a specific network device with Read/Write and Synchronize access
+
[source,]
----
[…]$ sudo vi /etc/exports.d/projects.exports
<i(nsert)>
/srv/nfs/common *(rw,sync)
----
==== Connection options
Each default for every exported file system must be explicitly overridden. For example, if the rw option is not specified, then the exported file system is shared as read-only.
For basic options of exports
Option Description
rw/wo::
Allow both read and write requests / only read requests on a NFS volume.
sync/async::
Reply to requests only after the changes have been committed to stable storage (Default) / allow the NFS server to violate the NFS protocol and reply to requests before any changes made by that request have been committed to stable storage.
secure/insecure::
Require that requests originate on an Internet port less than IPPORT_RESERVED (1024). (Default) / accepts all ports. using the insecure option allows clients such as Mac OS X to connect on ports above 1024. This option is not otherwise "insecure".
wdelay/no_wdelay:: Delay committing a write request to disc slightly if it suspects that another related write request may be in progress or may arrive soon. (Default)
This option has no effect if async is also set. The NFS server will normally delay committing a write request to disc slightly if it suspects that another related write request may be in progress or may arrive soon. This allows multiple write requests to be committed to disc with the one operation which can improve performance. If an NFS server received mainly small unrelated requests, this behaviour could actually reduce performance, so no_wdelay is available to turn it off.
subtree_check/no_subtree_check::
This option enables subtree checking. (Default)
This option disables subtree checking, which has mild security implications, but can improve reliability in some circumstances.
root_squash/no_root_squash::
Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.
Turn off root squashing. This option is mainly useful for disk-less clients.
all_squash/no_all_squash::
Map all uids and gids to the anonymous user. Useful for NFS exported public FTP directories, news spool directories, etc.
Turn off all squashing. (Default)
anonuid=UID::
These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150.
anongid=GID::
Read above (anonuid=UID)
Setting the crossmnt option on the main psuedo mountpoint has the same effect as setting nohide on the sub-exports: It allows the client to map the sub-exports within the psuedo filesystem. These two options are mutually exclusive.
=== Administration
When the nfs service starts, the /usr/sbin/exportfs command launches and reads this file, passes control to rpc.mountd (if NFSv2 or NFSv3) for the actual mounting process, then to rpc.nfsd where the file systems are then available to remote users.
When issued manually, the /usr/sbin/exportfs command allows the root user to selectively export or unexport directories without restarting the NFS service. When given the proper options, the /usr/sbin/exportfs command writes the exported file systems to /var/lib/nfs/xtab. Since rpc.mountd refers to the xtab file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately.
The following is a list of commonly used options available for /usr/sbin/exportfs:
-r — Causes all directories listed in /etc/exports to be exported by constructing a new export list in /etc/lib/nfs/xtab. This option effectively refreshes the export list with any changes that have been made to /etc/exports.
-a — Causes all directories to be exported or unexported, depending on what other options are passed to /usr/sbin/exportfs. If no other options are specified, /usr/sbin/exportfs exports all file systems specified in /etc/exports.
-o file-systems — Specifies directories to be exported that are not listed in /etc/exports. Replace file-systems with additional file systems to be exported. These file systems must be formatted in the same way they are specified in /etc/exports. Refer to Section 18.7, “The /etc/exports Configuration File” for more information on /etc/exports syntax. This option is often used to test an exported file system before adding it permanently to the list of file systems to be exported.
-i — Ignores /etc/exports; only options given from the command line are used to define exported file systems.
-u — Unexports all shared directories. The command /usr/sbin/exportfs -ua suspends NFS file sharing while keeping all NFS daemons up. To re-enable NFS sharing, type exportfs -r.
-v — Verbose operation, where the file systems being exported or unexported are displayed in greater detail when the exportfs command is executed.
If no options are passed to the /usr/sbin/exportfs command, it displays a list of currently exported file systems.
==== Using exportfs with NFSv4
The exportfs command is used in maintaining the NFS table of exported file systems. When typed in a terminal with no arguments, the exportfs command shows all the exported directories.
Since NFSv4 no longer utilizes the rpc.mountd protocol as was used in NFSv2 and NFSv3, the mounting of file systems has changed.
An NFSv4 client now has the ability to see all of the exports served by the NFSv4 server as a single file system, called the NFSv4 pseudo-file system. On Red Hat Enterprise Linux, the pseudo-file system is identified as a single, real file system, identified at export with the fsid=0 option.
For example, the following commands could be executed on an NFSv4 server:
[source,]
----
mkdir /exports
mkdir /exports/opt
mkdir /exports/etc
mount --bind /usr/local/opt /exports/opt
mount --bind /usr/local/etc /exports/etc
exportfs -o fsid=0,insecure,no_subtree_check gss/krb5p:/exports
exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/opt
exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/etc
----
In this example, clients are provided with multiple file systems to mount, by using the --bind option which creates unbreakeable links.
Because of the pseudo-file systems feature, NFS version 2, 3 and 4 export configurations are not always compatible. For example, given the following directory tree:
[source,]
----
/home
/home/sam
/home/john
/home/joe
----
and the export:
[source,]
----
/home *(rw,fsid=0,sync)
----
Using NFS version 2,3 and 4 the following would work:
[source,]
----
mount server:/home /mnt/home
ls /mnt/home/joe
----
Using v4 the following would work:
[source,]
----
mount -t nfs4 server:/ /mnt/home
ls /mnt/home/joe
----
The difference being "server:/home" and "server:/". To make the exports configurations compatible for all version, one needs to export (read only) the root filesystem with an fsid=0. The fsid=0 signals the NFS server that this export is the root.
[source,]
----
/ *(ro,fsid=0)
/home *(rw,sync,nohide)
----
Now with these exports, both "mount server:/home /mnt/home" and "mount -t nfs server:/home /mnt/home" will work as expected.
== Testing the configuration
On client side:
[source,]
----
[…]# showmount -e 192.168.12.200
----
On client side, try to mount an exported subdirectory:
[source,]
----
[…]# mount 192.168.1.200:/nfsfileshare /mnt/nfsfileshare
----
Display the active mounts
[source,]
----
[…]# mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
192.168.12.5:/nfsfileshare on /mnt/nfsfileshare type nfs4 (rw,relatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.12.7,local_lock=none,addr=192.168.12.5)
----
Check if the NFS mount is writable
[source,]
----
[…]# touch /mnt/nfsfileshare/test
----
== Adding user identification and encryption (NFS 4)
TBD
== Further reading
* Upstream documentation: http://linux-nfs.org/wiki/index.php/Main_Page
* Linux manual page: https://man7.org/linux/man-pages/man5/exports.5.html

0
modules/ROOT/pages/tutorials/imagefactory.adoc Executable file → Normal file
View file

View file

@ -1,8 +1,8 @@
= Installing Fedora Server Edition as a Virtual Machine using Proxmox Virtual Environment
Paul Maconi
:page-authors: {author}, {author_2}
:revnumber: F41
:revdate: 2024-11-10
:revnumber: F44
:revdate: 2026-07-04
:page-aliases: pages/virtualization-vm-install-fedoraserver-cockpit.adoc
@ -14,7 +14,7 @@ Paul Maconi
//
//These documents are not approved yet and may be incomplete and/or incorrect. You would probably prefer to study the https://docs.stg.fedoraproject.org/en-US/fedora-server/[published documentation].
// *Status of this document*: Updated to f41.
// *Status of this document*: Updated to F44, updated screenshots, changed console blocks to match current style.
//====
@ -46,14 +46,14 @@ Before we create the VM, we will need to find and upload our disk image to the P
Once you create a directory to house your disk images, you will need to upload the disk image file via scp into the Proxmox node. `scp [image_filename] root@[node_name]:/path/to/images/[image_filename]`
[,shell]
[source,console]
----
aggraxis@whirlwind:~$ cd Desktop/osimages/
aggraxis@whirlwind:~/Desktop/osimages$ ls
Fedora-Server-KVM-41-1.4.x86_64.qcow2
aggraxis@whirlwind:~/Desktop/osimages$ ssh root@pve-m-0
$ cd Desktop/osimages/
$ ls
Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2
$ ssh root@pve-m-0
root@pve-m-0's password:
Linux pve-m-0 6.8.12-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-2 (2024-09-05T10:03Z) x86_64
Linux pve-m-0 7.0.12-1-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.12-1 (2026-06-09T21:07Z) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
@ -61,34 +61,36 @@ individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Nov 9 11:03:50 2024
root@pve-m-0:~# ls -alh /mnt/pve/nfs-kraken/osimages/
drwxrwxrwx 1 1026 users 462 Nov 11 08:20 .
drwxrwxrwx 1 root root 294 Apr 16 2024 ..
-rwxrwxrwx 1 1026 users 1.6G Apr 20 2024 fedora-coreos-39.20240322.3.1-qemu.x86_64.qcow2
-rwxrwxrwx 1 1026 users 1.6G May 9 2024 fedora-coreos-40.20240416.3.1-qemu.x86_64.qcow2
-rwxrwxrwx 1 1026 users 574M Apr 16 2024 Fedora-Server-KVM-39-1.5.x86_64.qcow2
-rwxrwxrwx 1 1026 users 629M Apr 24 2024 Fedora-Server-KVM-40-1.14.x86_64.qcow2
-rwxrwxrwx 1 1027 users 913M Aug 30 13:44 rhel-9.4-x86_64-kvm.qcow2
root@pve-m-0:~# exit
Last login: Sat Jul 4 09:20:08 2026 from [ip]
# ls -alh /mnt/pve/nfs-kraken/osimages
total 4.5G
drwxrwxrwx 1 1026 users 518 May 15 14:10 .
drwxrwxrwx 1 root root 128 Oct 22 2025 ..
-rwxrwxrwx 1 1024 users 508M Apr 9 2025 Fedora-Cloud-Base-Generic-42-1.1.x86_64.qcow2
-rwxrwxrwx 1 1027 users 555M Oct 22 2025 Fedora-Cloud-Base-Generic-43-1.5.x86_64.qcow2
-rwxrwxrwx 1 1027 users 557M Apr 22 17:57 Fedora-Cloud-Base-Generic-44.x86_64.qcow2
-rwxrwxrwx 1 1027 users 602M May 15 14:09 Fedora-Cloud-Base-UEFI-UKI-44-1.7.x86_64.qcow2
-rwxrwxrwx 1 1024 users 591M Aug 5 2025 noble-server-cloudimg-amd64.img
-rwxrwxrwx 1 1027 users 816M May 14 2025 rhel-10.0-x86_64-kvm.qcow2
-rwxrwxrwx 1 1027 users 913M Aug 30 2024 rhel-9.4-x86_64-kvm.qcow2
# exit
logout
Connection to pve-m-0 closed.
aggraxis@whirlwind:~/Desktop/osimages$ scp Fedora-Server-KVM-41-1.4.x86_64.qcow2 \
root@pve-m-0:/mnt/pve/nfs-kraken/osimages/Fedora-Server-KVM-41-1.4.x86_64.qcow2
$ scp Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2 \
root@pve-m-0:/mnt/pve/nfs-kraken/osimages/Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2
root@pve-m-0's password:
Fedora-Server-KVM-41-1.4.x86_64.qcow2 100% 659MB 110.7MB/s 00:05
aggraxis@whirlwind:~/Desktop/osimages$
----
=== Verify the image is in place
While not completely necessary, we logged back in to the Proxmox node and verified that the file had actually uploaded to the target directory. We'll come back to this path later when it is time to import the disk image to a VM.
[,shell]
[source,console]
----
aggraxis@whirlwind:~/Desktop/osimages$ ssh root@pve-m-0
$ ssh root@pve-m-0
root@pve-m-0's password:
Linux pve-m-0 6.8.12-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-2 (2024-09-05T10:03Z) x86_64
Linux pve-m-0 7.0.12-1-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.12-1 (2026-06-09T21:07Z) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
@ -96,18 +98,21 @@ individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 11 08:18:31 2024 from 192.168.218.217
root@pve-m-0:~# ls -alh /mnt/pve/nfs-kraken/osimages/
total 5.8G
drwxrwxrwx 1 1026 users 462 Nov 11 08:20 .
drwxrwxrwx 1 root root 294 Apr 16 2024 ..
-rwxrwxrwx 1 1026 users 1.6G Apr 20 2024 fedora-coreos-39.20240322.3.1-qemu.x86_64.qcow2
-rwxrwxrwx 1 1026 users 1.6G May 9 2024 fedora-coreos-40.20240416.3.1-qemu.x86_64.qcow2
-rwxrwxrwx 1 1026 users 574M Apr 16 2024 Fedora-Server-KVM-39-1.5.x86_64.qcow2
-rwxrwxrwx 1 1026 users 629M Apr 24 2024 Fedora-Server-KVM-40-1.14.x86_64.qcow2
-rwxrwxrwx 1 1024 users 660M Nov 11 08:20 Fedora-Server-KVM-41-1.4.x86_64.qcow2
-rwxrwxrwx 1 1027 users 913M Aug 30 13:44 rhel-9.4-x86_64-kvm.qcow2
root@pve-m-0:~#
Last login: Sat Jul 4 09:24:04 2026 from [ip]
# ls -alh /mnt/pve/nfs-kraken/osimages/
total 5.4G
drwxrwxrwx 1 1026 users 612 Jul 4 09:25 .
drwxrwxrwx 1 root root 128 Oct 22 2025 ..
-rwxrwxrwx 1 1024 users 508M Apr 9 2025 Fedora-Cloud-Base-Generic-42-1.1.x86_64.qcow2
-rwxrwxrwx 1 1027 users 555M Oct 22 2025 Fedora-Cloud-Base-Generic-43-1.5.x86_64.qcow2
-rwxrwxrwx 1 1027 users 557M Apr 22 17:57 Fedora-Cloud-Base-Generic-44.x86_64.qcow2
-rwxrwxrwx 1 1027 users 602M May 15 14:09 Fedora-Cloud-Base-UEFI-UKI-44-1.7.x86_64.qcow2
-rwxrwxrwx 1 1024 users 909M Jul 4 09:25 Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2
-rwxrwxrwx 1 1024 users 591M Aug 5 2025 noble-server-cloudimg-amd64.img
-rwxrwxrwx 1 1027 users 816M May 14 2025 rhel-10.0-x86_64-kvm.qcow2
-rwxrwxrwx 1 1027 users 913M Aug 30 2024 rhel-9.4-x86_64-kvm.qcow2
#
----
=== VM Creation: General
@ -190,31 +195,29 @@ Now that the VM itself has been built, we need to log in to the Proxmox node via
*** The format may vary depending on where you are storing the VM. The test articule uses an NFS mount, and qcow2 formatted images are preferred in this usage scenario.
[,shell]
[source,console]
----
root@pve-m-0:~# cd /mnt/pve/nfs-kraken/osimages/
root@pve-m-0:/mnt/pve/nfs-kraken/osimages# qm disk import 106 \
Fedora-Server-KVM-41-1.4.x86_64.qcow2 nfs-kraken --format qcow2
importing disk 'Fedora-Server-KVM-41-1.4.x86_64.qcow2' to VM 106 ...
Formatting '/mnt/pve/nfs-kraken/images/106/vm-106-disk-1.qcow2',
fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata
compression_type=zlib size=7516192768 lazy_refcounts=off
refcount_bits=16
transferred 0.0 B of 7.0 GiB (0.00%)
transferred 76.7 MiB of 7.0 GiB (1.07%)
transferred 148.4 MiB of 7.0 GiB (2.07%)
# cd /mnt/pve/nfs-kraken/osimages/
# qm disk import 127 \
Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2 nfs-kraken --format qcow2
importing disk 'Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2' to VM 127 ...
Formatting '/mnt/pve/nfs-kraken/images/127/vm-127-disk-0.qcow2', fmt=qcow2
cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib
size=10737418240 lazy_refcounts=off refcount_bits=16
transferred 0.0 B of 10.0 GiB (0.00%)
transferred 102.4 MiB of 10.0 GiB (1.00%)
transferred 206.8 MiB of 10.0 GiB (2.02%)
--SNIP--
transferred 7.0 GiB of 7.0 GiB (99.33%)
transferred 7.0 GiB of 7.0 GiB (100.00%)
transferred 7.0 GiB of 7.0 GiB (100.00%)
Successfully imported disk as 'unused0:nfs-kraken:106/vm-106-disk-1.qcow2'
root@pve-m-0:/mnt/pve/nfs-kraken/osimages#
transferred 9.8 GiB of 10.0 GiB (98.26%)
transferred 9.9 GiB of 10.0 GiB (99.26%)
transferred 10.0 GiB of 10.0 GiB (100.00%)
transferred 10.0 GiB of 10.0 GiB (100.00%)
unused0: successfully imported disk 'nfs-kraken:127/vm-127-disk-0.qcow2'
#
----
When the import process finishes you should get a success message like the one shown above. This process was done on a storage array with rotational hard disks, and it still only took a few seconds to complete.
=== VM Configuration: Disk
Now that the disk is part of the VM, we can go back to the hardware tab, highlight the new unused disk, and click edit. You shouldn't need to change anything and can safely just click `Add`.