Stories with Tag KVM

• How to Install Windows NT 4 Server on Proxmox

  permalink

  Posted: 2025-05-25 01:34:54

  Verbose tl;dr

  This blog post details how to install Windows NT 4.0 Server within a Proxmox virtual machine. The process involves creating a new VM in Proxmox, using an IDE hard disk and a legacy network card. Crucially, the installation requires a modified Windows NT 4.0 ISO image with updated drivers to support the virtualized environment. The author provides a download link to a pre-patched ISO, simplifying the process. After configuring the VM and attaching the ISO, the standard Windows NT 4.0 installation process is followed within the Proxmox console. The post also briefly covers installing the guest agent for enhanced integration with Proxmox.

  This blog post details the process of installing Windows NT 4.0 Server within a Proxmox Virtual Environment (VE), a task complicated by the age of the operating system and its incompatibility with modern virtualization features. The author emphasizes the necessity of this process for specific legacy applications and outlines a methodical approach leveraging a physical machine as an intermediary.

  First, the author explains the challenge: Windows NT 4.0 lacks the necessary drivers for Proxmox's default virtual hardware. Therefore, a direct installation within a Proxmox VE is not feasible. To circumvent this, a physical machine with an IDE hard drive is utilized. The author specifies using a compact flash (CF) to IDE adapter for convenience and potential future use with other vintage operating systems.

  The installation process begins on the physical machine. Windows NT 4.0 Server is installed onto the IDE hard drive connected via the CF adapter. Crucially, the author recommends installing only the base operating system and necessary drivers during this initial setup, postponing the installation of additional services or applications.

  Once the basic NT 4.0 installation is complete on the physical machine, the system is shut down. The CF card, now containing the installed operating system, is removed and connected to a machine capable of reading it. Using a disk imaging tool, preferably one that supports raw disk images, the contents of the CF card are copied into a raw image file (.img). The author specifically mentions dd as a suitable tool for this task.

  This raw disk image is then transferred to the Proxmox server. Within the Proxmox web interface, a new Virtual Machine (VM) is created. Critically, the IDE storage type must be selected for the hard disk of this VM. The previously created raw disk image is then added as the hard disk for the newly created VM. The author suggests utilizing the 'qm importdisk' command-line tool for this purpose, providing a specific example of its usage.

  With the virtual hard disk configured, the virtual machine's other settings, such as memory allocation and CPU cores, are adjusted as needed. Finally, the virtual machine is started. Since the operating system was already installed on the physical hardware, it should now boot within the Proxmox VE.

  The author concludes by highlighting that although the initial Windows NT 4.0 installation takes place on physical hardware, subsequent maintenance, such as patching, can be performed directly within the Proxmox VE. This approach leverages the flexibility of virtualization while accommodating the limitations of the legacy operating system. This allows users to maintain and utilize legacy applications dependent on this outdated environment within a modern, virtualized infrastructure.

  • Windows NT 4.0
  • Proxmox
  • Virtualization
  • Installation
  • Server
  • Retrocomputing
  • Legacy OS
  • KVM
  • virtual machine
  • Hypervisor

  Summary of Comments ( 48 )
  https://news.ycombinator.com/item?id=44084885

  Verbose tl;dr

  Several commenters on Hacker News expressed nostalgia for Windows NT 4.0 Server, recalling its stability and simplicity compared to later Windows server versions. Some discussed specific use cases, like running legacy applications or exploring older technologies. Others shared personal anecdotes about their experiences with NT 4.0, highlighting its role in their early IT careers. A few commenters offered tips on the installation process, including workarounds for potential issues and suggestions for optimizing performance within a Proxmox environment. One user pointed out the potential security risks of running such an outdated operating system.

  The Hacker News post "How to Install Windows NT 4 Server on Proxmox" has generated several comments, discussing various aspects of running this legacy operating system in a modern virtualized environment.

  A significant portion of the discussion revolves around the motivations and use cases for such an endeavor. Some users express nostalgia and a desire to revisit a piece of computing history, while others highlight the practical need to maintain legacy systems for compatibility with specific hardware or software. One commenter specifically mentions the necessity of running old scientific equipment that relies on NT 4.

  The technical challenges and solutions related to installing and configuring NT 4 on Proxmox are also discussed. Commenters share their experiences and offer tips, including the importance of using an IDE hard disk image and dealing with driver compatibility issues. A common point of concern is the limited memory addressing capabilities of NT 4, and suggestions are given for configuring the virtual machine accordingly.

  Some comments delve into the broader context of legacy systems and virtualization. One user points out the increasing difficulty of finding suitable hardware for older operating systems and how virtualization provides a valuable solution for preservation and continued use. Another commenter raises the issue of security vulnerabilities in NT 4 and the importance of isolating such systems within a secure environment.

  Several commenters also share anecdotes and personal experiences related to NT 4, reminiscing about its stability and performance characteristics. One comment thread delves into the history of Microsoft operating systems, comparing NT 4 to its predecessors and successors.

  Finally, a few comments touch upon the legal aspects of running NT 4, specifically regarding licensing. One commenter advises ensuring proper licensing compliance before proceeding with the installation.

• AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

  permalink

  Posted: 2025-04-24 06:58:05

  Verbose tl;dr

  AMD has open-sourced their GPU virtualization driver, the Guest Interface Manager (GIM), aiming to improve the performance and security of GPU virtualization on Linux. While initially focused on data center GPUs like the Instinct MI200 series, AMD has confirmed that bringing this technology to Radeon consumer graphics cards is "in the roadmap," though no specific timeframe was given. This move towards open-source allows community contribution and wider adoption of AMD's virtualization solution, potentially leading to better integrated and more efficient virtualized GPU experiences across various platforms.

  Advanced Micro Devices (AMD) has taken a significant step towards enhancing GPU virtualization capabilities by publishing the source code for their Guest Interface Module (GIM), a critical component for mediating communication between virtual machines (VMs) and the physical GPU in a virtualized environment. This move towards open-sourcing the GIM, hosted on GitHub under a permissive MIT license, marks a notable advancement in transparency and community involvement for AMD's virtualization technology. Previously, this crucial piece of software was proprietary and closed-source, limiting accessibility and hindering potential community contributions and scrutiny. By opening the source code, AMD empowers developers and researchers to examine the inner workings of the GIM, potentially leading to improvements in performance, stability, and security. This open approach also fosters greater interoperability and facilitates the integration of the GIM into various virtualization platforms and operating systems.

  While the initial release focuses on their GPU Interface Manager (GIM) component designed for the Xilinx Alveo U50/U200/U250/U280 series of data center accelerators, the announcement strongly hints at broader support for Radeon graphics cards in the future. This is particularly significant as it suggests AMD’s intention to bring similar virtualization capabilities to their consumer-focused GPUs, opening doors for wider adoption of GPU virtualization across various applications, including gaming, content creation, and machine learning in virtualized environments. The roadmap mentioning Radeon GPUs indicates that AMD is actively working towards extending this open-source approach to their gaming and consumer-grade hardware, although specific timelines and details regarding Radeon support remain undisclosed.

  This development represents a substantial contribution to the open-source community and the virtualization ecosystem. By opening the GIM source code, AMD fosters collaboration and accelerates the development of advanced virtualization solutions. This increased transparency allows for peer review, identification of potential vulnerabilities, and ultimately leads to a more robust and secure virtualization environment for AMD hardware. The implications of this open-sourcing are far-reaching, potentially impacting cloud computing, high-performance computing, and even consumer-level applications that leverage GPU virtualization. The move positions AMD competitively in the GPU virtualization market, especially as they embrace open standards and community involvement.

  • AMD
  • GPU
  • Virtualization
  • Open Source
  • Driver
  • Radeon
  • Linux
  • graphics
  • GIM
  • GPU Isolation and Migration
  • SR-IOV
  • Kernel
  • KVM

  Summary of Comments ( 36 )
  https://news.ycombinator.com/item?id=43779953

  Verbose tl;dr

  Hacker News commenters generally expressed enthusiasm for AMD open-sourcing their GPU virtualization driver (GIM), viewing it as a positive step for Linux gaming, cloud gaming, and potentially AI workloads. Some highlighted the potential for improved performance and reduced latency compared to existing solutions like SR-IOV. Others questioned the current feature completeness of GIM and its readiness for production workloads, particularly regarding gaming. A few commenters drew comparisons to AMD's open-source CPU virtualization efforts, hoping for similar success with GIM. Several expressed anticipation for Radeon support, although some remained skeptical given the complexity and resources required for such an undertaking. Finally, some discussion revolved around the licensing (GPL) and its implications for adoption by cloud providers and other companies.

  The Hacker News post "AMD Publishes Open-Source Driver for GPU Virtualization, Radeon 'In the Roadmap'" sparked a discussion with several interesting comments. Many commenters expressed excitement and cautious optimism about AMD's open-sourcing of the GPU virtualization driver, particularly regarding its potential impact on gaming and cloud gaming.

  Several commenters discussed the implications for cloud gaming, noting that this move could be a significant step towards making cloud gaming more accessible and performant. Some speculated about the potential for improved latency and frame rates, while others pondered whether this would lead to more competition and lower prices in the cloud gaming market. There was some discussion about the specific benefits of AMD's approach compared to existing solutions and how it could affect different cloud gaming platforms.

  Some commenters expressed hope that this open-sourcing effort would eventually extend to consumer Radeon cards, which would enable functionality like GPU passthrough for virtual machines, significantly improving performance for gaming and other GPU-intensive tasks within virtualized environments. However, other commenters tempered this enthusiasm, noting that the roadmap mentioned only "data center GPUs" and cautioning against assuming consumer support in the near future. They pointed out that significant driver changes might be necessary to fully support consumer hardware.

  There was also a discussion comparing AMD's approach to NVIDIA's existing virtualization solutions. Some commenters highlighted the potential benefits of an open-source solution over proprietary alternatives, while others questioned whether AMD's performance and feature set would be competitive. This comparison led to some debate about the respective advantages and disadvantages of open-source versus closed-source drivers in the context of GPU virtualization.

  Finally, a few more technically inclined commenters delved into the specifics of the driver architecture and the implications for different operating systems and virtualization platforms. They discussed topics such as SR-IOV support, the use of KVM, and the potential challenges of managing shared GPU resources effectively. Some commenters also expressed interest in contributing to the project and furthering its development.

  Overall, the comments reflect a positive reception to AMD's announcement, with a mixture of excitement for the potential benefits and a healthy dose of pragmatism regarding the challenges and uncertainties that lie ahead. The discussion highlights the significance of this move for the future of GPU virtualization and its potential impact on various applications, particularly in the cloud gaming space.

