Proxmox VE Import Wizard: How to import VMs from VMware ESXi


This video will show how to use the Proxmox VE Import Wizard to migrate VMware ESXi VMs to Proxmox Virtual Environment. Version 8.2 provides an integrated VM importer using the storage plugin system for native integration into the API and web-based user interface. You can use this to import a VMware ESXi VM as a whole. The video demonstrates the following steps:

Mounting the host as a new Proxmox storage
Launching the Import Wizard for the Windows 2022 Server
Resulting configuration and import
Import progress
First boot of the imported VM
Enabling VirtIO SCSI boot
Device Manager – final checks
and much more....

Read the step-by-step guide:
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Automatic_Import_of_Full_VM
#vmware #proxmox #migrate #kvm #virtualization


https://t.iss.one/unixmens

The Machine Config Operator (MCO) in Red Hat OpenShift has been able to perform disruptionless updates on select changes since version 4.7. These select changes were hardcoded in the MCO. To make this process more user-friendly and customizable, the MCO team is introducing node disruption policies.This blog post will offer context behind node disruption policies, how MCO uses node disruption policies during a MachineConfig Operator update, and important points to be aware of while using them. Why hand over node disruption control to administrators?Disruptions can be very expensive for customer

via Red Hat Blog https://ift.tt/MPRgjN5

People are asking AI for answers. Is your infrastructure ready to deliver?I recently came across a case study showing that traffic from ChatGPT was converting at over 15%, nearly 10x higher than traditional organic search.That kind of stat is hard to ignore, and it points to a broader shift that’s already underway: people aren’t just Googling anymore. They’re turning to large language models (LLMs) to ask for advice, recommendations and product suggestions in natural language. Because these tools feel so intuitive, users expect them to deliver facts. In reality, some models are trained t

via Red Hat Blog https://ift.tt/lX8oUbV

Red Hat Enterprise Linux (RHEL) remains the trusted backbone of enterprise IT, constantly evolving to meet modern demands. At Red Hat Summit, we unveiled a powerful series of innovations that redefine RHEL's capabilities across the hybrid cloud, security and management. This roundup explores key blog posts published during Summit 2025 and covers everything from deep cloud integrations and cutting-edge security features like post-quantum cryptography, AI-powered assistance and operating system (OS) management with image mode. Explore how RHEL is building a resilient and secure foundation for yo

via Red Hat Blog https://ift.tt/SxJh7HD

KubeVirt is an innovative tool designed to manage the lifecycle and scheduling of Virtual Machines (VMs) within Kubernetes clusters. It aims to bridge the gap between traditional virtualization and modern container orchestration, allowing for a hybrid environment where both VMs and containers can coexist. Here’s a detailed overview of KubeVirt, its comparisons with other projects, and its use cases.
Overview of KubeVirt
KubeVirt extends Kubernetes by enabling it to manage VMs alongside containerized applications. This integration allows organizations to leverage Kubernetes' orchestration capabilities for both types of workloads, providing a unified platform for managing resources in a datacenter or cloud environment.
KubeVirt vs. Other Projects
Kubernetes:
Kubernetes is primarily focused on automating the deployment and management of containerized applications.
KubeVirt acts as an add-on to Kubernetes, enabling it to manage VMs, thus enhancing Kubernetes' capabilities.
OpenStack:
OpenStack is a comprehensive IaaS platform that includes various components for compute, networking, and storage.
KubeVirt is a single component that specializes in VM scheduling and lifecycle management, relying on other systems for networking and storage.
Nova:
Nova is the VM scheduling component of OpenStack, supporting multiple virtualization technologies.
KubeVirt focuses specifically on KVM managed by Libvirt, allowing for a more streamlined and efficient management of VMs.
oVirt:
oVirt is a virtualization management platform that emphasizes high availability and infrastructure-level guarantees.
KubeVirt aims to provide similar consistency guarantees while also offering the scalability needed for cloud environments.
Libvirt:
Libvirt is a toolkit for managing VMs on a local node, providing lifecycle management and network/storage interface management.
KubeVirt utilizes Libvirt for managing KVM VMs, leveraging its existing capabilities rather than reinventing the wheel.
AWS EC2 and Google GCE:
Both EC2 and GCE are proprietary cloud services that lock users into specific pricing models and infrastructures.
KubeVirt is an open-source project that focuses solely on VM scheduling, providing flexibility and independence from specific cloud providers.
Use Cases
KubeVirt is designed to address several key use cases:
Cloud Virtualization:
It provides a feature set for managing VM scale-out, similar to the abstractions offered by cloud IaaS APIs.
Datacenter Virtualization:
KubeVirt aims to deliver strong infrastructure consistency guarantees, making it suitable for managing large numbers of VMs.
Kubernetes Trusted Workloads:
It allows for the execution of virtualized workloads that require the security guarantees provided by a hypervisor.
Combining Container and Virtualized Workloads:
KubeVirt enables the scheduling of both containerized and virtualized workloads on the same Kubernetes cluster, facilitating a more integrated approach to resource management.
Conclusion
KubeVirt is positioned as a powerful tool for organizations looking to manage VMs within a Kubernetes environment. By focusing on KVM and leveraging existing technologies like Libvirt, KubeVirt aims to provide a robust solution for both cloud and datacenter virtualization, while also supporting the coexistence of containerized applications. Its open-source nature and flexibility make it an attractive option for IaaS providers and enterprises alike.


