مجازی سازی در دبیان با virsh&QEMU&KVM — نصب ابزارهای مجازی سازی و اولین ایجاد VM

ek3nk4r 2025-01-12

0 12 خواندن این مطلب 16 دقیقه زمان میبرد

مجازی سازی در دبیان با virsh&QEMU&KVM — نصب ابزارهای مجازی سازی و اولین ایجاد VM

پیشنهاد ویژه

خرید فالوور واقعی خرید لایک اینستاگرام خرید ویو اینستاگرام خرید فالوور اینستاگرام

توضیحات تصویر

در این مقاله به اصول اولیه آن نمی پردازم مجازی سازی– چیست و چه زمانی ممکن است به آن نیاز داشته باشید. این مقاله برای کسانی است که کم و بیش با این مفهوم آشنا هستند، اما نمی دانند چگونه با آن در دبیان شروع کنند.

در اینجا نقشه راه این مقاله آمده است:

➀ مجازی سازی و خود میزبانی
➁ مجازی سازی به عنوان ابزاری برای توسعه برنامه های کاربردی با محدودیت منابع
➂ مجازی سازی در دبیان: چگونه کار می کند

➂.➀ پشتیبانی از مجازی سازی CPU
➂.➁ هایپروایزر

➃ KVM و QEMU
➄ Libvirt
➅ اعتبار سنجی نصب ابزار مجازی سازی

➅.➀ مهم! qemu:///system در مقابل qemu:///session

➆ ایجاد اولین VM:

➆.➀ فایل تصویری سیستم عامل
➆.➁ آماده سازی ذخیره سازی
➆.➂ ایجاد VM با virt-install

➇ اجازه دهید شبکه آغاز شود!

➇.➀ اتصال فضای کاربری (SLIRP یا گذشته).
➇.➁ ارسال NAT (با نام مستعار “شبکه های مجازی”)

ابتدا، مورد استفاده خود را معرفی می کنم – چرا به ماشین های مجازی در رایانه شخصی خود نیاز دارم.

به طور خلاصه، من یک دختر “در محل” هستم (بخوانید “نه خیلی حرفه ای با زیرساخت های ابری”). من تجربه ای در برخورد با زیرساخت های اولیه دارم و اکنون با نیاز به استقرار پروژه شخصی خود در جایی – یک برنامه وب – روبرو هستم تا دنیای واقعی را ببیند و دنیای واقعی آن را ببیند. و نه، این یک وب سایت ثابت نیست. دارای یک باطن و یک پایگاه داده است. و به طور فرضی، برخی از اجزاء در آینده به مقیاس افقی نیاز خواهند داشت.

فهرست مطالب

➀ مجازی سازی و خود میزبانی

رایانه شخصی من از نظر مشخصات اصلاً بد نیست – کاملاً برای اهداف توسعه و حتی به صورت تئوری، برای خدمت به تمام نیازهای برنامه کوچک من در تولید. با این حال، میزبانی هر چیزی که در معرض وب در رایانه شخصی قرار می گیرد، مورد بحث نیست. اگر اولین فکر شما این است که تنها مانع این است که کامپیوتر من باید 24/7 کار کند، در مورد آن نیست. استفاده از ماشینی که دارای برخی اطلاعات شخصی برای میزبانی چیزی است که در معرض وب قرار دارد، ایده بسیار بدی است. اگر دلیل آن را متوجه نشدید، می توانید این مقاله را بررسی کنید.

اگر من ماشین(های) مجازی را در ماشین شخصی خود ایجاد کنم و شبکه ها را به خوبی پیکربندی کنم، آیا این مشکل حل می شود؟ نه! و در اینجا دلیل آن است. مانع اصلی میزبانی هر چیزی از “خانه”– حتی اگر یک سرور مناسب برای آن خریده باشید –ارائه دهنده روتر و اینترنت شما است. آیا این در مورد سرعت اینترنت است؟ نه این در مورد … آدرس IP عمومی شما است.

فرض کنید به خانه جدیدی نقل مکان کرده اید، و این خانه WiFi ندارد. بنابراین شما با ارائه دهندگان اینترنت در شهر خود تماس بگیرید، قیمت ها را بررسی کنید، سودمندترین پیشنهاد را انتخاب کنید و … قرارداد را امضا کنید. اگر شما فقط یک کاربر معمولی هستید و چیز دیگری مشخص نکرده اید، قرارداد “اینترنت برای خانه شما” را از ارائه دهنده انتخاب شده در اختیار شما قرار می دهد.

یک تکنسین در قرار ملاقات برنامه ریزی شده می آید، چند کابل و یک جعبه پلاستیکی – که روتر است – می آورد. آنها با کابل ها سروکار دارند، آنها را به روتر وصل می کنند، یک دفترچه راهنما همراه با نام و رمز شبکه WiFi و voilà به شما تحویل می دهند! می‌توانید همه دستگاه‌های خانگی خود را متصل کنید و از مرور وب لذت ببرید.

هنگامی که فقط از اینترنت استفاده می کنید، به احتمال زیاد هرگز حتی از آدرس IP عمومی خود آگاه نیستید. اما به احتمال زیاد، اصلاً ثابت نیست. به‌طور دوره‌ای تغییر می‌کند، و این کار توسط ارائه‌دهنده اینترنت شما انجام می‌شود – نه به این دلیل که آنها بد هستند، بلکه صرفاً به این دلیل است که آنها همه مشتریان خود را با استفاده از “خانه” مدیریت می‌کنند.

وقتی نوبت به میزبانی چیزی می رسد، مانند یک وب سایت، حتی اگر نام دامنه ای مانند آن را خریداری کنید my-cool-site.it، مردم چگونه آن را پیدا خواهند کرد؟ چه کسی کامپیوتر شما را با کد این سایت (جایی که تمام نیازها و وابستگی های سایت در آن قرار دارد) به آن دامنه متصل می کند؟ نام دامنه برنامه وب شما باید به گونه ای حل شود که آدرس IP صحیح پشت آن آشکار شود.

از نظر تئوری، شما حتی نیازی به خرید نام دامنه ندارید. سایت شما فقط با یک آدرس IP مانند می تواند کاملاً خوب کار کند https://12.34.56.78/home. اما اگر می‌خواهید سایت شما در گوگل قابل جستجو باشد و فقط برای افرادی که قبلاً پیوند را دارند قابل دسترسی نباشد، اصلاً عالی نیست.

اگر ارائه دهنده اینترنت شما آدرس IP عمومی شما را به صورت دوره ای تغییر می دهد، مانند خانه هایی است که اغلب در حال جابجایی هستند. افرادی که سعی می کنند برای شما نامه بفرستند، همچنان آنها را به آدرس قدیمی شما می فرستند، مگر اینکه آنها را به روز کنید، و نامه ها هرگز به دست شما نخواهند رسید. همین منطق در مورد هاست دارای IP پویا نیز صدق می کند. مطمئناً می‌توانید همه چیز را به‌صورت دستی به‌روزرسانی کنید و دامنه را به آدرس IP عمومی جدید خود پیوند دهید، اما این کار چندان راحت نیست.