• TinyKVM: Fast sandbox that runs on top of Varnish

  permalink

  Posted: 2025-03-14 02:12:11

  Verbose tl;dr

  TinyKVM leverages KVM virtualization to create an incredibly fast and lightweight sandbox environment specifically designed for Varnish Cache. It allows developers and operators to safely test Varnish Configuration Language (VCL) changes without impacting production systems. By booting a minimal Linux instance with a dedicated Varnish setup within a virtual machine, TinyKVM isolates experiments and ensures that faulty configurations or malicious code can't disrupt the live caching service. This provides a significantly faster and more efficient alternative to traditional testing methods, allowing for rapid iteration and confident deployments.

  The blog post "TinyKVM: Fast sandbox that runs on top of Varnish" introduces a novel sandboxing mechanism called TinyKVM, designed for exceptional speed and efficiency. It leverages the performance characteristics of Varnish, a widely-used high-performance HTTP accelerator, to create a secure and isolated environment for executing untrusted code, specifically Varnish Modules (VMODs).

  Traditional sandboxing methods often rely on techniques like seccomp-bpf and Linux namespaces, which while effective, introduce performance overhead. TinyKVM takes a different approach, utilizing Kernel-based Virtual Machine (KVM) technology, typically associated with full-blown virtual machines, in a highly optimized and minimal fashion. This allows for a much lighter footprint and reduced performance impact compared to traditional methods.

  The post details the meticulous engineering behind TinyKVM, highlighting several key aspects. First, it explains how TinyKVM boots a specifically crafted, minimal Linux kernel within the KVM environment. This kernel is stripped down to the bare essentials needed for running a VMOD, thereby minimizing resource consumption and boot time.

  Second, it describes the careful management of resources within the TinyKVM instance. Memory is tightly controlled, and the virtual disk is kept incredibly small, further contributing to the overall efficiency. The blog post emphasizes the quick startup time of TinyKVM, often measured in milliseconds, making it suitable for dynamic and on-demand sandboxing scenarios.

  Furthermore, the post touches upon the security benefits provided by TinyKVM. By leveraging hardware virtualization, it isolates the executing VMOD within its own virtual machine, effectively preventing any malicious code from impacting the host system or other VMODs. This strong isolation is critical for maintaining the integrity and stability of the Varnish deployment.

  Finally, the post emphasizes the practical applications of TinyKVM in real-world Varnish deployments. It enables developers to create and deploy powerful VMODs with enhanced security guarantees, without sacrificing the performance advantages offered by Varnish. This opens up possibilities for complex and potentially risky VMOD functionalities, while mitigating the associated security concerns. In essence, TinyKVM bridges the gap between performance and security in the context of Varnish modules, providing a fast and robust sandbox for executing untrusted code.

  • TinyKVM
  • Varnish
  • Sandbox
  • Virtualization
  • KVM
  • Security
  • performance
  • Web Application Firewall (WAF)
  • Caching
  • Edge Computing
  • Containerization

  Summary of Comments ( 40 )
  https://news.ycombinator.com/item?id=43358980

  Verbose tl;dr

  HN commenters discuss TinyKVM's speed and simplicity, praising its clever use of Varnish's infrastructure for sandboxing. Some question its practicality and security compared to existing solutions like Firecracker, expressing concerns about potential vulnerabilities stemming from running untrusted code within the Varnish process. Others are interested in its potential applications, particularly for edge computing and serverless functions. The tight integration with Varnish is seen as both a strength and a limitation, raising questions about its general applicability outside of the Varnish ecosystem. Several commenters request benchmarks comparing TinyKVM's performance to other sandboxing technologies.

  The Hacker News post discussing TinyKVM, a fast sandbox running on top of Varnish, has generated a moderate amount of discussion with several interesting points raised.

  One commenter questions the practicality of using TinyKVM for untrusted code execution, emphasizing that full virtualization, while offering stronger isolation, often comes with performance overhead. They suggest exploring alternative sandboxing techniques like seccomp-bpf and Landlock for better performance, albeit with potentially reduced security. Another commenter echoes this sentiment, highlighting the security concerns with nested virtualization and the potential for vulnerabilities within the hypervisor itself to be exploited.

  The discussion delves into the specific use case of TinyKVM within Varnish, with some commenters expressing confusion about its intended purpose. One user questions the benefit of running untrusted code within a caching layer like Varnish, suggesting it might introduce unnecessary complexity and security risks. Another user speculates about potential applications, such as running plugins or extensions within Varnish, but acknowledges the lack of clarity in the blog post regarding the specific motivations and use cases.

  Several commenters express interest in the performance claims made about TinyKVM, with one highlighting the impressive boot times mentioned in the article. However, they also emphasize the importance of further benchmarking and real-world testing to validate these claims.

  The conversation also touches upon the choice of Firecracker as the underlying virtualization technology, with one commenter mentioning its origins within AWS Lambda and its suitability for lightweight virtualization tasks. Another commenter raises the question of alternative sandbox solutions and wonders if there are any compelling reasons to choose TinyKVM over existing options.

  Finally, there are some comments focused on the technical details of TinyKVM, with one commenter inquiring about the feasibility of running graphical applications within the sandbox and another discussing the implications of running the sandbox within a multi-tenant environment.

