Review of Netcup ARM G11 VPS in Manassas, VA USA! -- Does @imok have the world's best VPS?

Comments

• imok OG

  January 6

  Lol

  Thanks for the review, it express the same way I feel.

  Not the fastest disk, but speed seems fine for a SSD.

  This is going to be a PBS server if I manage to run it on ARM.

  Thanked by (2)Not_Oles Blembim
• Blembim

  January 6 edited January 6

  I already let mine go, since they no longer provide SVM flag for their services.

  
  thank you for your inquiry.

  Please excuse our late reply due to the current very high volume of inquiries.

  In our experience, nested virtualization via the SVM flag can lead to technical problems at processor level. Since the servers we rent out are fully virtualized, such problems affect all customers on the same node equally. For this reason, as well as for security reasons, we can no longer offer you the activation of the SVM flag for any of our products.
  

  Thanked by (2)Not_Oles wankel
• wankel OG

  January 6

  Thanks for the write-up!

  @imok , please do report your experiences with (the after all these years still unofficial) Proxmox on ARM!

  Thanked by (2)imok Not_Oles
• techdragon

  January 6 edited January 6

  From the YABS posted, the disk seems a bit underwhelming.

  Oracle Free Tier isn't far off. Taking into account ARM. 4CPU, 24GB RAM, 200GB.

  Thanked by (1)Not_Oles
• perryoo11 OG

  January 6 edited January 6

  (#)imentionedimok13times Discount coupon soon?

  Thanked by (1)Not_Oles
• legolaslx

  January 6 edited January 6

  I am using VPS ServaRica, some times CPU overload, please help me compare VPS 3000 ARM G11 and ServaRica - UniFied Slim ($14/month). Thanks you.

  # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
  #              Yet-Another-Bench-Script              #
  #                     v2025-01-01                    #
  # https://github.com/masonr/yet-another-bench-script #
  # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
  
  Mon Jan  6 04:49:10 PM UTC 2025
  
  Basic System Information:
  ---------------------------------
  Uptime     : 1 days, 22 hours, 25 minutes
  Processor  : AMD EPYC 7551P 32-Core Processor
  CPU cores  : 8 @ 1996.250 MHz
  AES-NI     : ✔ Enabled
  VM-x/AMD-V : ❌ Disabled
  RAM        : 31.3 GiB
  Swap       : 0.0 KiB
  Disk       : 984.2 GiB
  Distro     : Ubuntu 22.04.1 LTS
  Kernel     : 5.15.0-130-generic
  VM Type    : XEN
  IPv4/IPv6  : ✔ Online / ❌ Offline
  
  IPv4 Network Information:
  ---------------------------------
  ISP        : Rica Web Services
  ASN        : AS26832 Rica Web Services
  Host       : Rica Web Services
  Location   : Montreal, Quebec (QC)
  Country    : Canada
  
  fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mapper/unified--nvme-main):
  ---------------------------------
  Block Size | 4k            (IOPS) | 64k           (IOPS)
    ------   | ---            ----  | ----           ----
  Read       | 31.79 MB/s    (7.9k) | 197.96 MB/s   (3.0k)
  Write      | 31.83 MB/s    (7.9k) | 199.00 MB/s   (3.1k)
  Total      | 63.62 MB/s   (15.9k) | 396.96 MB/s   (6.2k)
             |                      |
  Block Size | 512k          (IOPS) | 1m            (IOPS)
    ------   | ---            ----  | ----           ----
  Read       | 258.59 MB/s    (505) | 285.33 MB/s    (278)
  Write      | 272.33 MB/s    (531) | 304.33 MB/s    (297)
  Total      | 530.92 MB/s   (1.0k) | 589.66 MB/s    (575)
  
  iperf3 Network Speed Tests (IPv4):
  ---------------------------------
  Provider        | Location (Link)           | Send Speed      | Recv Speed      | Ping
  -----           | -----                     | ----            | ----            | ----
  Clouvider       | London, UK (10G)          | 231 Mbits/sec   | 592 Mbits/sec   | 79.4 ms
  Eranium         | Amsterdam, NL (100G)      | 235 Mbits/sec   | 2.00 Gbits/sec  | 80.6 ms
  Uztelecom       | Tashkent, UZ (10G)        | 212 Mbits/sec   | 442 Mbits/sec   | 167 ms
  Leaseweb        | Singapore, SG (10G)       | 189 Mbits/sec   | 618 Mbits/sec   | 246 ms
  Clouvider       | Los Angeles, CA, US (10G) | 221 Mbits/sec   | 435 Mbits/sec   | 81.6 ms
  Leaseweb        | NYC, NY, US (10G)         | 252 Mbits/sec   | 1.74 Gbits/sec  | 9.69 ms
  Edgoo           | Sao Paulo, BR (1G)        | 218 Mbits/sec   | 608 Mbits/sec   | 152 ms
  
  Geekbench 6 Benchmark Test:
  ---------------------------------
  Test            | Value
                  |
  Single Core     | 767
  Multi Core      | 3411
  Full Test       | https://browser.geekbench.com/v6/cpu/9796715
  