به علاوه، محدودیت دیگر، روتر است که توسط ارائه دهنده اینترنت شما ارائه شده است. آنها اغلب اقدامات بسیار محدود کننده ای از نظر ترافیک https/s دریافتی دارند (مسدود می شود) و این محدودیت ها (خوشبختانه) مانع از هرگونه تلاش برای میزبانی می شود. متشکرم می گویم، زیرا اگر واقعاً درک نمی کنید که چگونه کار می کند، بهتر است که این محدودیت ها، قوانین فایروال، بالا باشند و از شما محافظت کنند.

نکته دیگری که باید در نظر بگیرید، این است که قرارداد شبکه خانگی شما ممکن است به شما اجازه میزبانی چیزی را ندهد زیرا به نوعی یک هدف “تجاری” است. و اهداف “تجاری” برای ارائه دهندگان اینترنت به این معنی است که آنها می توانند هزینه بیشتری از شما دریافت کنند. در واقع، اگر می خواهید یک آدرس IP عمومی ثابت داشته باشید، باید با ارائه دهنده اینترنت خود تماس بگیرید و دریابید که در چه شرایطی می توانید آن را دریافت کنید.

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

به طور خلاصه، در حال حاضر، این گزینه برای من نیست که “خود میزبان” باشم.

➁ مجازی سازی به عنوان ابزاری برای توسعه برنامه های کاربردی با محدودیت منابع

بنابراین، مجازی سازی راه حلی برای مشکل من با استقرار برنامه وب نیست. سپس کجا می توان آن را مستقر کرد؟ ابر من می‌توانم یک ارائه‌دهنده ابری انتخاب کنم، نمونه‌هایی را که با نیازهای برنامه من مطابقت دارند اجاره کنم، آنها را پیکربندی کنم و برنامه‌ام را اجرا کنم. ساده است، درست است؟ خوب، نه به این سرعت – زیرا هر نمونه، هر سرویس، قیمتی دارد. و این قیمت‌ها… برای کسی مثل من، که یک رایانه شخصی بسیار قدرتمند با قیمت حدود 1000 دلار ساخته است، دیدن قیمت‌گذاری ابری برای نمونه‌های «سرور کوچک» می‌تواند کمی گیج‌کننده باشد. برای ارائه ایده، می‌توانید قیمت AWS را با استفاده از ماشین‌حساب آن‌ها بررسی کنید. من اسکرین شات هایی از قیمت نمونه EC2 به اشتراک می گذارم:

توضیحات تصویر

2 vCPU، 4 گیگابایت رم و فضای ذخیره سازی با هزینه اضافی. اگر می‌خواهید چیزی را میزبانی کنید که عملیات سمت سرور دارد، همه با حدود 30 دلار در ماه مال شماست.

توضیحات تصویر

در واقع، 2 vCPU ها نه CPU ها. vCPU مخفف CPU مجازی است زیرا آنها CPUهای فیزیکی واقعی نیستند، بلکه مجازی شده اند. و نمونه های EC2 اساساً فقط ماشین های مجازی هستند.

اکنون که به کلمه مجازی سازی بازگشته ایم، بیایید در مورد مورد استفاده من – نیازهای من صحبت کنیم. وقتی نوبت به توسعه برنامه من روی رایانه شخصی من می رسد، حتی با وجود اینکه می توانستم همه چیز مورد نیاز را مستقیماً نصب کنم (از آنجایی که من همیشه از همان پشته به عنوان یک توسعه دهنده استفاده می کنم)، این بهینه نیست. چرا رایانه‌ام را با نصب‌هایی مانند Nginx و MongoDB شلوغ می‌کنم و وقتی پروژه به پایان می‌رسد، آنها را بی‌رویه به حال خود رها می‌کند؟

برای مرتب نگه داشتن همه چیز برای اهداف توسعه، ماشین های مجازی میزبانی شده روی رایانه شخصی من راه حل عالی است. با این حال، مشکل اصلی توسعه مستقیماً روی رایانه شخصی من این است: وقتی من روی دستگاهی با 20 هسته CPU از آخرین نسل، 64 گیگابایت رم و 12 گیگابایت حافظه GPU توسعه می‌دهم، چگونه می‌توانم مطمئن شوم که چه چیزی را دارم. آیا توسعه یافته در واقع بر روی نمونه های کوچک EC2 اجرا می شود؟ یا مهمتر از آن، چگونه می توانم منابع مورد نیاز برنامه خود را به طور کلی ارزیابی کنم؟ (حالا ارزیابی مبتنی بر کد را کنار بگذاریم)

اینجاست که مجازی سازی واقعاً به من کمک خواهد کرد. من می توانم عملکرد کد خود را از همان ابتدا با ایجاد VM با منابع کوچک متصل و قرار دادن اجزای برنامه خود در آنجا ارزیابی کنم!

یادداشت برای Dockerists/Dockerphiles/Containerphiles

من از قبل می توانم “خدایا، فقط داکر را یاد بگیر” را پیش بینی کنم.آسان است! توسعه بر روی فلز لخت دایناسوریک است. Containerization، کلید است!» من شک ندارم که Docker می تواند همه چیز را اداره کند. در واقع، من شخصاً از Docker Swarm تا حدودی لذت می برم (هرچند نمی توانم این را برای Kubernetes بگویم).

با این حال، فراموش نکنیم که داکر دارای فناوری مجازی سازی است. و همانطور که قبلا ذکر کردم، نمونه های EC2 چیزی بیش از ماشین های مجازی نیستند. بنابراین، هنگامی که یک نمونه EC2 را چرخانید، اساساً یک VM دریافت می کنید لایه مجازی. سپس، وقتی Docker را در بالای آن نصب می‌کنید، در حال اضافه کردن یک لایه مجازی دیگر هستید! و همه اینها روی یک ماشین معمولی با چند CPU و مقداری RAM اتفاق می افتد.

می‌دانید وقتی لایه‌های مجازی‌سازی بیشتر و بیشتری را انباشته می‌کنید چه اتفاقی می‌افتد؟ آنها شما را از عملکرد فلزی سخت افزار دورتر و دورتر می کنند.

و Kubernetes برای برنامه های کوچک؟ این مانند استفاده از بازوکا برای کشتن مگس است. مطمئناً، من می‌دانم که برنامه‌های Docker را می‌توان به روش‌های مختلفی در AWS (نه تنها در بالای EC2) مستقر کرد، اما این موضوع نیست. برنامه وب کوچک من به هیچ یک از “مزایای” Docker Van نیاز ندارد.

“با Docker، برنامه من می تواند در همه جا اجرا شود” – زیرا دیگر به سیستم عامل متصل نیست. اما من قصد ندارم برنامه ام را در جایی به جز دبیان اجرا کنم. من می دانم ماشین های مجازی اجزای برنامه من چگونه کار می کنند. من خودم آنها را تنظیم می کنم و دقیقاً می دانم چه چیزی آنجاست.
“Docker یک محیط ایزوله فراهم می کند” مطمئنا، اما جدا از چه؟ ماشین های مجازی مجزا در حال حاضر انزوای زیادی را ارائه می دهند.

