I understand that virtual memory fools the program by displaying more memory than is actually available.

Your wording with "fools" and "display" is inaccurate.

The original motivation for virtual memory was a form of memory management to provide an address space larger than physical memory.
Software could utilize the full address space of the CPU (e.g. 2^32 address space) while the actual installed physical memory was only a fraction of that number.
Large programs could be portable among computers that used virtual memory without imposing huge (installed) memory requirements.
This use of virtual memory was back in the day of mainframe computers and ferrite core memory (which was low-density physically and expensive).

But ultimately it has to map the logical address to the actually physical address. Now how is it increasing the memory?

Virtual memory has evolved from just a technique to provide more address space.
Virtual memory is a key component in providing security to each process in a modern operating systems, so that a process cannot interfere with another process, nor be compromised by another process.
But multiprocessing (do not confuse with multiprocessors) with virtual memory still does provide more apparent memory for the system than physical memory.

Each created process is provided with its own virtual address space, i.e. its own virtual memory.
The amount of physical memory that is actually used (and mapped to the virtual memory) to each process is dynamic. Typically only the virtual memory that contains the code (aka text) and data pages/segments to perform the execution of the process is mapped to physical memory (aka resident in memory).

Nonessential code (because it's not currently executed) and data (because it's not being referenced/processed) does not have to be memory resident all the time. The code and/or data pages/segments can be "swapped out" to the backing store (e.g. swap space or page file on a HDD or SSD), and later "swapped (back) in" as needed (aka "on demand").

Virtual memory facilitates the efficient usage of the finite physical memory among numerous processes, each with its own protected virtual address space. The sum of these virtual memories would typically be larger than the installed physical memory.
The "increased memory" is now from the system perspective, and not just the program perspective.

I understand that virtual memory fools the program by displaying more memory than is actually available.

The original motivation for virtual memory was a form of memory management to provide an address space larger than physical memory.
Software could utilize the full address space of the CPU (e.g. 2^32 address space) while the actual installed physical memory was only a fraction of that number.
Large programs could be portable among computers that used virtual memory without imposing huge (installed) memory requirements.
This use of virtual memory was back in the day of mainframe computers and ferrite core memory (which was low-density physically and expensive).

But ultimately it has to map the logical address to the actually physical address. Now how is it increasing the memory?

Virtual memory has evolved from just a technique to provide more address space for the program.
Virtual memory is a key component in providing security to each process in modern operating systems, so that a process cannot interfere with another process, nor be compromised by another process.
But multiprocessing (do not confuse with multiprocessors) with virtual memory still does provide more apparent memory for the system than physical memory.

Each created process is provided with its own virtual address space, i.e. its own virtual memory.
The amount of physical memory that is actually used (and mapped to the virtual memory) to each process is dynamic. Typically only the virtual memory that contains the code (aka text) and data pages/segments to perform the execution of the process is mapped to physical memory (aka resident in memory).

Nonessential code (because it's not currently executed) and data (because it's not being referenced/processed) does not have to be memory resident all the time. The code and/or data pages/segments can be "swapped out" to the backing store (e.g. swap space or page file on a HDD or SSD), and later "swapped (back) in" as needed (aka "on demand").

Virtual memory facilitates the efficient usage of the finite physical memory among numerous processes, each with its own protected virtual address space. The sum of these virtual memories would typically be larger than the installed physical memory.
The "increased memory" is now from the system perspective, and not just the program perspective.

I understand that virtual memory fools the program by displaying more memory than is actually available.

Your wording with "fools" and "display" is inaccurate.

The original motivation for virtual memory was a form of memory management to provide an address space larger than physical memory.
Software could utilize the full address space of the CPU (e.g. 2^32 address space) while the actual installed physical memory was only a faction of that number.
Large programs could be portable among computers that used virtual memory without imposing huge (installed) memory requirements.
This use of virtual memory was back in the day of mainframe computers and ferrite core memory (which was low-density physically and expensive).

But ultimately it has to map the logical address to the actually physical address. Now how is it increasing the memory?

Virtual memory has evolved from just a technique to provide more address space.
Virtual memory is a key component in providing security to each process in a modern operating systems, so that a process cannot interfere with another process, nor be compromised by another process.
But multiprocessing (do not confuse with multiprocessors) with virtual memory still does provide more apparent memory than physical memory.

Each created process is provided with its own virtual address space, i.e. its own virtual memory.
The amount of physical memory that is actually used (and mapped to the virtual memory) to each process is dynamic. Typically only the virtual memory that contains the code (aka text) and data pages/segments to perform the execution of the process is mapped to physical memory (aka resident in memory).

Nonessential code (because it's not currently executed) and data (because it's not being referenced/processed) does not have to be memory resident all the time. The code and/or data pages/segments can be "swapped out" to the backing store (e.g. swap space or page file on a HDD or SSD), and later "swapped (back) in" as needed (aka "on demand").

Virtual memory facilitates the efficient usage of the finite physical memory among numerous processes, each with its own protected virtual address space. The sum of these virtual memories would typically be larger than the installed physical memory.

I understand that virtual memory fools the program by displaying more memory than is actually available.

Your wording with "fools" and "display" is inaccurate.

The original motivation for virtual memory was a form of memory management to provide an address space larger than physical memory.
Software could utilize the full address space of the CPU (e.g. 2^32 address space) while the actual installed physical memory was only a fraction of that number.
Large programs could be portable among computers that used virtual memory without imposing huge (installed) memory requirements.
This use of virtual memory was back in the day of mainframe computers and ferrite core memory (which was low-density physically and expensive).

But ultimately it has to map the logical address to the actually physical address. Now how is it increasing the memory?

Virtual memory has evolved from just a technique to provide more address space.
Virtual memory is a key component in providing security to each process in a modern operating systems, so that a process cannot interfere with another process, nor be compromised by another process.
But multiprocessing (do not confuse with multiprocessors) with virtual memory still does provide more apparent memory for the system than physical memory.

Each created process is provided with its own virtual address space, i.e. its own virtual memory.
The amount of physical memory that is actually used (and mapped to the virtual memory) to each process is dynamic. Typically only the virtual memory that contains the code (aka text) and data pages/segments to perform the execution of the process is mapped to physical memory (aka resident in memory).

Nonessential code (because it's not currently executed) and data (because it's not being referenced/processed) does not have to be memory resident all the time. The code and/or data pages/segments can be "swapped out" to the backing store (e.g. swap space or page file on a HDD or SSD), and later "swapped (back) in" as needed (aka "on demand").

Virtual memory facilitates the efficient usage of the finite physical memory among numerous processes, each with its own protected virtual address space. The sum of these virtual memories would typically be larger than the installed physical memory.
The "increased memory" is now from the system perspective, and not just the program perspective.