• Cloud Virtualization: Red Hat, AWS Firecracker, and Ubicloud internals

  permalink

  Posted: 2025-01-24 15:59:23

  Verbose tl;dr

  The blog post explores different virtualization approaches, contrasting Red Hat's traditional KVM-based virtualization with AWS Firecracker's microVM approach and Ubicloud's NanoVMs. KVM, while robust, is deemed resource-intensive. Firecracker, designed for serverless workloads, offers lightweight and secure isolation but lacks features like live migration and GPU access. Ubicloud positions its NanoVMs as a middle ground, leveraging a custom hypervisor and unikernel technology to provide a balance of performance, security, and features, aiming for faster boot times and lower overhead than KVM while supporting a broader range of workloads than Firecracker. The post highlights the trade-offs inherent in each approach and suggests that the "best" solution depends on the specific use case.

  This Ubicloud blog post delves into the intricacies of cloud virtualization, comparing and contrasting different approaches with a focus on Red Hat's KVM-based solution, AWS's Firecracker microVM, and Ubicloud's own container-based virtualization technology. It begins by establishing the fundamental concept of virtualization as abstracting hardware resources to create isolated environments for running applications. The post then emphasizes the evolving landscape of cloud virtualization, moving from traditional, fully virtualized machines to lighter-weight solutions optimized for specific use cases.

  The discussion around Red Hat's virtualization centers on its utilization of Kernel-based Virtual Machine (KVM), a mature and widely adopted hypervisor within the Linux kernel. KVM leverages hardware virtualization extensions, providing near-native performance for guest operating systems. The blog post highlights the robustness and comprehensive feature set of KVM, making it suitable for a broad range of workloads. However, it also acknowledges the overhead associated with managing full virtual machines, particularly regarding boot times and resource consumption.

  Next, the post explores AWS Firecracker, a specialized microVM designed for serverless computing and containerized workloads. Firecracker’s minimalist approach prioritizes speed and security by implementing a highly optimized and stripped-down virtual machine monitor (VMM). This lean design results in significantly faster startup times and reduced resource usage compared to traditional VMs, making it ideal for rapidly scaling serverless functions. The blog post points out that Firecracker leverages KVM for its underlying virtualization capabilities, building upon its proven foundation. It also notes the specific focus of Firecracker on running single applications, aligning it closely with container-based deployments.

  Finally, the post introduces Ubicloud's container-based virtualization technology. This approach leverages Linux containers, specifically LXD, as the core virtualization mechanism. By utilizing containers, Ubicloud aims to achieve even greater efficiency and density compared to microVMs. The blog post emphasizes the near-instantaneous startup times and minimal resource footprint of containers, allowing for highly dynamic and scalable cloud environments. Furthermore, it highlights the integration of LXD with systemd, providing a robust and familiar management framework. The post contrasts this approach with traditional VMs and microVMs, highlighting the trade-offs between performance, isolation, and compatibility. Specifically, it acknowledges that containers, while offering exceptional performance and density, may not provide the same level of isolation as full VMs or even microVMs, depending on the specific configuration and security requirements.

  In conclusion, the blog post provides a comprehensive overview of different virtualization techniques in the cloud, showcasing the evolution from traditional VMs towards more specialized and efficient solutions like microVMs and container-based virtualization. It underscores the importance of choosing the right virtualization technology based on specific workload requirements, balancing performance, security, and manageability. Ubicloud positions its container-based approach as a compelling option for use cases prioritizing speed, density, and simplified management.

  • Cloud Computing
  • Virtualization
  • Cloud Virtualization
  • Red Hat
  • AWS
  • Firecracker
  • Ubicloud
  • MicroVMs
  • Containerization
  • KVM
  • Linux
  • Open Source
  • Cloud Infrastructure
  • IaaS
  • Serverless
  • Cloud Native
  • Private Cloud

  Summary of Comments ( 6 )
  https://news.ycombinator.com/item?id=42814373

  Verbose tl;dr

  HN commenters discuss Ubicloud's blog post about their virtualization technology, comparing it to Firecracker. Some express skepticism about Ubicloud's performance claims, particularly regarding the overhead of their "shim" layer. Others question the need for yet another virtualization technology given existing solutions, wondering about the specific niche Ubicloud fills. There's also discussion of the trade-offs between security and performance in microVMs, and whether the added complexity of Ubicloud's approach is justified. A few commenters express interest in learning more about Ubicloud's internal workings and the technical details of their implementation. The lack of open-sourcing is noted as a barrier to wider adoption and scrutiny.

  The Hacker News post titled "Cloud Virtualization: Red Hat, AWS Firecracker, and Ubicloud internals" has generated a modest number of comments, primarily focusing on the technical aspects of virtualization and containerization. Several commenters engage with the technical details presented in the Ubicloud blog post.

  One commenter points out the benefits of using KVM for virtualization, highlighting its maturity and wide adoption as key advantages. This commenter also mentions that Firecracker leverages KVM, emphasizing that Firecracker isn't a completely new hypervisor but rather builds upon existing, well-established technology. They also draw a comparison between Firecracker and Kata Containers, another virtualization technology focused on lightweight VMs, suggesting that Kata might be a more suitable alternative in some scenarios.

  Another comment thread delves into the differences between containerization and virtualization, with one user questioning the performance implications of virtualization over containerization when used specifically for microservices. This leads to a discussion about the security benefits of virtualization, arguing that the isolation provided by virtual machines offers a stronger security posture compared to containers, especially in multi-tenant environments. This thread further explores the trade-offs between performance and security, suggesting that the choice between containers and virtualization depends heavily on the specific use case and the prioritization of security vs. performance.

  One commenter mentions gVisor as another isolation technology worth considering, positioning it as a more secure alternative to running containers directly on the host kernel. They also touch upon the concept of Unikernels and their potential for enhanced security and performance in cloud environments.

  Finally, a commenter raises the point about the complexity of container runtimes like containerd and CRI-O, highlighting that these tools are not as straightforward as they might initially seem. This comment underscores the challenges involved in managing containerized environments at scale.

  While the discussion doesn't represent a large volume of comments, it offers valuable insights into various aspects of cloud virtualization and containerization, highlighting the trade-offs between different technologies and approaches, and focusing on the practical considerations for implementing these technologies in real-world scenarios.