در مورد بسته‌بندی و جداسازی نرم‌افزار اجزای مختلف و مدیریت تضادهای نسخه. اگر این نیاز اولیه شما به Docker حتی در پروژه های کوچک است… شیطان، شیطان – آیا از TypeScript/Python خالص صرف نظر کرده اید و به کتابخانه های خارجی بسیار متکی بوده اید؟ اتفاقا مورد من نیست.

چرا باید تبلیغات کانتینری‌سازی را دنبال کرد فقط به این دلیل که دیگران آن را انجام می‌دهند؟

با این حال، من Docker را به طور کامل از پشته خود بیرون نمی اندازم. اما برای من، dockerization چیزی است که فقط زمانی در نظر خواهم گرفت که همه چیز آماده باشد.

علاوه بر این، Docker/Containerization به همان سادگی مجازی سازی/ماشین های مجازی است. سینتاکسی های مختلف، برخی مفاهیم متفاوت، اما منطق پشت آن کم و بیش یکسان است. وقتی صحبت از راه‌اندازی همه چیز به‌صورت پیش‌فرض به میان می‌آید، Docker آسان است، اما اگر به چیز پیشرفته‌تری نیاز دارید، به احتمال زیاد اگر چیزی در مورد مجازی‌سازی سخت‌افزار و ماشین‌های مجازی ندانید، بسیار ناامید خواهید شد. داکر برای کسانی که تجربه ای با ماشین های مجازی دارند اصلاً علم موشکی نیست.

پس بیایید با مجازی سازی در دبیان شروع کنیم!

➂ مجازی سازی در دبیان: چگونه کار می کند

فرآیند مجازی سازی تحت “دستورالعمل های” رایانه شخصی شما انجام می شود فیزیکی CPU، بنابراین مهم است که CPU شما از آن پشتیبانی کند. بله، ماشین‌های مجازی می‌توانند (در صورت اجازه) به اجزای سخت‌افزاری مختلف رایانه شخصی شما دسترسی داشته باشند، اما این دقیقاً CPU است که مسئول جداسازی فرآیند در حال اجرا در ماشین‌های مجازی مهمان از میزبان (رایانه شخصی شما) است. اگر CPU شما از مجازی سازی پشتیبانی می کند، ابتدا باید آن را در رایانه شخصی خود فعال کنید:

➂.➀ پشتیبانی از مجازی سازی CPU

برای اینکه بدانید پشتیبانی مجازی‌سازی را فعال کرده‌اید، می‌توانید بررسی کنید که آیا پرچم مربوطه با grep فعال است یا خیر. اگر دستور زیر برای پردازنده شما مقداری متن را برمی گرداند، از قبل پشتیبانی مجازی سازی را فعال کرده اید:
برای پردازنده های اینتل می توانید اجرا کنید grep vmx /proc/cpuinfo برای بررسی برنامه های افزودنی ماشین مجازی اینتل.
برای پردازنده های AMD می توانید اجرا کنید grep svm /proc/cpuinfo برای بررسی ماشین مجازی امن AMD. (راهنمای مدیر دبیان: مجازی سازی)

در مورد من:

#this command is counting the number of times 'vmx flags' is mentioned in the output of /proc/cpuinfo. It is equal to 20, meaning that all my CPU cores support virtualization (I have 20 cores totale)
$ egrep -c '(vmx flags)' /proc/cpuinfo
20
#additional command
$ lscpu | grep Virtualization
Virtualization:       VT-x

اگر در مورد شما خروجی فرمان grep vmx /proc/cpuinfo خالی است، اما CPU شما کاملاً مدرن است و قرار است از مجازی سازی پشتیبانی کند، باید در هنگام بوت وارد BIOS شده و آن را در آنجا فعال کنید. مراحلی که باید در BIOS دنبال کنید چیزی شبیه به توضیح در این راهنما است. رابط بایوس شما به برند مادربرد شما بستگی دارد، بنابراین اگر گم شده اید، باید دستورالعمل های فعال کردن مجازی سازی را در رایانه شخصی خود در وب بررسی کنید.

تمام هسته های CPU آماده مجازی سازی چیزی هستند! چه کسی شروع می کند؟

➂.➁ هایپروایزر

یک هایپروایزر! Hypervisor یک اصطلاح کلی است:

هایپروایزر که به عنوان مانیتور ماشین مجازی (VMM) یا مجازی ساز نیز شناخته می شود، نوعی نرم افزار، سفت افزار یا سخت افزار کامپیوتری است که ماشین های مجازی را ایجاد و اجرا می کند. کامپیوتری که هایپروایزر یک یا چند ماشین مجازی را روی آن اجرا می کند، ماشین میزبان و هر ماشین مجازی را ماشین مهمان می نامند. (ویکی پدیا)

هایپروایزر انواع مختلفی دارد که برای ساده کردن درک آنها می توان آنها را به 2 نوع 9lefy و تصاویر سمت راست از طرح زیر تقسیم کرد:

توضیحات تصویر

اگر تا به حال از VirtualBox استفاده کرده باشید، ممکن است نوع دوم هایپروایزر برای شما آشنا باشد. این برنامه در ویندوز مانند هر برنامه دیگری در ویندوز اجرا می شود. از طرف دیگر هایپروایزرهای نوع 1 مستقیماً روی فلز خالی اجرا شود. آنها اغلب سیستم عامل خود را دارند که به طور خاص برای اهداف مجازی سازی تنظیم شده است. و اغلب برای حوزه سازمانی استفاده می شوند.

من Proxmox را در دسته هایپروایزرهای نوع 2 قرار دادم، زیرا به عنوان یک سیستم عامل مبتنی بر دبیان عرضه می شود. برای استفاده از آن، باید دبیان دسکتاپ فعلی خود را با سیستم عامل Proxmox جایگزین کنید. به هر حال، Proxmox بسیار عالی است – استفاده از آن آسان و دارای عملکرد غنی است. من از این هایپروایزر برای کار استفاده می کنم و آن را عالی می دانم. اما اینکه Proxmox هایپروایزر نوع 1 است، از نظر فنی کاملاً صحیح نیست، زیرا مبتنی بر KVM&QEMU است.

بیایید به KVM برسیم، که در وسط تصویر بالا شماتیک شده است. آیا این یک هایپروایزر است؟ خوب … بله و نه. اصطلاح “هایپروایزر” عمومی است، بنابراین شما می توانید آن را اینگونه بنامید. اما از نظر فنی، KVM یک ماژول هسته لینوکس است. نیازی نیست خودتان آن را بسازید – آن را با هسته لینوکس که بخش اصلی دبیان شما است، ارسال می شود، درست مانند سایر ماژول های هسته (به عنوان مثال، درایورها).

در این مقاله، من از KVM برای راه اندازی ابزار مجازی سازی روی رایانه شخصی خود استفاده خواهم کرد. یک جایگزین محبوب برای KVM در دبیان Xen است. Xen یک است واقعا Hypervisor نوع 1، حتی اگر می تواند در کنار سیستم عامل Debian برای استفاده شخصی نیز اجرا شود.