#ovirt #kubevirt #linux #k8s #kubernetes #lcm #virtualization


https://t.iss.one/unixmens

In 2013, Redmonk analyst Steven O’Grady positioned application developers as the new kingmakers. It was a role that enterprise IT had served since the rise of business-driven computing. First, systems administrators held the keys to the kingdom by having the (then) esoteric knowledge of the operating system - but as Linux took hold in the late 90s/early 00s, the applications, not the OS, took center stage. This made developers the unlikely “voice behind the throne” in a CxO monarchy. But we’re looking at another shift in royalty fabrication with the continued velocity of generative AI

via Red Hat Blog https://ift.tt/ZAmW492

KubeVirt is an innovative tool designed to manage the lifecycle and scheduling of Virtual Machines (VMs) within Kubernetes clusters. It aims to bridge the gap between traditional virtualization and modern container orchestration, allowing for a hybrid environment where both VMs and containers can coexist. Here’s a detailed overview of KubeVirt, its comparisons with other projects, and its use cases.
Overview of KubeVirt
KubeVirt extends Kubernetes by enabling it to manage VMs alongside containerized applications. This integration allows organizations to leverage Kubernetes' orchestration capabilities for both types of workloads, providing a unified platform for managing resources in a datacenter or cloud environment.
KubeVirt vs. Other Projects
Kubernetes:
Kubernetes is primarily focused on automating the deployment and management of containerized applications.
KubeVirt acts as an add-on to Kubernetes, enabling it to manage VMs, thus enhancing Kubernetes' capabilities.
OpenStack:
OpenStack is a comprehensive IaaS platform that includes various components for compute, networking, and storage.
KubeVirt is a single component that specializes in VM scheduling and lifecycle management, relying on other systems for networking and storage.
Nova:
Nova is the VM scheduling component of OpenStack, supporting multiple virtualization technologies.
KubeVirt focuses specifically on KVM managed by Libvirt, allowing for a more streamlined and efficient management of VMs.
oVirt:
oVirt is a virtualization management platform that emphasizes high availability and infrastructure-level guarantees.
KubeVirt aims to provide similar consistency guarantees while also offering the scalability needed for cloud environments.
Libvirt:
Libvirt is a toolkit for managing VMs on a local node, providing lifecycle management and network/storage interface management.
KubeVirt utilizes Libvirt for managing KVM VMs, leveraging its existing capabilities rather than reinventing the wheel.
AWS EC2 and Google GCE:
Both EC2 and GCE are proprietary cloud services that lock users into specific pricing models and infrastructures.
KubeVirt is an open-source project that focuses solely on VM scheduling, providing flexibility and independence from specific cloud providers.
Use Cases
KubeVirt is designed to address several key use cases:
Cloud Virtualization:
It provides a feature set for managing VM scale-out, similar to the abstractions offered by cloud IaaS APIs.
Datacenter Virtualization:
KubeVirt aims to deliver strong infrastructure consistency guarantees, making it suitable for managing large numbers of VMs.
Kubernetes Trusted Workloads:
It allows for the execution of virtualized workloads that require the security guarantees provided by a hypervisor.
Combining Container and Virtualized Workloads:
KubeVirt enables the scheduling of both containerized and virtualized workloads on the same Kubernetes cluster, facilitating a more integrated approach to resource management.
Conclusion
KubeVirt is positioned as a powerful tool for organizations looking to manage VMs within a Kubernetes environment. By focusing on KVM and leveraging existing technologies like Libvirt, KubeVirt aims to provide a robust solution for both cloud and datacenter virtualization, while also supporting the coexistence of containerized applications. Its open-source nature and flexibility make it an attractive option for IaaS providers and enterprises alike.