• ralf

  January 6

  As for how @imok got the better server at the higher price, I think I can guess!

  Even though the Advent Calendar only mentioned the 6 core version, there was a link at the bottom of the text that took you to the bigger one and a similar discount had been applied. I can't remember exactly, but it probably was around the €9 he got it for.

  I regret not grabbing this server as I really want some ARM servers that aren't at risk of just disappearing like my free Oracle instances might. I wasted too much time trying to figure out if the price was for IPv6 only or not, as it didn't mention IPv4 in the specs and had an option to add "Extra IPv4". In the end it was 1am, and I decided to go to bed and buy it in the morning, but of course I slept past the cut-off time.

  Thanked by (1)Not_Oles
• imok OG

  January 6

  Yes, that's exactly how it happened.

  Thanked by (1)Not_Oles
• Not_Oles Hosting ProviderContent Writer

  January 7

  @ralf Looks like our experiences are similar both with Oracle and with Netcup!

  @ralf said: risk of just disappearing like my free Oracle instances might

  After many months of enjoying my Oracle free VPS, there came one week when, due to switching laptops to facilitate 2FA, I went an extra day or maybe two without logging in. Haha, I received the termination notice email, so I deleted everything and gave up on Oracle.

  @ralf said: I decided to go to bed

  Again, haha, exactly what happened to me, several times, when I was trying to buy from Netcup. IMHO, Netcup's product selection, ordering, and new account initialization process is too complicated. But, in general, they seem to know very well what they are doing, and their VPS works great.

  Thanked by (1)ralf

  I hope everyone gets the servers they want!
• Not_Oles Hosting ProviderContent Writer

  January 7

  @techdragon said:
  From the YABS posted, the disk seems a bit underwhelming.

  Oracle Free Tier isn't far off. Taking into account ARM. 4CPU, 24GB RAM, 200GB.

  Thanks for mentioning Oracle Free Tier! I had forgotten about them. You certainly are right that Oracle Free Tier ARM is similar to Netcup. Hetzner Cloud has ARM too.

  I hope everyone gets the servers they want!
• terrorgen OG

  January 8

  You have been visiting MX for a loooooooooong time, @Not_Oles!

  Thanked by (1)Not_Oles

  The all seeing eye sees everything...
• adly

  January 9 edited January 9

  @Not_Oles said:
  Nested virtualization (VM-x/AMD-V) to set up more fast KVM VPSes inside the main VPS is not enabled.

  It’s not that it’s not enabled, it’s that hardware support for nested virtualisation was only really added in ARMv8.4+, and the Altra Max CPU used by Netcup is only ARMv8.2 compatible.

  Thanked by (1)Not_Oles
• imok OG

  January 11

  are the cores dedicated?

  Thanked by (1)Not_Oles
• grasple

  January 11

  @imok said:
  are the cores dedicated?

  No, that’s their other, slightly more expensive product: https://www.netcup.com/en/server/root-server

  Thanked by (2)Not_Oles imok