Xen یک راه حل “paravirtualization” است. این یک لایه انتزاعی نازک به نام “hypervisor” بین سخت افزار و سیستم های فوقانی معرفی می کند. این به عنوان یک داور عمل می کند که دسترسی به سخت افزار از ماشین های مجازی را کنترل می کند. (راهنمای مدیر دبیان: مجازی سازی)

همانطور که Xen اجرا می شود بین سخت افزار و سیستم های بالایی به عنوان یک هایپروایزر نوع 1 واجد شرایط است. VMware ESXi نمونه دیگری از Hypervisor نوع 1 است.

من از تنظیمات مجازی سازی مبتنی بر KVM به جای Xen استفاده خواهم کرد – فقط یک ترجیح شخصی.

➃ KVM و QEMU

اما KVM علاوه بر اینکه یک ماژول هسته است دقیقاً چیست؟

Kernel Virtual Machine یا KVM یک راه حل مجازی سازی کامل برای لینوکس در x86 (شامل 64 بیت) و سخت افزار ARM حاوی پسوند مجازی سازی (Intel VT یا AMD-V) است. این شامل یک ماژول هسته قابل بارگیری به نام kvm.ko است که زیرساخت مجازی سازی هسته و یک ماژول خاص پردازنده، kvm-intel.ko یا kvm-amd.ko را فراهم می کند. (ویکی دبیان: KVM)

در حالی که KVM بیشتر زیرساخت هایی را ارائه می دهد که می تواند توسط مجازی ساز استفاده شود، اما به خودی خود یک مجازی ساز نیست. کنترل واقعی برای مجازی سازی توسط یک برنامه کاربردی مبتنی بر QEMU انجام می شود.
برخلاف سایر سیستم های مجازی سازی، KVM از همان ابتدا در هسته لینوکس ادغام شد. توسعه دهندگان آن ترجیح دادند از مجموعه دستورالعمل های پردازنده اختصاص داده شده به مجازی سازی (Intel-VT و AMD-V) استفاده کنند که KVM را سبک وزن، ظریف و تشنه منابع نمی کند. البته همتای آن این است که KVM روی هیچ کامپیوتری کار نمی کند، بلکه فقط روی کامپیوترهایی کار می کند که پردازنده های مناسبی دارند.
برخلاف ابزارهایی مانند VirtualBox، KVM خود هیچ رابط کاربری برای ایجاد و مدیریت ماشین‌های مجازی ندارد. (راهنمای مدیریت دبیان: مجازی‌سازی)

قبلا نشان دادم که چگونه می توان بررسی کرد که مجازی سازی در رایانه شخصی شما فعال است یا خیر، دستور زیر به شما نشان می دهد که آیا ماژول هسته KVM دارید و می توان از آن استفاده کرد:

# checking for presence of KVM kernel modules
$ lsmod | grep kvm
kvm_intel             327680  0
kvm                   983040  1 kvm_intel
#Additional check with cpu-checker package:
$ sudo apt install cpu-checker 
$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

همانطور که کتابچه راهنمای مجازی سازی دبیان در نقل قول بالا بیان شده است، KVM به تنهایی همراه با qemu برای porocesses مجازی سازی است.

QEMU (مخفف Quick Emulator) یک شبیه ساز و مجازی ساز ماشین عمومی و منبع باز است.
زمانی که از QEMU به عنوان شبیه‌ساز ماشین استفاده می‌شود، می‌تواند سیستم‌عامل‌ها و برنامه‌های ساخته شده برای یک دستگاه (مثلاً یک برد ARM) را بر روی یک دستگاه دیگر (مثلاً رایانه شخصی شما) اجرا کند. با استفاده از ترجمه پویا به عملکرد بسیار خوبی دست می یابد.
هنگامی که به عنوان مجازی ساز استفاده می شود، QEMU با اجرای کد مهمان به طور مستقیم بر روی CPU میزبان به عملکرد نزدیک به بومی می رسد. QEMU هنگام اجرای تحت هایپروایزر Xen یا استفاده از ماژول هسته KVM در لینوکس از مجازی سازی پشتیبانی می کند. هنگام استفاده از KVM، QEMU می تواند x86، سرور و PowerPC جاسازی شده، POWER 64 بیتی، S390، ARM 32 و 64 بیتی و مهمانان MIPS را مجازی کند. (QEMU Wiki)

آیا فقط با استفاده از KVM امکان مجازی سازی وجود دارد؟ از نظر تئوری بله، اما KVM نه رابط کاربری گرافیکی دارد و نه CLI، بنابراین برای مجازی سازی چیزی باید کد را به زبان C بنویسید، اما KVM به تنهایی از CPU مجازی یا RAM مجازی تقلید نمی کند.
آیا می توانید از QEMU بدون KVM استفاده کنید؟ بله. QEMU به تنهایی می تواند تقلید کردن یک سیستم کامل با مترجم داخلی کد Tiny Code Generator (TCG) که صرفا شبیه سازی شده است (= محاسبات فشرده) و عملکرد کلی سیستم کاملا شبیه سازی شده می تواند کند باشد. بنابراین، استفاده از QEMU بدون شتاب دهنده ناکارآمد است و به طور کلی برای مقاصد آزمایشی بهترین است (مثلاً اگر CPU شما دارای معماری A است، اما شما کنجکاو هستید که در مورد نحوه عملکرد آن در معماری B CPU). برای “تسریع” سیستم شبیه سازی شده که بر روی همان معماری اجرا می شود به QEMU یک میزبان، از شتاب دهنده ها استفاده می کند. و KVM یکی از آنهاست. با این حال، QEMU می‌تواند از شتاب‌دهنده‌های جایگزین مانند XEN (QEMU: Virtualisation Accelerators) استفاده کند.

QEMU یک بسته نرم افزاری نیست که از قبل روی دبیان نصب شده باشد، بنابراین باید آن را به صورت دستی نصب کنید. و اینجاست که ممکن است سردرگمی ایجاد شود. اگر در گوگل سرچ کنید، به احتمال زیاد چیزی شبیه به این را برای سیستم های مبتنی بر دبیان خواهید یافت sudo apt install qemu-kvm virt-manager bridge-utils. در نگاه اول، به نظر خوب می رسد – شما در واقع برای کار با KVM به QEMU نیاز دارید. اما بخش مشکل اینجاست: qemu-kvm حتی یک بسته واقعی نیست این یک بسته مجازی است که در واقع به چیز دیگری اشاره دارد:

توضیحات تصویر

برای مورد من، خوب است زیرا من قصد دارم همه مهمانانم از این معماری استفاده کنند. اما اگر می خواهید از معماری متفاوتی برای VM های مهمان خود استفاده کنید، qemu-kvmبسته اضافی را به همراه خواهد داشت. بسته های دیگری نیز وجود دارند که QEMU را نصب می کنند qemu-system-x86, مانند qemu-system-arm، qemu-system-misc، qemu-system-ppc و qemu-system، که وابستگی هایی را برای مجازی سازی/شبیه سازی معماری های مختلف با qemu به شما می آورد.