#kubevirt #linux #k8s #kubernetes #vm #virtualization

https://t.iss.one/unixmens

ZFS (Zettabyte File System) offers several RAID-like configurations, including ZRAID and DRAID, which provide different advantages for data storage and redundancy.
ZRAID
ZRAID is a term often used to describe the traditional RAID configurations available in ZFS, such as RAID-Z1, RAID-Z2, and RAID-Z3. These configurations allow for:
Data Redundancy: Protects against data loss due to disk failures. RAID-Z1 can tolerate one disk failure, RAID-Z2 can tolerate two, and RAID-Z3 can tolerate three.
Efficient Storage: Unlike traditional RAID, ZFS uses variable block sizes and can efficiently utilize disk space.
Self-Healing: ZFS checksums all data and can automatically repair corrupted data using redundant copies.
DRAID
DRAID (Distributed RAID) is a newer feature in ZFS that enhances the traditional RAID configurations by distributing parity and data across all disks in a pool. Key benefits include:
Improved Performance: DRAID can offer better performance during rebuilds and normal operations by distributing the workload across all disks.
Scalability: It allows for easier expansion of storage pools by adding new disks without significant performance degradation.
Reduced Rebuild Times: Since data and parity are distributed, the time taken to rebuild a failed disk is generally shorter compared to traditional RAID configurations.

ZRAID (RAID-Z)

ZRAID encompasses the various RAID-Z configurations in ZFS, which include:

RAID-Z1:
Configuration: Similar to RAID 5, it uses one parity block.
Fault Tolerance: Can withstand one disk failure.
Use Case: Suitable for environments where data redundancy is important but cost needs to be managed.

RAID-Z2:
Configuration: Similar to RAID 6, it uses two parity blocks.
Fault Tolerance: Can withstand two disk failures.
Use Case: Ideal for critical data storage where higher redundancy is required.

RAID-Z3:
Configuration: Uses three parity blocks.
Fault Tolerance: Can withstand three disk failures.
Use Case: Best for environments with very high data availability requirements.

Advantages of ZRAID:

Data Integrity: ZFS checksums all data, ensuring that any corruption can be detected and repaired.
Snapshots and Clones: ZFS allows for efficient snapshots and clones, which can be useful for backups and testing.
Compression: ZFS supports data compression, which can save space and improve performance.

Considerations for ZRAID:

Rebuild Times: In traditional RAID configurations, rebuilding a failed disk can take a significant amount of time, during which the system may be vulnerable to additional failures.
Performance: Write performance can be impacted due to the overhead of calculating parity.

DRAID (Distributed RAID)

DRAID is a more recent addition to ZFS, designed to address some of the limitations of traditional RAID configurations.
Key Features of DRAID:

Distributed Parity: Unlike ZRAID, where parity is concentrated, DRAID distributes parity across all disks, which can lead to improved performance.
Dynamic Resiliency: DRAID can adapt to changes in the storage pool, such as adding or removing disks, without significant performance penalties.
Faster Rebuilds: The distributed nature of DRAID allows for faster rebuild times since the workload is shared across multiple disks.

Advantages of DRAID:

Performance: DRAID can provide better read and write performance, especially in environments with high I/O demands.
Scalability: It is easier to scale storage by adding disks, as the system can dynamically adjust to the new configuration.



Conclusion


Both ZRAID and DRAID provide robust solutions for data storage, with ZRAID being more traditional and widely used, while DRAID offers modern enhancements for performance and scalability. The choice between them depends on specific use cases, performance requirements, and the desired level of redundancy.



#zfs #raid #linux #storage #kernel #data