• Not_Oles Hosting ProviderContent Writer

  January 11 edited January 11

  @adly said:

  @Not_Oles said:
  Nested virtualization (VM-x/AMD-V) to set up more fast KVM VPSes inside the main VPS is not enabled.

  It’s not that it’s not enabled, it’s that hardware support for nested virtualisation was only really added in ARMv8.4+, and the Altra Max CPU used by Netcup is only ARMv8.2 compatible.

  I've been trying to understand. It's complicated. For example, how should I understand "really added"?

  At https://developer.arm.com/documentation/102142/0100/Nested-virtualization it says, "Before the release of Armv8.3-A, it was possible to run a Guest Hypervisor in a VM by running the Guest Hypervisor in EL0."

  At [2017] it says "ARM recently introduced nested virtualization support in the latest ARMv8.3 revision of the architecture." [I haven't watched the video yet.]

  So nested virtualization on ARM was supported prior to ARMv8.3-A by ELO, but was "introduced in ARMv8.3", but was "only really added in ARMv8.4+."

  Checking https://developer.arm.com/documentation/102142/0100/Nested-virtualization seems not to explain how to check exactly which processor features are available in a given, running Linux instance.

  Here is the beginning of the lscpu output on my Netcup ARM VPS:

  root@manassas:~# lscpu
  Architecture:             aarch64
    CPU op-mode(s):         32-bit, 64-bit
    Byte Order:             Little Endian
  CPU(s):                   6
    On-line CPU(s) list:    0-5
  Vendor ID:                ARM
    BIOS Vendor ID:         QEMU
    Model name:             Neoverse-N1
      BIOS Model name:      virt-6.2  CPU @ 2.0GHz
      BIOS CPU family:      1
      Model:                1
      Thread(s) per core:   1
      Core(s) per cluster:  1
      Socket(s):            6
      Cluster(s):           6
      Stepping:             r3p1
      BogoMIPS:             50.00
      Flags:                fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid as
                            imdrdm lrcpc dcpop asimddp
  

  What do the Flags say when nested virtualization is enabled? [I tried searching Google for '"lscpu" "Flags" "arm" "nested virtualization"' and other more simple queries, but those searches did not seem to give useful results.]

  How should we understand the seemingly bumpy "implementation and reimplementation" of nested virtualization on ARM?

  Thanks!

  I hope everyone gets the servers they want!
• Not_Oles Hosting ProviderContent Writer

  January 11

  @Not_Oles said: What do the Flags say when nested virtualization is enabled? [I tried searching Google for '"lscpu" "Flags" "arm" "nested virtualization"' and other more simple queries, but those searches did not seem to give useful results.]

  How should we understand the seemingly bumpy "implementation and reimplementation" of nested virtualization on ARM?

  Thanks!

  I had a 258 line discussion with Google Gemini on the basis of which I think I might have received a few helpful hints about the answers to the questions I asked above. Here it is, in case anybody might be interested:

  chronos@penguin:~/gemini-cli$ cat 20250111-arm-virtualization
  chronos@penguin:~/gemini-cli$ cat commands
  export PATH=$PATH:/usr/local/go/bin:/home/chronos/go/bin
  export GEMINI_API_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  script -T timing
  gemini-cli chat --model "gemini-1.5-pro-latest"
  $load <file path>
  chronos@penguin:~/gemini-cli$ gemini-cli chat --model "gemini-1.5-pro-latest"
  Chatting with gemini-1.5-pro-latest
  Type 'exit' or 'quit' to exit, or '$load <file path>' to load a file
  > $load post-7-ARM-nested-virtualization
  
  Hello!
  
  What does each letter stand for in the following acronyms taken from the discussion of ARM architecture nested virtualization at https://developer.arm.com/documentation/102142/0100/Nested-virtualization ? I am guessing that "NV" stands for "Nested Virtualization."
  
  HCR_EL2.NV
  HCR_EL2.NV1
  HCR_EL2.NV2
  VNCR_EL2 
  
  What does it mean when the page says "Armv8.3-A added the NV and NV1 controls." What are the NV and NV1 controls? 
  
  Thanks!
  You're correct, NV generally stands for Nested Virtualization in this context. Let's break down the acronyms:
  
  * **HCR_EL2.NV:**  Hypervisor Configuration Register at Exception Level 2, Nested Virtualization bit.  This single bit in the HCR_EL2 register controls basic nested virtualization support.
  
  * **HCR_EL2.NV1:** Hypervisor Configuration Register at Exception Level 2, Nested Virtualization bit 1. This bit provides more granular control over certain aspects of nested virtualization, specifically related to stage 2 translation (the guest hypervisor's address translation).
  
  * **HCR_EL2.NV2:** Hypervisor Configuration Register at Exception Level 2, Nested Virtualization bit 2. This bit offers further refinements for nested virtualization, usually concerning how exceptions are routed and handled in a nested environment.
  
  * **VNCR_EL2:**  Virtual Nested Control Register at Exception Level 2.  This register provides additional configuration options for nested virtualization beyond the individual bits in HCR_EL2.
  
  
  **"Armv8.3-A added the NV and NV1 controls"** means that before the Armv8.3-A architecture revision, hardware support for nested virtualization was either limited or nonexistent. The introduction of the NV (in HCR_EL2) and NV1 (also in HCR_EL2) bits in Armv8.3-A marked a significant improvement. These controls allow for more efficient and streamlined nested virtualization, reducing software overhead and improving performance.  Before Armv8.3-A, similar functionality might have been achieved through complex software workarounds, or nested virtualization might have been severely restricted.
  
  Specifically, the `NV` control provides basic enablement of Nested Virtualization, allowing the guest hypervisor to use stage-2 translation without interference from the host hypervisor. The `NV1` control provides more fine-grained control over stage-2 address translation, particularly related to the handling of certain instructions and system registers within the nested environment. This finer control minimizes the need for the host hypervisor to trap and emulate these instructions or register accesses, leading to better performance in the nested guest.
  
  Therefore, the addition of `NV` and `NV1` controls in Armv8.3-A represented a crucial step forward in hardware-assisted nested virtualization, making it more efficient and practical.  NV2 and the VNCR_EL2 register typically provide even more advanced controls, often added in later architecture versions (v8.4 and beyond) to further optimize and refine nested virtualization support.
  > What is "stage-2 address translation?"
  In nested virtualization, you have two levels of hypervisors:
  
  1. **Host Hypervisor (VMM1):**  This is the primary hypervisor that runs directly on the physical hardware.
  2. **Guest Hypervisor (VMM2):** This hypervisor runs as a virtual machine *under* the host hypervisor.  It believes it's running on physical hardware, but it's actually being virtualized.
  
  Each hypervisor manages its own address translation:
  
  * **Stage-1 Address Translation:** Performed by the *host* hypervisor (VMM1).  It translates guest virtual addresses (GVAs) used by normal VMs to intermediate physical addresses (IPAs).  These IPAs are not true physical addresses but addresses within the memory space managed by the host hypervisor.
  
  * **Stage-2 Address Translation:** Performed by the *guest* hypervisor (VMM2).  It translates the GVAs used by the VMs running *inside* the guest hypervisor to intermediate physical addresses (IPAs) which are then further translated by the stage-1 of the host hypervisor. This second stage is necessary because the guest hypervisor needs to manage its own virtual machines just like the host hypervisor manages its virtual machines.
  
  
  **In essence:**  Stage-2 translation is the address translation performed *within* a nested virtualization environment by the guest hypervisor.  It's like a virtualization layer within a virtualization layer.  The guest hypervisor, unaware it's being virtualized, performs address translation as if it were running on bare metal.
  
  
  **Example:**
  
  Imagine a VM running inside a guest hypervisor, which is itself running on a host hypervisor.
  
  1. The VM attempts to access memory using a GVA.
  2. The *guest* hypervisor (VMM2) intercepts this access and performs stage-2 translation, converting the GVA to an IPA.
  3. This IPA is still a virtual address from the perspective of the *host* hypervisor (VMM1).
  4. The *host* hypervisor intercepts the access again and performs stage-1 translation, converting the IPA from stage-2 into a true physical address that can be accessed on the hardware.
  
  
  The NV and NV1 controls in Armv8.3-A are designed to make this two-stage translation process more efficient.  They enable hardware assistance for stage-2 translation, so the host hypervisor doesn't have to constantly trap and emulate the guest hypervisor's memory management operations. This greatly improves the performance of VMs running within nested virtualization environments.
  > What are the ARM assembly language instructions related to HCR_EL2 and VNCR_EL2?
  The ARM assembly language instructions related to HCR_EL2 and VNCR_EL2 primarily involve the `MRS` (Move System Register to general-purpose register) and `MSR` (Move general-purpose register to System Register) instructions.  These instructions allow you to read and write the values of system registers, including HCR_EL2 and VNCR_EL2.
  
  Here's a breakdown:
  
  **Reading HCR_EL2:**
  
  ```assembly
  MRS <Xt>, HCR_EL2
  ```
  
  * `<Xt>` represents the 64-bit general-purpose register where the value of HCR_EL2 will be stored.
  
  **Writing to HCR_EL2:**
  
  ```assembly
  MSR HCR_EL2, <Xt>
  ```
  
  * `<Xt>` represents the 64-bit general-purpose register containing the value you want to write to HCR_EL2.
  
  **Reading VNCR_EL2:**
  
  ```assembly
  MRS <Xt>, VNCR_EL2
  ```
  
  * `<Xt>` represents the 64-bit general-purpose register where the value of VNCR_EL2 will be stored.
  
  
  **Writing to VNCR_EL2:**
  
  ```assembly
  MSR VNCR_EL2, <Xt>
  ```
  
  * `<Xt>` represents the 64-bit general-purpose register containing the value you want to write to VNCR_EL2.
  
  
  **Important Considerations:**
  
  * **Privilege Level:** These instructions must be executed at the appropriate exception level (EL2 in this case).  Attempting to access these registers from a lower exception level will result in an exception.
  * **Implementation Defined Behavior:** The specific behavior of some bits within these registers might be implementation defined, meaning they can vary across different ARM processors. Consult the relevant architecture reference manual for the specific processor you are working with.
  * **System Register Access Restrictions:** Certain system registers might have access restrictions even at the correct exception level.  For instance, some bits might be read-only or require specific conditions to be met before they can be modified.
  * **Context Switching:** When dealing with virtualization, be mindful of the context you are operating in (host hypervisor or guest hypervisor).  Incorrectly modifying these registers can have significant consequences for system stability.
  
  **Example (Setting the NV bit in HCR_EL2):**
  
  ```assembly
  MRS     X0, HCR_EL2        // Read the current value of HCR_EL2 into X0
  ORR     X0, X0, #(1 << 55) // Set the NV bit (bit 55) in X0
  MSR     HCR_EL2, X0        // Write the modified value back to HCR_EL2
  ```
  
  This example shows how to set the NV bit in HCR_EL2.  Similar logic can be used to modify other bits in HCR_EL2 or VNCR_EL2.  Always consult the ARM architecture reference manual for the specific bit positions and their meanings. Remember to handle potential reserved bits carefully.  Writing to reserved bits can have unpredictable consequences.
  > What do the lscpu flags say on ARM when nested virtualization is enabled?
  Unfortunately, there's no single, standardized `lscpu` flag that directly indicates whether nested virtualization is *enabled*.  `lscpu` is primarily a Linux tool, and its output reflects what the Linux kernel sees, not necessarily the detailed configuration of the underlying hardware.  While the presence of certain features might suggest the *capability* for nested virtualization, whether it's actively enabled depends on runtime settings within the hypervisors.
  
  Here's what you can look for and why it's not a definitive "enabled" indicator:
  
  * **Virtualization:** `lscpu` will show virtualization features that the kernel is aware of.  Look for flags like:
      * `Virtualization: <type>` where `<type>` might be `kvm` or something similar, indicating kernel-based virtual machine support.  This suggests the *potential* for nested virtualization, but doesn't confirm it's actively used.
      * Specific extensions, potentially including things related to virtualization.  However, these again indicate *capability*, not necessarily current activation.
  
  * **Architecture:**  The architecture information is crucial. You'll see something like `Architecture: aarch64`. The architecture version (e.g., Armv8.1-A, Armv8.3-A, or later) will indicate if the hardware *supports* the necessary features for nested virtualization.  Armv8.3-A and later introduce the critical NV controls.
  
  * **CPU Flags:** While not directly an "enabled" flag, the presence of virtualization-related flags within the `Flags` section of `lscpu` output hints at the processor's capabilities. However, it does not confirm active usage of nested virtualization.
  
  
  **Why `lscpu` Isn't Sufficient:**
  
  * **Hypervisor Configuration:** Enabling nested virtualization typically involves setting specific bits in system registers (like HCR_EL2) within the *host* hypervisor.  `lscpu`, running within a guest OS, won't have direct access to these registers.
  * **Runtime Configuration:** Nested virtualization can be enabled or disabled dynamically by the hypervisors.  `lscpu` provides a snapshot of the system at a particular moment, but it doesn't reflect changes in hypervisor configuration.
  
  **How to Determine if Nested Virtualization is Enabled:**
  
  1. **Hypervisor-Specific Tools:** The most reliable way is to use tools provided by your specific hypervisor.  For example, if you're using KVM, there might be tools or commands within the host environment to check or configure nested virtualization settings.  Look for documentation related to your particular hypervisor.
  
  2. **Guest Hypervisor Behavior:** Observe the behavior of the guest hypervisor. If it can successfully create and manage its own virtual machines, that's a strong indication nested virtualization is functioning.
  
  3. **Low-Level Access (If Possible):** If you have sufficient privileges in the host environment, you could potentially examine the values of system registers like HCR_EL2 directly, but this is usually not practical or recommended in production environments.
  
  
  In summary, `lscpu` provides clues about the *potential* for nested virtualization based on hardware support and kernel features.  However, it doesn't definitively show whether nested virtualization is actively *enabled*.  Rely on hypervisor-specific tools and observation for confirmation.
  > what do these flags mean: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid as imdrdm lrcpc dcpop asimddp
  Those flags represent CPU features and instruction set extensions present on an ARM processor. Here's a breakdown of what each one signifies:
  
  **Floating-Point and Advanced SIMD:**
  
  * **fp:**  Floating-Point unit.  Supports hardware acceleration for floating-point arithmetic operations.
  * **asimd:** Advanced SIMD (Single Instruction, Multiple Data). Enables vector processing for improved performance in multimedia, signal processing, and similar applications.
  * **fphp:**  Half-precision floating-point. Support for 16-bit floating-point operations.
  * **asimdhp:** Half-precision floating-point in Advanced SIMD. Enables vectorized operations on half-precision floating-point data.
  * **asimddp:** Double-precision floating-point in Advanced SIMD. Enables vectorized operations on double-precision floating-point data.
  
  **Security and Cryptography:**
  
  * **aes:**  Advanced Encryption Standard. Hardware support for AES encryption and decryption.
  * **sha1:** Secure Hash Algorithm 1. Hardware acceleration for SHA-1 hashing.
  * **sha2:** Secure Hash Algorithm 2. Hardware acceleration for SHA-2 hashing (including SHA-256, SHA-384, SHA-512).
  * **crc32:** Cyclic Redundancy Check 32. Hardware support for CRC32 checksum calculations.
  
  **Other Features:**
  
  * **evtstrm:** Event Stream.  Used for performance monitoring and tracing.
  * **pmull:** Polynomial Multiply.  Used in cryptography and some other specialized applications.
  * **atomics:**  Support for atomic operations, ensuring data consistency in multi-threaded environments.
  * **cpuid:**  CPU identification. Allows software to identify the specific processor model and features.
  * **asimdrdm:** Rounding Double Multiply Accumulate/Subtract.  Extension for fused multiply-accumulate operations with rounding.
  * **lrcpc:**  Last Branch Record. Feature to help with branch prediction and performance analysis.
  * **dcpop:** Data Cache Prefetch by Offset.  Mechanism for prefetching data into the cache.
  
  **General Notes:**
  
  * These flags usually appear in the output of tools like `/proc/cpuinfo` or `lscpu` on Linux systems.
  * The exact set of flags present will vary depending on the specific ARM processor model and its capabilities.
  * Some flags represent optional extensions, meaning they might not be implemented on all processors.
  * Understanding these flags can be important for software developers who want to optimize their code to take advantage of specific hardware features.
  
  For precise details on any specific flag and its implications, it's always recommended to refer to the official ARM architecture reference manuals for the relevant processor family.
  > Which flags would be added if nested virtualization features were seen by the kernel?
  No specific flags are added to `/proc/cpuinfo` or the output of `lscpu` *solely* to indicate that nested virtualization features are "seen" by the kernel.  The kernel's awareness of nested virtualization capabilities is primarily reflected in the availability of the necessary virtualization extensions and the ability to configure nested virtualization in the hypervisor.
  
  Here's why and what you might observe indirectly:
  
  * **Virtualization Extensions:** The kernel's support for virtualization in general (which is a prerequisite for nested virtualization) is indicated by flags like:
      * `Virtualization: <type>` (e.g., `kvm`)  This confirms the kernel has virtualization capabilities.
      * Flags related to specific hardware virtualization extensions (these vary depending on the architecture).
  
  * **Architecture Version:** The architecture version (e.g., `Architecture: aarch64`, with details on the specific ARMv8.x version) is crucial.  Armv8.3-A and later are required for the hardware features (like the NV controls) that make efficient nested virtualization possible.  The kernel recognizing a compatible architecture is a necessary but not sufficient condition.
  
  * **No "Nested" Flag:** There isn't a dedicated flag explicitly saying "nested virtualization enabled/seen" because the enablement happens at the hypervisor level, not directly within the kernel.
  
  * **Indirect Evidence (KVM):** If you're using KVM, the presence of nested virtualization capabilities might be indirectly reflected in the availability of certain KVM modules or kernel parameters related to nested VM configuration.  However, this still wouldn't be a single, definitive flag.
  
  **Example Scenario:**
  
  Let's say you have a system with an Armv8.4 processor and a kernel compiled with KVM support.  `/proc/cpuinfo` or `lscpu` would likely show:
  
  * `Architecture: aarch64` (and details indicating Armv8.4 or later)
  * `Virtualization: kvm`
  * Various other flags indicating hardware capabilities, including virtualization extensions.
  
  The *absence* of specific error messages or limitations when attempting to configure and run nested VMs within KVM would be the practical confirmation that nested virtualization is supported and functioning.
  
  
  In essence, the kernel's awareness of nested virtualization isn't signaled by a specific flag, but rather by the combination of virtualization support, a compatible architecture, and the successful operation of nested VMs within the hypervisor environment.  Use hypervisor-specific tools for definitive confirmation.
  > Do Intel/AMD VM-x/AMD-V have corresponding flags that show in lscpu output?
  Yes, Intel VT-x and AMD-V have corresponding flags that typically show up in `lscpu` output (and `/proc/cpuinfo`) on systems with those capabilities.
  
  **Intel VT-x:**
  
  * **`vmx`:** This is the primary flag indicating Intel VT-x support.
  
  **AMD-V:**
  
  * **`svm`:** This flag signifies AMD-V (Secure Virtual Machine) support.
  
  **Example (Intel):**
  
  If you run `lscpu` on a system with Intel VT-x, you'll likely see `vmx` listed in the `Flags:` section.
  
  **Example (AMD):**
  
  Similarly, on a system with AMD-V, `svm` would appear in the `Flags:` section of `lscpu` output.
  
  **Important Considerations:**
  
  * **BIOS/UEFI:**  Even if these flags are present, it doesn't guarantee virtualization is *enabled*.  VT-x and AMD-V must be enabled in the system's BIOS or UEFI settings for the kernel and hypervisors to use them.  If they are disabled in the BIOS/UEFI, the flags might still be listed, but virtualization won't function.
  * **Kernel Modules:**  The necessary kernel modules (like `kvm-intel` or `kvm-amd`) must be loaded for the kernel to utilize these hardware virtualization features.
  * **Hypervisor Configuration:**  Ultimately, the hypervisor (e.g., KVM, Xen, VMware) controls the use of these hardware capabilities.
  
  
  So, while the presence of `vmx` or `svm` is a strong indicator of hardware support, always check your BIOS/UEFI settings and ensure the required kernel modules are loaded for virtualization to be fully operational. Just like with ARM and nested virtualization, the CPU flags only indicate the *potential* for virtualization, not its current state of enablement.
  > There's no flag for ARM whoch corresponds to 'vmx' or 'svm'?
  You're essentially correct. There isn't a single, direct equivalent to the `vmx` (Intel VT-x) or `svm` (AMD-V) flags in the `lscpu` output for ARM systems to indicate the basic hardware virtualization capability.
  
  Here's why and what you'll see instead:
  
  * **Virtualization Extensions:** ARM's virtualization support is indicated by a combination of factors, most notably the architecture version and the presence of specific virtualization extensions. These extensions are listed in the `Features` or `Flags` section of `lscpu`, but there's no single overarching flag like `vmx` or `svm`.  Look for extensions related to virtualization, but the specific extensions will vary depending on the ARM architecture version.
  
  * **Architecture Version:**  The architecture version itself (e.g., `Architecture: aarch64` followed by the specific Armv8.x version) is crucial.  Earlier versions of Armv8 might have limited virtualization support, while Armv8.1 and later generally have more comprehensive features.  The architecture version indirectly tells you whether the hardware *could* support virtualization.
  
  * **Virtualization Type:**  You might see a `Virtualization: <type>` entry (e.g., `kvm`, `hvm`). This confirms the kernel's virtualization capabilities but doesn't directly confirm the underlying hardware support in the same way `vmx` or `svm` do for x86.
  
  * **Driver/Module Information:**  In some cases, information about the loaded kernel modules related to virtualization might offer additional clues, but again, no single flag definitively indicates the presence of hardware virtualization in the same way as on x86.
  
  In essence, on ARM, you infer hardware virtualization support from the combination of architecture version, virtualization extensions listed in the flags, and the ability of the kernel and hypervisor to operate correctly.  It's less of a single flag and more of a deduced capability.
  > Okay, very helpful! Thank you! 
  You're welcome! I'm glad I could help clarify this.  ARM's approach to indicating virtualization support is indeed a bit different from the x86 world. If you have any more questions about virtualization or ARM architecture, feel free to ask!
  > exit
  chronos@penguin:~/gemini-cli$ 
  

  I hope everyone gets the servers they want!
• imok OG

  January 11

  @grasple said:

  @imok said:
  are the cores dedicated?

  No, that’s their other, slightly more expensive product: https://www.netcup.com/en/server/root-server

  ok then maybe it's not a good idea to use it as a Plex server
• Not_Oles Hosting ProviderContent Writer

  January 11

  Here is a page about the Neoverse N-1 CPU used in the Netcup G11 VPS:

  https://developer.arm.com/Processors/Neoverse N1

  Quoting from the linked page, it seems like this CPU includes some 8.3+ extensions, but apparently not all the extensions needed for the most efficient nested virtualization:

  Architecture
  Armv8-A (Harvard)

  Extensions
  Armv8.1 extensions
  Armv8.2 extensions
  Cryptography extensions
  RAS extensions
  SPE extensions
  Armv8.3 LDAPR instructions
  Armv8.4 Dot Product instructions
  Armv8.5 (security vulnerabilities mitigations)

  Thanked by (1)adly

  I hope everyone gets the servers they want!
• remy

  January 12 edited January 12

  @adly said:

  @Not_Oles said:
  Nested virtualization (VM-x/AMD-V) to set up more fast KVM VPSes inside the main VPS is not enabled.

  It’s not that it’s not enabled, it’s that hardware support for nested virtualisation was only really added in ARMv8.4+, and the Altra Max CPU used by Netcup is only ARMv8.2 compatible.

  However, Netcup disables nested virtualization, even when hardware supports it.
  With this enabled, netcup would be the perfect choice for most workloads.

  Thanked by (2)Not_Oles adly
• adly

  January 13

  @Not_Oles said:

  @adly said:

  @Not_Oles said:
  Nested virtualization (VM-x/AMD-V) to set up more fast KVM VPSes inside the main VPS is not enabled.

  It’s not that it’s not enabled, it’s that hardware support for nested virtualisation was only really added in ARMv8.4+, and the Altra Max CPU used by Netcup is only ARMv8.2 compatible.

  I've been trying to understand. It's complicated. For example, how should I understand "really added"?

  At https://developer.arm.com/documentation/102142/0100/Nested-virtualization it says, "Before the release of Armv8.3-A, it was possible to run a Guest Hypervisor in a VM by running the Guest Hypervisor in EL0."

  At [2017] it says "ARM recently introduced nested virtualization support in the latest ARMv8.3 revision of the architecture." [I haven't watched the video yet.]

  So nested virtualization on ARM was supported prior to ARMv8.3-A by ELO, but was "introduced in ARMv8.3", but was "only really added in ARMv8.4+."

  Checking https://developer.arm.com/documentation/102142/0100/Nested-virtualization seems not to explain how to check exactly which processor features are available in a given, running Linux instance.

  Here is the beginning of the lscpu output on my Netcup ARM VPS:

  root@manassas:~# lscpu
  Architecture:             aarch64
    CPU op-mode(s):         32-bit, 64-bit
    Byte Order:             Little Endian
  CPU(s):                   6
    On-line CPU(s) list:    0-5
  Vendor ID:                ARM
    BIOS Vendor ID:         QEMU
    Model name:             Neoverse-N1
      BIOS Model name:      virt-6.2  CPU @ 2.0GHz
      BIOS CPU family:      1
      Model:                1
      Thread(s) per core:   1
      Core(s) per cluster:  1
      Socket(s):            6
      Cluster(s):           6
      Stepping:             r3p1
      BogoMIPS:             50.00
      Flags:                fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid as
                            imdrdm lrcpc dcpop asimddp
  

  What do the Flags say when nested virtualization is enabled? [I tried searching Google for '"lscpu" "Flags" "arm" "nested virtualization"' and other more simple queries, but those searches did not seem to give useful results.]

  How should we understand the seemingly bumpy "implementation and reimplementation" of nested virtualization on ARM?

  Thanks!

  In terms of “really added” - KVM added basic support for nested virtualisation with ARMv8.3 (FEAT_NV), which was extended with ARMv8.4 (FEAT.NV2); prior to this it involved software emulation. However, it seems very few (if any) CPUs actually implemented FEAT_NV, but there are some with FEAT_NV2 support (Apple M2+, for example).

  Thanked by (1)Not_Oles
• hornet

  January 13

  imok may have you bested on a couple stats, but you won the monthly cost war!

  

  Thanked by (2)imok Not_Oles