من QEMU را به این ترتیب نصب خواهم کرد:

$ sudo apt install qemu-system-x86

برای اینکه کمی انتخاب خود را شکل دهید، طبق اسناد QEMU در مجازی سازی با KVM:

QEMU می تواند از KVM هنگام اجرای یک معماری هدف که همان معماری میزبان است استفاده کند. به عنوان مثال، هنگام دویدن qemu-system-x86 در یک پردازنده سازگار با x86، می‌توانید از شتاب KVM استفاده کنید – به شما مزایایی برای میزبان و سیستم مهمان خود می‌دهد (QEMU: ویژگی‌های KVM)

از نظر فنی، اگر بخواهید مهمانی با معماری CPU متفاوت از CPU دستگاه میزبان خود ایجاد کنید، KVM استفاده نمی شود، زیرا، به یاد داشته باشید، QEMU می تواند به طور کامل ماشین ها را شبیه سازی کند (البته من خودم این را آزمایش نکرده ام).

QEMU نصب شده است، KVM آماده مجازی سازی است، بنابراین همه چیز از نظر فنی تنظیم شده است. با این حال، نحو QEMU CLI بسیار ساده و خاص نیست. من ترجیح می دهم از نحوی استفاده کنم که برای من آشناتر است. و اینجاست که Libvirt به من کمک خواهد کرد.

➄ Libvirt

Libvirt مجموعه‌ای از نرم‌افزار است که روشی مناسب برای مدیریت ماشین‌های مجازی و سایر قابلیت‌های مجازی‌سازی، مانند مدیریت ذخیره‌سازی و رابط شبکه ارائه می‌دهد.
هدف اصلی libvirt ارائه یک راه واحد برای مدیریت چندین ارائه دهنده/هایپروایزر مجازی سازی مختلف است. بدون نیاز به یادگیری ابزارهای خاص Hypervisor! (سؤالات متداول Libvirt)