https://t.iss.one/unixmens

IntroductionRed Hat understands that customer feedback plays a crucial role in guiding technology purchasing decisions. Consequently, peer review vendors such as TrustRadius and G2 have become essential tools for businesses and buyers alike. Buyers benefit from reading authentic customer experiences, ratings and accolades on these trusted peer review sites in order to make the best buying decision for their business. At the same time, the feedback collected from our customers through peer review sites, alongside other channels, contributes significantly to Red Hat’s ongoing effort to enhance

via Red Hat Blog https://ift.tt/vhELCqN

Why agents are the new kingmakersFor more than a decade, developers have been looked as the kingmakers when it comes to enterprise IT and innovation...but are AI agents supplanting them? Learn more SiliconANGLE - Red Hat offers free and simple self-serve access to RHEL for application developersRed Hat is cutting through some of the complexity of today’s intricate hybrid cloud and on-premises computing environments with a new version of its flagship operating system that’s more accessible for developer teams who design and test new applications. Learn more TheCUBE - Matt Hicks, Red Hat Pre

via Red Hat Blog https://ift.tt/tHxnJhy

ماژول stream در Nginx یکی از ماژول‌های قدرتمند و در عین حال کمتر شناخته‌شده است که برای پراکسی کردن (proxying) ترافیک لایه‌ی چهارم (TCP/UDP) به کار می‌رود. برخلاف ماژول http که برای سرویس‌های لایه‌ی هفتم طراحی شده، ماژول stream مخصوص لایه‌ی انتقال است (لایه چهارم در مدل OSI).
🎯 کاربرد اصلی Stream Module

ا Load Balancing برای دیتابیس‌ها (مثل MySQL, PostgreSQL)

ا TCP-level reverse proxy (مثلاً برای SSH، Redis، MQTT)

پراکسی کردن ترافیک UDP (مثل DNS، VoIP)

ساخت TLS passthrough proxy (برخلاف termination در http)

استفاده به عنوان ورودی برای SSL offloading

🧩 فعال‌سازی ماژول Stream

ماژول stream به‌طور پیش‌فرض در نسخه‌های pre-built رسمی Nginx فعال نیست. برای استفاده از آن باید:

از نسخه‌ی Nginx Plus استفاده کنید
یا

از سورس با --with-stream کامپایل کنید

بررسی فعال بودن:

nginx -V 2>&1 | grep -- --with-stream

📜 نمونه پیکربندی
✅ پراکسی TCP ساده

stream {
    upstream backend {
        server 192.168.1.10:3306;
        server 192.168.1.11:3306;
    }

    server {
        listen 3306;
        proxy_pass backend;
    }
}

✅ پراکسی UDP

stream {
    server {
        listen 53 udp;
        proxy_pass 8.8.8.8:53;
    }
}

ا ✅ SSL passthrough برای mail server

stream {
    map $ssl_preread_server_name $backend {
        mail.example.com   mail_backend:993;
        default            default_backend:993;
    }

    server {
        listen 993;
        proxy_pass $backend;
        ssl_preread on;
    }
}

نکته: قابلیت ssl_preread در stream شبیه SNI sniffing در TLS است.

⚙️ دستورات مهم Stream Module

proxy_pass  تعریف مقصد
upstream  تعریف سرورهای backend
listen  تعریف پورت/پروتکل ورودی
ssl_preread  فعال‌سازی خواندن SNI بدون decryption
proxy_timeout  تایم‌اوت بین Nginx و سرور مقصد
proxy_connect_timeout  تایم‌اوت برای اتصال اولیه
proxy_protocol  فعال‌سازی PROXY protocol (برای انتقال IP کلاینت)

📌 محدودیت‌ها


امکان دستکاری محتوا وجود ندارد (چون لایه ۴ است)

نمی‌توان از rewrite, headers, gzip, cache استفاده کرد

لاگ‌گیری محدود به connection-level است، نه request-level

🧠 جمع‌بندی

ماژول stream در Nginx به شما اجازه می‌دهد به‌جای لایه‌ی اپلیکیشن (HTTP)، روی لایه‌ی انتقال (TCP/UDP) تمرکز کنید و خدماتی مانند load balancing، SSL passthrough، reverse proxy برای سرویس‌های غیروبی ارائه دهید. این قابلیت برای طراحی زیرساخت‌های حرفه‌ای بسیار حیاتی است، به‌خصوص در محیط‌هایی مثل:

ا Kubernetes ingress برای TCP/UDP

انتقال ترافیک دیتابیس‌ها

پیاده‌سازی reverse proxy با امنیت بالا

🎯 امکانات ماژول stream در NGINX

پشتیبانی از TCP و UDP Reverse Proxy

ا Load Balancing برای TCP/UDP با الگوریتم‌های:

ا round-robin (پیش‌فرض)

ا least_conn (در نسخه Plus)

ا hash-based routing

پشتیبانی از Health Checks (در نسخه NGINX Plus)

ا SSL Passthrough با قابلیت ssl_preread

ا SNI-based Routing بدون decrypt کردن TLS

پشتیبانی از PROXY Protocol (برای انتقال IP کلاینت)

کنترل دسترسی با allow / deny

لاگ‌گیری سفارشی برای TCP/UDP connections

تنظیم Timeoutهای مختلف:

proxy_timeout

proxy_connect_timeout

پشتیبانی از متریک‌های ساده‌ی اتصال

تعریف upstream blocks برای backend سرورها

🧠 کاربردهای ماژول stream

پراکسی و Load Balancing برای دیتابیس‌ها (PostgreSQL, MySQL, Redis)

ا SSL passthrough برای HTTPS با SNI routing

پراکسی سرویس‌های VoIP و UDP-based (مانند RTP، SIP)

ا Reverse Proxy برای DNS (TCP و UDP)

پراکسی و مسیردهی ترافیک mail servers (IMAP, POP3, SMTP)

ا Bastion SSH Host برای هدایت کاربران SSH به سرورهای مختلف

پراکسی برای پروتکل‌های خاص TCP مانند MQTT، FIX، یا custom protocols

استفاده در Kubernetes Ingress Controller برای TCP/UDP Services




#nginx #stream #linux #network

https://t.iss.one/unixmens

Technology innovation can seem overwhelming. We're constantly chasing the latest breakthrough and sprinting to apply the hype de jour. But, there's a less glamorous, invisible component of our work that underpins it all: platform upgrades and migrations.Over the years, I've learned a hard truth: failing to adequately plan for platform maintenance and renewal inevitably results in technical stagnation and decay, increasing the risk of sudden, critical failures. The challenge we face is that upgrades and migrations are essential, complex multidisciplinary efforts. They can have a big impact on o

via Red Hat Blog https://ift.tt/DlNiSyV

Although it's been around for decades, the world of virtualization continues to change, with organizations facing new challenges around cost, licensing and modern infrastructure. Red Hat Summit recently showcased how Red Hat OpenShift Virtualization is leading this transformation, providing a clear path to bridge traditional virtual machines (VMs) and cloud-native applications. This roundup discusses the articles published during Summit, exploring how OpenShift Virtualization enables smooth migration, unified management, enhanced security and strong integrations, empowering businesses to moder

via Red Hat Blog https://ift.tt/OaFx8Jz

مقاله‌ در مورد ، گزارشی محرمانه (رسته‌ٔ «S‌») از پروژه Grill Flame، بخشی از تلاش‌های آمریکا در دوران جنگ سرد برای بررسی کاربردهای «بینایی از راه دور» (Remote Viewing) در امور اطلاعاتی و دفاعی است . در ادامه خلاصه‌ای از مهم‌ترین نکاتش را می‌خوانید:


---

🔍 تاریخچه و هدف

شروع: برنامه از اوایل دهۀ ۷۰ میلادی با همکاری SRI International و تحت نظر نهادهایی مثل CIA، DIA، NSA، INSCOM و دیگران آغاز شد.

کدگذاری: در ۱۹۷۸، پروژه به‌صورت رسمی با نام «Grill Flame» سازمان‌دهی شد و از ۱۹۷۹ مدیریت مستقیم INSCOM را گرفت. از ۱۹۸۰، DIA مدیریت بودجه و فعالیت را بر عهده داشت .