• Euro-cloud provider Anexia moves 12,000 VMs off VMware to homebrew KVM platform

  permalink

  Posted: 2025-01-13 12:19:15

  Verbose tl;dr

  Austrian cloud provider Anexia has migrated 12,000 virtual machines from VMware to its own internally developed KVM-based platform, saving millions of euros annually in licensing costs. Driven by the desire for greater control, flexibility, and cost savings, Anexia spent three years developing its own orchestration, storage, and networking solutions to underpin the new platform. While acknowledging the complexity and effort involved, the company claims the migration has resulted in improved performance and stability, along with the substantial financial benefits.

  Austrian cloud provider Anexia, in a significant undertaking spanning two years, has migrated 12,000 virtual machines (VMs) from VMware vSphere, a widely-used commercial virtualization platform, to its own internally developed platform based on Kernel-based Virtual Machine (KVM), an open-source virtualization technology integrated within the Linux kernel. This migration, affecting a substantial portion of Anexia's infrastructure, represents a strategic move away from proprietary software and towards a more open and potentially cost-effective solution.

  The driving forces behind this transition were primarily financial. Anexia's CEO, Alexander Windbichler, cited escalating licensing costs associated with VMware as the primary motivator. Maintaining and upgrading VMware's software suite had become a substantial financial burden, impacting Anexia's operational expenses. By switching to KVM, Anexia anticipates significant savings in licensing fees, offering them more control over their budget and potentially allowing for more competitive pricing for their cloud services.

  The migration process itself was a complex and phased operation. Anexia developed its own custom tooling and automation scripts to facilitate the transfer of the 12,000 VMs, which involved not just the VMs themselves but also the associated data and configurations. This custom approach was necessary due to the lack of existing tools capable of handling such a large-scale migration between these two specific platforms. The entire endeavor was planned meticulously, executed incrementally, and closely monitored to minimize disruption to Anexia's existing clientele.

  While Anexia acknowledges that there were initial challenges in replicating specific features of the VMware ecosystem, they emphasize that their KVM-based platform now offers comparable functionality and performance. Furthermore, they highlight the increased flexibility and control afforded by using open-source technology, enabling them to tailor the platform precisely to their specific requirements and integrate it more seamlessly with their other systems. This increased control also extends to security aspects, as Anexia now has complete visibility and control over the entire virtualization stack. The company considers the successful completion of this migration a significant achievement, demonstrating their technical expertise and commitment to providing a robust and cost-effective cloud infrastructure.

  • Cloud Computing
  • Virtualization
  • KVM
  • VMware
  • Anexia
  • Migration
  • Data Center
  • infrastructure
  • Open Source
  • Proprietary Software
  • Cost Savings
  • Europe
  • Homebrew
  • Custom Platform
  • Server Management
  • Virtual Machines
  • Data Centers
  • Cost Reduction
  • Cloud Infrastructure
  • Private Cloud
  • Hybrid Cloud
  • Server Virtualization
  • Virtual Machines (VMs)

  Summary of Comments ( 21 )
  https://news.ycombinator.com/item?id=42682671

  Verbose tl;dr

  Hacker News commenters generally praised Anexia's move away from VMware, citing cost savings and increased flexibility as primary motivators. Some expressed skepticism about the "homebrew" aspect of the new KVM platform, questioning its long-term maintainability and the potential for unforeseen issues. Others pointed out the complexities and potential downsides of such a large migration, including the risk of downtime and the significant engineering effort required. A few commenters shared their own experiences with similar migrations, offering both warnings and encouragement. The discussion also touched on the broader trend of moving away from proprietary virtualization solutions towards open-source alternatives like KVM. Several users questioned the wisdom of relying on a single vendor for such a critical part of their infrastructure, regardless of whether it's VMware or a custom solution.

  The Hacker News comments section for the article "Euro-cloud provider Anexia moves 12,000 VMs off VMware to homebrew KVM platform" contains a variety of perspectives on the motivations and implications of Anexia's migration.

  Several commenters focus on the cost savings as the primary driver. They point out that VMware's licensing fees can be substantial, and moving to an open-source solution like KVM can significantly reduce these expenses. Some express skepticism about the claimed 70% cost reduction, suggesting that the figure might not account for all associated costs like increased engineering effort. However, others argue that even with these additional costs, the long-term savings are likely substantial.

  Another key discussion revolves around the complexity and risks of such a large-scale migration. Commenters acknowledge the significant technical undertaking involved in moving 12,000 VMs, and some question whether Anexia's "homebrew" approach is wise, suggesting potential issues with maintainability and support compared to using an established KVM distribution. Concerns are raised about the potential for downtime and data loss during the migration process. Conversely, others praise Anexia for their ambition and technical expertise, viewing the move as a bold and innovative decision.

  A few comments highlight the potential benefits beyond cost savings. Some suggest that migrating to KVM gives Anexia more control and flexibility over their infrastructure, allowing them to tailor it to their specific needs and avoid vendor lock-in. This increased control is seen as particularly valuable for a cloud provider.

  The topic of feature parity also emerges. Commenters discuss the potential challenges of replicating all of VMware's features on a KVM platform, especially advanced features used in enterprise environments. However, some argue that KVM has matured significantly and offers comparable functionality for many use cases.

  Finally, some commenters express interest in the technical details of Anexia's migration process, asking about the specific tools and strategies used. They also inquire about the performance and stability of Anexia's KVM platform after the migration. While the original article doesn't provide these specifics, the discussion reflects a desire for more information about the practical aspects of such a complex undertaking. The lack of technical details provided by Anexia is also noted, with some speculation about why they chose not to disclose more.