Libvirt یک بسته نرم افزاری است که شامل یک کتابخانه API، یک شبح (libvirtdو یک ابزار خط فرمان (virsh).

ابزارهای Libvirt برای مدیریت ماشین های مجازی عبارتند از 'virsh'، 'virt-manager' و 'virt-install' که همگی بر اساس عملکرد libvirt ساخته شده اند.

توضیحات تصویر

virt-manager یک ابزار رابط کاربری گرافیکی برای ایجاد و مدیریت ماشین های مجازی به طور کامل از طریق یک رابط کاربری گرافیکی (GUI) است <-- می تواند یک گزینه قابل اجرا در ابتدا باشد.
virt-install یک ابزار CLI است که ایجاد و مدیریت ماشین های مجازی را از طریق دستورات و پارامترها امکان پذیر می کند. اگر ماشین های مجازی ساخته شده قرار است نمایشگر و جلسات گرافیکی داشته باشند، می توان به آنها دسترسی داشت virt-viewer (برای نمایش).
virsh یک ابزار خط فرمان است که می تواند کارهای زیادی را انجام دهد – از کارهای بسیار ساده مانند ایجاد VM تا مجازی سازی پیشرفته. virsh به خوبی با فایل های پیکربندی XML کار می کند، که می تواند برای پیکربندی دامنه ها، مشخصات ماشین مجازی، شبکه ها و غیره استفاده شود. Virsh گزینه ای برای اتصال به VM های موجود از راه دور از طریق SSH می دهد <-- من از این ابزار استفاده خواهم کرد.

نصب میکنم libvirt با دستور زیر:

$ sudo apt install libvirt-daemon-system
$ systemctl status libvirtd
● libvirtd.service - libvirt legacy monolithic daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-01-10 22:39:29 CET; 2min 17s ago
#if not enabled in your case:
# $ sudo systemctl enable libvirtd

به این ترتیب خواهم داشت libvirt-clients همچنین نصب شده است، زیرا وابسته به این بسته است.

قرار است همه چیز مورد نیاز فعلا نصب شود. ابتدا، می‌خواهم تأیید کنم که همه چیز درست است، و سپس می‌توانم ابتدا ساخت VM را ادامه دهم.

➅ اعتبار سنجی ابزارهای مجازی سازی نصب شده

$ virt-host-validate
  QEMU: Checking for hardware virtualization  : PASS
  QEMU: Checking if device '/dev/kvm' exists  : PASS
  QEMU: Checking if device '/dev/kvm' is accessible : PASS
  ...
$ virsh version
Compiled against library: libvirt 10.10.0
Using library: libvirt 10.10.0
Using API: QEMU 10.10.0
Running hypervisor: QEMU 9.2.0

#command to check, which guest machines you can emulate with QEMU features you have installed:
$ virsh capabilities
...
  
    hvm
     <---
      32 <---
      /usr/bin/qemu-system-i386
      ...
       <---
        <---
    
  

  
    hvm
     <---
      64 <---
      /usr/bin/qemu-system-x86_64
      ...
       <---
        <---

➅.➀ مهم! qemu:///system در مقابل qemu:///session

این دستوری است که می خواهم به آن توجه کنید:

$ virsh uri
qemu:///session

$ sudo virsh uri
qemu:///system

همانطور که می بینید، بین دویدن تفاوت وجود دارد virsh با sudo یا بدون آن وقتی می دوی virsh با sudo، به سیستم متصل می شود libvirtd سرویس راه اندازی شده توسط systemd. libvirtd به صورت روت اجرا می شود، بنابراین به تمام منابع میزبان دسترسی دارد. پیکربندی Daemon وارد شده است /etc/libvirt، گزارش های VM و سایر بیت ها در آن ذخیره می شوند /var/lib/libvirt.
برعکس، اگر بدوید virsh بدون sudo، به آن متصل می شود qemu:///session، که یک جلسه است libvirtd سرویسی که به‌عنوان کاربر برنامه اجرا می‌شود، اگر دیمون قبلاً اجرا نشده باشد، به‌طور خودکار راه‌اندازی می‌شود. libvirt و تمام ماشین های مجازی به عنوان کاربر اجرا می شوند. همه پیکربندی‌ها و گزارش‌ها و تصاویر دیسک در آن ذخیره می‌شوند $HOME دایرکتوری یک کاربر این بدان معنی است که هر کاربر ویژگی های خود را دارد qemu:///session ماشین های مجازی، جدا از همه کاربران دیگر. جزئیات از اینجا گرفته شده است.

اگر بنا به دلایلی خروجی شما از virsh uri خالی است، می توانید به صورت دستی وصل شوید. و اگر بین جلسه یا سیستم بهم ریخته باشید، در خروجی از آن مطلع خواهید شد.

$ virsh
virsh # connect qemu:///system
==== AUTHENTICATING FOR org.libvirt.unix.manage ====
System policy prevents management of local virtualized systems

#The correct way if you want to connect to user-space session:
virsh # connect qemu:///session
#The correct way if you want to connect to system wide session:
$ sudo virsh
virsh # connect qemu:///system

این اطلاعات بسیار مهم است:

با qemu:///session، libvirtd و VM ها به عنوان کاربر غیرمجاز شما اجرا می شوند. این با موارد استفاده از دسکتاپ بهتر ادغام می شود زیرا مجوزها مشکلی ندارند، هیچ رمز عبور root مورد نیاز نیست و هر کاربر دارای استخر مجزای ماشین های مجازی خود است.
با این حال، از آنجایی که هیچ چیز در زنجیره ممتاز نیست، هر کار راه اندازی VM که به امتیازات سرپرست میزبان نیاز دارد، یک گزینه نیست. متأسفانه این شامل اکثر گزینه های شبکه با هدف عمومی می شود.
حالت پیش‌فرض شبکه qemu هنگام اجرا بدون امتیاز، شبکه حالت کاربر (یا SLIRP) است. این یک پشته IP است که در فضای کاربران پیاده سازی شده است. این ایرادات زیادی دارد: دنیای خارج به راحتی نمی‌تواند به ماشین مجازی دسترسی داشته باشد، ماشین مجازی می‌تواند با دنیای بیرون صحبت کند اما فقط از طریق تعداد محدودی از پروتکل‌های شبکه، و سرعت آن بسیار کند است. (منبع)

اگر این نقل قول چیز زیادی به شما نمی گوید، نکته مهم در اینجا آمده است: qemu:///session بهتر ادغام می شود با موارد استفاده دسکتاپ. هر راه اندازی VM وظایف که به امتیازات ادمین میزبان نیاز دارند، گزینه ای نیستند. این بدان معنی است که ماشین های مجازی شما در محدوده qemu:///session فقط گزینه های شبکه با هدف عمومی را خواهد داشت.

➆ ایجاد اولین VM

NB! برای اهداف نمایشی، من اولین VM را در محدوده ایجاد خواهم کرد qemu:///session. به این ترتیب، من قادر خواهم بود محدودیت های VM ایجاد شده را نشان دهم. سپس، من به شما نشان خواهم داد که چگونه VM را به زیر منتقل کنید qemu:///system.

➆.➀ فایل تصویری سیستم عامل

برای ایجاد اولین ماشین مجازی خود، که البته Debian Stable (Bookworm) خواهد بود، به یک .iso فایل من برای مرتب نگه داشتن سیستم به سراغ تصویر حداقل netinstall می‌روم و بعداً فقط ابزارهایی را که نیاز دارم نصب می‌کنم.

$ cd #to teleport to $HOME directory
$ mkdir -p .local/share/libvirt/images/
$ cd .local/share/libvirt/images/
$ wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.9.0-amd64-netinst.iso

➆.➁ آماده سازی ذخیره سازی

سپس، می‌خواهم دستگاه ذخیره‌سازی را که قصد دارم برای همه ماشین‌های مجازی خود استفاده کنم، مشخص کنم (زیرا آنها بخش‌هایی از آن را به اشتراک خواهند گذاشت). از آنجایی که من تمام دستگاه‌های ذخیره‌سازی رایانه شخصی خود را با استفاده از LVM مدیریت می‌کنم، اولین قدم ایجاد یک حجم منطقی جدید با استفاده از فضای آزاد موجود در گروه حجم منطقی موجود من است.

$ sudo vgs
  VG            #PV #LV #SN Attr   VSize    VFree
  MY-vg       1   5   0 wz--n- <372.53g <129.02g

ماشین های مجازی من چگونه از فضای ذخیره سازی که قصد دارم برای آنها ایجاد کنم استفاده خواهند کرد؟ هر ماشین یک یا چند دیسک مجازی خواهد داشت و این دیسک های مجازی در اصل “تصاویر دیسک” هستند. از آنجایی که همه چیز در سیستم عامل لینوکس یک فایل است، این تصاویر دیسک فایل هستند. و می توانند فرمت های مختلفی داشته باشند. را .qcow فرمت یک فرمت فایل برای فایل های تصویر دیسک است که توسط QEMU استفاده می شود. نسخه به روز شده آن، .qcow2، بهینه سازی بهتری را نسبت به نسخه اصلی ارائه می دهد .qcow. من همچنین می توانم تصاویر دیسک را برای ماشین های مجازی در داخل ایجاد کنم .raw قالب با این حال، .qcow2 به طور کلی از نظر فضا کارآمدتر است و می توان آن را عکس فوری و فشرده کرد.

بنابراین وظیفه به شرح زیر است: من نیاز به ایجاد یک .qcow2 تصویر دیسک برای VM من ایجاد شود. و من می خواهم از فضای موجود در گروه حجم منطقی خود استفاده کنم.

دو گزینه وجود دارد:

من می توانم یک حجم منطقی نسبتاً بزرگ جدید ایجاد کنم تا فضا را برای چندین ماشین مجازی فراهم کنم. در این مورد، من باید یک سیستم فایل را در بالای حجم منطقی جدید قرار دهم، آن را نصب کنم و سپس ایجاد کنم. .qcow2 تصاویر دیسک روی آن چرا؟ زیرا یک حجم منطقی بدون سیستم فایل یک بلوک ذخیره سازی منفرد و پیوسته است. یک مجرد .qcow2 می تواند کل دستگاه بلوک را اشغال کند، اما مکانیزمی برای ذخیره چندین فایل در یک دستگاه وجود ندارد مگر اینکه یک سیستم فایل وجود داشته باشد.
گزینه دوم ایجاد حجم های منطقی جداگانه با اندازه نیازهای هر ماشین مجازی است که هر حجم منطقی به طور کامل به یک واحد اختصاص داده شود. .qcow2 تصویر به هر حال، شما همچنین می توانید از پارتیشن های فیزیکی برای ماشین های مجازی خود استفاده کنید، زیرا حجم های منطقی تنها روش ترجیحی من برای مدیریت فضای ذخیره سازی است. با این حال، حتی اگر زیر هر یک .qcow2 تصویر حجم منطقی “شخصی” آن وجود دارد، این بدان معنا نیست که می توانید اندازه آن را افزایش دهید .qcow2 تصویر با گسترش
حجم منطقی نه اصلا اگر فضای VM من تمام شود، باید یک “دیسک مجازی” جدید وصل کنم، یک حجم منطقی اضافی ایجاد کنم، و جدید ایجاد کنم. .qcow2 تصویر روی آن …. این به سرعت به یک آشفتگی تبدیل می شود.

بنابراین، من گزینه اول را ترجیح می دهم: یک حجم منطقی واحد به عنوان نوعی استخر ذخیره برای همه تصاویر دیسک ماشین های مجازی من.

اگر درک شما از اصطلاحات LVM کمی است لرزان و شما هنوز گیج می شوید گروه های حجم منطقی با حجم های منطقی، خواندن این مقاله را توصیه می کنم.

#I create new logical volume with name 'virt-machines' inside of the existing volume group
$ sudo lvcreate -L 100G -n virt-machines MY-vg
# I create filesystem on top of it 
$ sudo mkfs.ext4 /dev/MY-vg/virt-machines
# I create a mounting point for it
$ sudo mkdir -p /mnt/virt-machines
# I mount it
$ sudo mount /dev/MY-vg/virt-machines /mnt/virt-machines
# i add automounting option on boot with by modifying /etc/fstab
$ sudo vim.tiny /etc/fstab
# I add this line 
/dev/mapper/MY--vg-virt--machines /mnt/virt-machines ext4 defaults 0 0
# to validate syntax:
$ sudo mount -a

اکنون، من می توانم یک را ایجاد کنم .qcow2 تصویر دیسک در این فهرست از آنجایی که قصد دارم VM ها را در فضای کاربری خود ایجاد و اجرا کنم، مالکیت این فهرست را به کاربر خود داده ام تا بعداً از هرگونه مشکل مجوز جلوگیری کنم.

# I create a .qcow2 disk image
$ sudo qemu-img create -f qcow2 /mnt/virt-machines/deb-nginx.qcow2 10G

من یک .iso فایلی که ماشین مجازی از آن بوت می شود (که به عنوان یک CDROM مجازی ضمیمه خواهد شد)، و من یک دیسک مجازی دارم که سیستم جدید در آن نصب خواهد شد. اکنون فقط باید یک VM ایجاد کنم و هسته های CPU و RAM را به آن اختصاص دهم. برای اولین ایجاد VM، از آن استفاده خواهم کرد virt-install به جای virsh برای نشان دادن منطق، و سپس با توضیحات پیکربندی XML ادامه دهید. را virt-install CLI بخشی از virtinst بسته بندی شده و در آن گنجانده نشده است libvirt-clients بسته بندی نیاز به نصب جداگانه دارد.

➆.➂ ایجاد VM با `virt-install`

من از گزینه های پیش فرض استفاده خواهم کرد virt-install دستور، با دو استثنا: –-graphics none و --extra-args="console=ttyS0". ماشین های مجازی من نیازی به رابط گرافیکی ندارند زیرا سرورهای نمایشگر ندارند. من از طریق کنسول به آنها دسترسی خواهم داشت. دبیان نه تنها یک نصب کننده گرافیکی، بلکه یک نصب کننده رابط کاربری ترمینال (TUI) نیز ارائه می دهد که فرآیند نصب را راهنمایی می کند.

$ sudo apt install virtinst
$ virt-install \
  --connect qemu:///session \
  --name deb-nginx \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/mnt/virt-machines/deb-nginx.qcow2,size=10 \
  --location $HOME/.local/share/libvirt/images/debian-12.8.iso \
  --os-variant debian12 \
  --graphics none \
  --extra-args="console=ttyS0"

اگر با خطا مواجه شدید:

Traceback (most recent call last):
  File "/usr/bin/virt-install", line 6, in 
    from virtinst import virtinstall
  File "/usr/share/virt-manager/virtinst/__init__.py", line 8, in 
    import gi
ModuleNotFoundError: No module named 'gi'

بررسی کنید که آیا در حال حاضر در هیچ محیط فعال پایتون نیستید. من از آناکوندا استفاده می کنم، بنابراین base محیط conda همیشه فعال است. فقط با غیر فعالش میکنم conda deactivate دستور قبل از اجرا virt-install فرمان
این را خواهید دید:

توضیحات تصویر

و سپس نصب دبیان (فقط در TUI) باید ظاهر شود.

توضیحات تصویر

پس از اتمام نصب، VM راه اندازی مجدد می شود، من مجدداً با آگهی کنسول فعال ارتباط برقرار می کنم virsh.

$ virsh --connect qemu:///session console deb-nginx

توضیحات تصویر

در واقع، همه چیز آماده است، VM قابل استفاده است، بنابراین از نظر فنی می توانم سعی کنم به SSH بروم …

➇ اجازه دهید شبکه آغاز شود!

برای SSH در VM، باید آدرس IP خصوصی را بدانم که به آن اختصاص داده شده است (و فکر می‌کنم اینطور بود، زیرا انتظار دارم برخی از شبکه‌های پیش‌فرض پیکربندی شده باشند و VM در طول فرآیند ایجاد از طریق QEMU به آن ملحق شود). جزئیات نحوه عملکرد SSH از منظر شبکه را فعلاً خواهم گذاشت و در مقاله بعدی این مجموعه مجازی سازی به آن خواهم پرداخت.

برای پیدا کردن IP VM ایجاد شده:

root@deb-nginx:~# ip a
1: lo:  mtu qdisc noqueue state UNKNOWN 
....
2: enp1s0:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether MA:CA:DD:RE:SS:VM brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp1s0
       valid_lft 77570sec preferred_lft 77570sec
    inet6 XXXXXXXXXXXXXX/64 scope site dynamic mngtmpaddr
       valid_lft 86291sec preferred_lft 14291sec
    inet6 XXXXXXXXXXXXXXXX/64 scope link
       valid_lft forever preferred_lft forever

رابط شبکه enp1s0 و آدرس IPv4 10.0.2.15 است. بنابراین، بیایید ssh را امتحان کنیم!

#from Host machine!
$ ssh 10.0.2.15

Nothing!

➇.➀ اتصال فضای کاربری (SLIRP یا گذشته).

با این حال، همانطور که قبلا ذکر کردم، qemu:///session ماشین های مجازی در درجه اول برای استفاده در دسکتاپ در نظر گرفته شده اند، مانند آزمایش یک توزیع جدید. شبکه مورد استفاده تحت qemu:///session تا حدودی ابتدایی و محدود کننده است – اجازه اتصالات ورودی به ماشین های مجازی را نمی دهد و نمی توان آن را به درستی تغییر داد. برای مثال، نمی‌توانید تنظیمات شبکه پیچیده‌تری را بدون آن پیکربندی کنید sudo امتیاز برای ایجاد اجزای شبکه مانند پل ها، تغییر وضعیت آنها و غیره.

من می توانم بررسی کنم که کدام شبکه برای این VM پیکربندی شده است و به طور کلی می توانم پیکربندی کامل VM ایجاد شده را بررسی کنم. وقتی استفاده کردم virt-install، من به سادگی برخی از گزینه ها را در طول فرآیند ایجاد برای مشخص کردن ارسال کردم چگونه من ماشین مجازی خود را می خواستم و آن پارامترها به فایل پیکربندی ترجمه شدند. این فایل بسیار دقیق تر و “فنی”تر از لیست گزینه هایی است که هنگام ایجاد VM ارائه کردم. QEMU الزامات من را به طور کامل به مشخصات فنی ترجمه کرد، سخت افزار لازم را تخصیص داد و سایر اجزا را برای کار VM من پیکربندی کرد. فرمت پیکربندی استفاده شده توسط virsh زیرا تقریباً همه چیز XML است.

VM ایجاد شده دارای یک رابط شبکه است، فقط یک. اما در فایل پیکربندی XML می بینم که این رابط دارای نوع “user” است. ، و معمولاً نوع آن باید “شبکه” باشد.

من می توانم جایگزین های موجود (سایر رابط های شبکه) را بررسی کنم. زیر qemu:///sessionهمانطور که انتظار می رود، چیزی وجود ندارد:

$ virsh net-list --all

 Name   State   Autostart   Persistent
----------------------------------------

با این حال، به نظر می رسد که اکنون می توان این شبکه فضای کاربران را به طور گسترده پیکربندی کرد، زیرا نسخه های جدیدتر libvirt ویژگی ها و گزینه های پیشرفته تری را معرفی کرده اند:

از 9.0.0 می توان با تنظیم ویژگی نوع عنصر فرعی اینترفیس روی گذشته، یک پیاده سازی باطن جایگزین از نوع رابط کاربری انتخاب کرد. در این حالت از حمل و نقل گذشته (https://passt.top) استفاده می شود. مشابه SLIRP، Past دارای یک سرور DHCP داخلی است که به مهمان درخواست کننده یک آدرس ipv4 و یک آدرس ipv6 ارائه می دهد. سپس از پراکسی‌های فضای کاربر و یک فضای نام شبکه مجزا برای ارائه جلسات UDP/TCP/ICMP خروجی استفاده می‌کند و به‌جای آن ترافیک ورودی مقصد میزبان را به سمت مهمان هدایت می‌کند. (Libvirt: اتصال فضای کاربری

با این حال، پیکربندی اتصال فضای کاربر خارج از محدوده این مقاله (و همچنین مقاله بعدی در مورد شبکه) است. در مورد استفاده من، من در واقع به ارسال پورت نیازی ندارم – من به چیزی متفاوت نیاز دارم.

➇.➁ ارسال NAT (با نام مستعار “شبکه های مجازی”)

با این حال، qemu:///system دارای یک رابط پیش فرض (NAT):

 $ sudo virsh net-list --all

 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   no          yes

بنابراین، من فقط یک VM را دوباره ایجاد می کنم qemu:///system scope و این VM به طور پیش فرض از این شبکه “پیش فرض” استفاده خواهد کرد.

ابتدا باید VM را از بین ببرم و تعریف نکنم qemu:///session.

$ virsh destroy deb-nginx
$ virsh undefine deb-nginx
#(optionally, recreare disk image)
$ sudo rm /mnt/virt-machines/deb-nginx.qcow2
$ sudo qemu-img create -f qcow2 /mnt/virt-machines/deb-nginx.qcow2 10G
#IMPORTANT! Start dafault network if it is not started yet
$ sudo virsh net-start default

$ sudo virt-install \
  --connect qemu:///system \
  --name test \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/mnt/virt-machines/deb-nginx.qcow2,size=10 \
  --location /var/lib/libvirt/images/debian-12.9.iso \
  --os-variant debian12 --graphics none \
--extra-args="console=ttyS0"

لطفا توجه داشته باشید جایی که فایل ISO را قرار دادم. اگر داخل آن قرار دهید /etc/libvirt/در برخی از پوشه ها، از آنجایی که ممکن است مکان مناسبی به نظر برسد، ممکن است با یک خطای عجیب و غریب و گمراه کننده مواجه شوید، مانند:
error: internal error cannot load AppArmor profile 'libvirt-9cb01efc-ed3b-ff8e-4de5-7227d311dd15'.

اگر فایل ISO را در جایی زیر خود قرار دهید $HOME دایرکتوری، ممکن است اخطاری مانند این را ببینید:
هشدار /home/…./debian-12.8.iso ممکن است توسط Hypervisor قابل دسترسی نباشد. شما باید مجوزهای جستجوی کاربر 'libvirt-qemu' را برای دایرکتوری های زیر اعطا کنید: [‘/home/…’, ‘/home/….local’, ‘/home/…/.local/share’].

هر دو خطا مربوط به این واقعیت است که فرآیند ایجاد VM نمی تواند به فایل ISO دسترسی پیدا کند.

در همین حال من با نصب جدید از طریق TUI ادامه می دهم. من LVM را روی این ماشین مجازی راه اندازی کردم و قرار دادم /var در حجم منطقی جداگانه، زیرا این VM برای NGINX در نظر گرفته شده است و NGINX می تواند در گزارش های آن بسیار پرحرف باشد، به خصوص اگر پیکربندی بدی داشته باشد. اگر نمی دانید چگونه این کار را انجام دهید، به این مقاله مراجعه کنید. من همچنین سرور SSH را نصب کردم، بنابراین می توانم از میزبان به این VM ssh کنم.

اگر دارید توجه کنید ufw بالا! در حین نصب، دبیان باید شبکه را به صورت خودکار پیکربندی کند. اگر شکست خورد و این را مشاهده کردید:

توضیحات تصویر

… غیر فعال کردن ufw به طور موقت برای فرآیند نصب، سپس پس از آن دوباره آن را فعال کنید. این بهترین راه حل نیست، بهترین رویکرد تنظیم کردن است ufw قوانین می‌دهد تا درخواست‌های DHCP و وضوح DNS را مسدود نکند libvirt برای پیکربندی شبکه ماشین مجازی از طریق راه اندازی پیش فرض NAT استفاده می کند.

توضیحات تصویر

وقتی نصب کامل شد، کنسول را با virsh دوباره باز می کنم و وارد VM تازه ایجاد شده می شوم. ابتدا اجازه می دهد اتصال را بررسی کنم، آدرس IP را کشف کنم، سعی کنم از میزبان ssh کنم:

$ sudo virsh console deb-nginx
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=15.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=17.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=112 time=16.3 ms
# ip a
1: lo: 
.....
2: enp1s0:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether XXXXXXXXXXXXXXXX brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.125/24 brd 192.168.122.255 scope global dynamic enp1s0
       valid_lft 3217sec preferred_lft 3217sec
    inet6 XXXXXXXXXXXXXXXX scope link
       valid_lft forever preferred_lft forever

بنابراین، IP 192.168.122.125 است.
*NB! اگر سعی کنید اجرا کنید ssh 192.168.122.125 از میزبان، ورود ناموفق خواهد بود زیرا شما به طور خودکار سعی در ssh as دارید root، و root ورود از طریق ssh به طور پیش فرض در دبیان غیرفعال است.
*

من انجام می دهم:

$ ssh user@192.168.122.125
->yes
user@192.168.122.125's password:

بنابراین، از نقطه نظر شبکه چه کاری می توانم از این VM انجام دهم:

من می توانم به اینترنت دسترسی داشته باشم (مثلاً اجرا کنید apt update و apt upgrade).
من می توانم از دستگاه میزبان به این VM SSH کنم.

کاری که نمی توانم انجام دهم:

من یک لپ تاپ دارم که به همان شبکه خانگی کامپیوترم متصل است (از طریق WiFi). آیا می توانم از لپ تاپ به این VM SSH کنم؟ خیر به همین دلیل است:

$ ip route
default ...
.....
.....
.....
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

شبکه 192.168.122.0/24 فقط از طریق پل مجازی قابل دسترسی است virbr0.

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

ek3nk4r 2025-01-12

0 12 خواندن این مطلب 16 دقیقه زمان میبرد