هدف: بررسی قابلیت‌های روانی – معنوی مانند ESP یا همان ذهن‌خوانی (Psi)، برای استفاده در جمع‌آوری اطلاعات، همچنین تقویت و درک تهدیدات احتمالی مشابه از سوی شوروی و بلوک شرق .



---

💰 بودجه و پشتیبانی مالی

منابع متعددی شامل CIA، نیروی دریایی، Wright-Patterson AFB، DIA، INSCOM و غیره تأمین‌کننده مالی کارهای SRI بین ۱۹۷۱ تا ۱۹۸۳ بودند. مجموع بودجه‌ها چند صد هزار دلار در سال بوده .



---

بینایی از راه دور (Remote Viewing)

تعریف پروژه: بینایی از راه دور فرایندی است که به افراد آموخته می‌شود تا از طریق ذهن، مکان‌ها یا اشیائی را ببینند که در فاصله بسیار دور یا در پنهانی از دید مستقیم‌اند، مثل اشیاء در کانتینرهای بسته یا تأسیسات نظامی در اتحاد جماهیر .

کاربرد اطلاعاتی: بینایی‌کننده‌ها (viewers) نشانه‌های بصری یا احساسی را ثبت و گزارش می‌کردند — و تحلیلگران اطلاعات CIA یا DIA آنها را با داده‌های واقعی تطبیق و ارزیابی می‌کردند. گزارش می‌گوید نتایج در مواردی "فراتر از تصادف" بوده و منبع قابل‌تکی برای اطلاعات تکمیلی است، نه تنها منبع نگاه .



---

🏭 نمونه عملی: تأسیسات شوروی – PNUTS

نمونه‌ای در سند ارائه شده از هدف‌گیری یک تأسیسات تحقیق و توسعه شوروی در سمپیالاتینسک (Semipalatinsk)، همچنین شناخته‌شده به ‌نام PNUTS. ویژگی‌های زیر «بینایی از راه دور» شده‌اند:

یک جرثقیل ریلی بزرگ (چندین طبقه ارتفاع).

اجزای فلزی که برای تشکیل کره زیر زمین مونتاژ می‌شدند.


تصویری که بینایی‌کننده رسم کرد، با واقعیات تأسیساتی ارتش شوروی مطابقت داشت؛ و جزییات (شکل اجزا، چینش‌ها و زمان تقریبی) در طرح‌ قابل اعتماد بودند .



---

جمع‌بندی

1. این سند بخشی از پروژه وسیع‌تر Stargate بود که تلاش داشت واقعیت‌های ذهنی را در قالب ابزاری اطلاعاتی کاربردی تبدیل کند.


2. این گزارش بر اساس بررسی داده‌ها، نشان می‌دهد تکنیک RV گاهی نتایج قابل‌استفاده‌ای داشته. اما تأکید شده که اطلاعات باید همراه با منابع دیگر تحلیل شوند.


3. ارائه نمونه‌ای در مورد شوروی (PNUTS) نشان‌دهنده نوع کاربرد واقعی این روش در فعالیت‌های اطلاعاتی آن زمان است.

در ادامه، بررسی جامع و مدون پروژه Grill Flame، با تأکید بر اسناد رسمی CIA و تحلیل جزئیات کلیدی را مشاهده می‌کنید:


---

📘 تاریخچه و ساختار پروژه

آغاز و کدگذاری: از اوایل دهه ۷۰، SRI International تحت حمایت CIA، DIA و ارتش، آزمایش‌‌هایی در زمینه RV (بینایی از راه دور) انجام می‌داد. در سال ۱۹۷۸ پروژه به‌صورت رسمی تحت کد «Grill Flame» تعریف و مدیریت آن به INSCOM سپرده شد. از سال ۱۹۸۰، DIA بر آن نظارت مالی داشت .

بودجه: منابع بین سال‌های ۱۹۷۱ تا ۱۹۸۳ از CIA، نیروی دریایی، FTD، Wright-Patterson AFB، DIA، INSCOM و غیره تأمین می‌شدند، با میزان بالغ بر صدها هزار دلار در سال .



---

🎯 اهداف اصلی

بررسی کاربرد RV و سایر پدیده‌های روانی (مثل روان‌کینزی – PK) برای استفاده در عملیات اطلاعاتی

ارزیابی تهدیدات بالقوه از برنامه‌های مشابه شوروی/بلوک شرق



---

🧪 روش‌شناسی عملیاتی

ساختار جلسه RV

استفاده از پروتکل دقیق: انتخاب تصادفی هدف (مختصات یا شخص به‌عنوان Beacon)، ۱۵ تا ۶۰ دقیقه جلسه RV با ضبط صوتی و نگارش/طراحی ذهنی، و تحلیل پس از بازگشت هدف

نقش‌ها مشخص تعریف شده: viewer، interviewer، beacon، project officer و …


نمونه PNUTS

در یک مأموریت نمونه به تأسیسات تحقیقاتی شوروی در Semipalatinsk (PNUTS)، بینایی‌کننده‌ها توانستند:

وجود جرثقیل ریلی چندطبقه

اجزای فلزی برای ساخت کره را به‌درستی تشخیص دهند
و طراحی ارائه‌شده با واقعیت مطابقت داشت



---

📝 نتایج و جمع‌بندی

گزارش نهایی پروژه (۱۹ اکتبر ۱۹۸۳) بیان می‌کند:

RV “یک پدیده واقعی است و تحت تأثیر فاصله یا موانع قرار نمی‌گیرد”

قابلیت آموزش و بهبود دارد

محتوای توصیفی (طراحی‌ها، شکل‌ها) در مقایسه با تحلیل‌های فنی قابل‌اعتمادتر است

وجود تهدید بالقوه از پژوهش‌های خارجی به‌ویژه شوروی


توصیه‌ها:

ادامه مطالعات پایه و کاربردی RV و روان‌کینزی

ارزیابی و پیگیری پژوهش‌های خارجی

استفاده از منابع DIA در مدیریت پروژه




---

🧩 وضعیت و پس از آن

پروژه از سال ۱۹۸۳ خاتمه یافت، اما بعدها DIA با بودجه مجدد ($200K–$335K) تلاش برای ادامه و انتقال واحد از INSCOM به DIA را آغاز کرد

پروژه Stargate تا ۱۹۹۵ ادامه یافت، اما نهایتاً بر اساس گزارش مستقل AIR، قابلیت عملی قابل اعتماد نداشت



---

✅ جمع‌بندی

Grill Flame، با پروتکل‌ها و ساختار کاملاً مدون، جلوه‌ای جدی در تحقیق نظامی روان‌پراتی داشت

برخی نتایج به‌ویژه نمونه PNUTS در سطح توصیفی معتبر هستند، اما گزارش رسمی استفاده‌ی عملی گسترده را رد می‌کند

پروژه باعث افزایش ادراک نسبت به تهدیدات خارجی و ایجاد ساختاری برای بررسی‌های روانی شد، اما در نهایت، کاربرد اطلاعاتی قابل اتکا ارائه نداد

در ادامه، بررسی عمیق‌تر و دقیق‌تری از پروژه Grill Flame با تمرکز روی ساختار، نمونه‌ مأموریت‌ها، پروتکل استاندارد و ارزیابی‌های مهم ارائه می‌دهم:


---

1. ساختار و بودجه پروژه

از سال ۱۹۷۲، SRI International با حمایت CIA، ارتش (INSCOM)، DIA، نیروی دریایی و سایر نهادها، تحقیقات در موضوع روان‌انرژی و RV را آغاز کرد. این اولین آزمایش‌های مخفی بینایی از راه دور بود .

در سال ۱۹۷۸، این تلاش رسمی تحت کد Grill Flame سازمان‌دهی شد؛ از ۱۹۷۹ مدیریت عملیاتی به INSCOM سپرده شد و از ۱۹۸۰ DIA مدیریت مالی آن را بر عهده گرفت .

بودجه سالانه این پروژه نمونه‌ای از ترکیب منابع بود: مثلاً برای سال‌های ۱۹۷۱–۱۹۸۳، بودجه‌ای بین ۷۵ تا ۳۴۰ هزار دلار از منابع مختلف تأمین شد .



---

2. پروتکل استاندارد جلسه بینایی از راه دور

بر اساس سند پروتکل رسمی SRI و INSCOM، فرایند RV شامل مراحل زیر بود:

1. انتخاب تصادفی هدف (مختصات یا شخص به‌عنوان Beacon)


2. جلسه مقدماتی: آماده‌سازی بینایی‌کننده، مصاحبه‌کننده و تعیین اهداف دقیق


3. جلسه بینایی: مدت ۱۵–۶۰ دقیقه با تشویق بیان «درک خام» و ثبت هرگونه برداشت تصویری یا کلامی


4. تحلیل پس از جلسه: بازخورد به بینایی‌کننده و ارزیابی محتوا .



برای اهداف شخصی، روش مشابه بود اما مشخصات بیومتریک یا تعامل کوتاه با «Beacon» هم به پروتکل اضافه می‌شد .



---

3. نمونه‌های عملی قابل توجه

🛩️ مورد اول: هواپیمای گمشده نیروی دریایی

در سپتامبر ۱۹۷۹، Grill Flame اولین عملیات رسمی خود با هدف locating یک هواپیمای گمشده نیروی دریایی انجام داد.

نتیجه: بینایی‌کننده هواپیما را در فاصله ۱۵ مایلی از محل واقعی آن قرار داد .


🏭 مورد دوم: تأسیسات PNUTS

یکی از مأموریت‌های دیگر بررسی تأسیسات نظامی شوروی در Semipalatinsk (شناخته‌شده به PNUTS) بود.

بینایی‌کنندگان اجزایی چون جرثقیل ریلی و استراکچرهای فلزی را شناسایی کردند که با طراحی واقعی محل همخوانی داشت .



---

4. یافته‌ها و ارزیابی نهایی

از منابع رسمی DIA/INSCOM، مهم‌ترین نتایج به‌صورت زیر گزارش شده‌اند:

یافته توضیح

RV واقعی است و تحت تأثیر فاصله یا موانع فیزیکی قرار نمی‌گیرد
قابلیت آموزش دارد بینایی‌کننده‌ها توانایی خود را با تمرین افزایش دادند
محتواهای توصیفی مانند نقشه یا تصاویر بهتر از تجزیه و تحلیل فنی قابل‌اعتماد بودند
تهدید خارجی شواهد وجود برنامه‌های مشابه و هدفمند در شوروی گزارش شد


توصیه‌ها:

ادامه تحقیقات بنیادی و کاربردی در حوزه RV و PK

به‌کارگیری RV برای نیازهای اطلاعاتی

بررسی مطالعات خارجی و نظارت بهتر بر پروتکل‌ها



---

5. آینده لاینحل و انتقال نیروها

پروژه رسمی Grill Flame در سال ۱۹۸۳ پایان یافت، اما در همان زمان، DIA با بودجه‌ای حدود ۲۰۰–۳۳۵ هزار دلار در سال ۱۹۸۴–۱۹۸۵، فعالیت‌های مشابه را آغاز کرد و کنترل پروژه را از INSCOM به DIA منتقل کرد .

پروژه کلی Stargate تحت این مجموعه ادامه یافت تا با گزارش مؤسسه AIR در ۱۹۹۵، متوقف شد.



---

🎯 جمع‌بندی تخصصی

Grill Flame مجموعه‌ای سازمان‌یافته با پروتکل دقیق بود که هدفش به‌کارگیری علمی پدیده RV بود.

نمونه‌های عملی مانند هواپیما و PNUTS گرچه قابل‌توجه بودند، اما محتوا توصیفی و نه استنتاج فنی بود.

پروتکل ساختاریافته اما به‌دلیل امکان نشت داده و نرخ دقت محدود، این موضوع از دید نهایی برای کاربرد گسترده در اطلاعات قابل‌اعتماد شناخته نشد.

توصیه شد تحقیقات ادامه یابد اما با کنترل بیشتر و نگاه انتقادی دقیق‌تر.

Remote viewing - Wikipedia
https://en.m.wikipedia.org/wiki/Remote_viewing?utm_source=chatgpt.com

PROJECT GRILL FLAME OPERATIONAL TASKS - CIA-RDP96-00788R001100340001-3.pdf
https://www.cia.gov/readingroom/docs/CIA-RDP96-00788R001100340001-3.pdf

PROJECT GRILL FLAME OPERATIONAL TASKS | CIA FOIA (foia.cia.gov)
https://www.cia.gov/readingroom/document/cia-rdp96-00788r001100340001-3