Virt-v2v - عبر الإنترنت في السحابة

برنامج:

اسم

؛ Virt-v2v - تحويل الضيف لاستخدام KVM

موجز

Virt-v2v -ic vpx: //vcenter.example.com/Datacenter/esxi vmware_guest

Virt-v2v -ic vpx: //vcenter.example.com/Datacenter/esxi vmware_guest \
-o rhev -os rhev.nfs: / export_domain - شبكة rhevm

Virt-v2v -i libvirtxml guest-domain.xml -o local -os / فار / tmp

Virt-v2v -i disk disk.img -o local -os / فار / tmp

Virt-v2v -i disk disk.img -o لمحة

Virt-v2v -ic qemu: /// نظام qemu_guest - في المكان

الوصف

يحول Virt-v2v الضيوف من برنامج مراقبة أجنبي للتشغيل على KVM. يمكنه قراءة Linux و
ضيوف Windows الذين يعملون على VMware و Xen و Hyper-V وبعض برامج Hypervisor الأخرى ، ويقومون بالتحويل
منهم إلى KVM التي تديرها libvirt و OpenStack و oVirt و Red Hat Enterprise Virtualisation (RHEV)
أو عدة أهداف أخرى.

هناك أيضًا واجهة أمامية مصاحبة تسمى Virt-p2v(1) والذي يأتي في صورة ISO أو CD أو PXE
الصورة التي يمكن تشغيلها على الأجهزة المادية لإضفاء الطابع الافتراضي على تلك الأجهزة (المادية إلى
ظاهري أو p2v).

هذه الصفحة اليدوية توثق Virt-v2v المعاد كتابتها والمضمنة في libguestfs ≥ 1.28.

INPUT لأي لبس OUTPUT MODES

┌────────────┐ ┌───────── ▶ -o فارغ
-أنا القرص ────────────┐ │ │ ─┘┌─────── ▶ -o محلي
-i ova ──────────┐ └── ▶ │ Virt-v2v │ ──┘┌─────── ▶ -o qemu
└──── ▶ │ التحويل │ ───┘┌────────────┐
برنامج VMware─ ▶ ┌────────────┐ │ server │ ──── ▶ -o libvirt │─ ▶ KVM
Xen ─── ▶ │ -i libvirt ── ▶ │ │ │ (افتراضي) │
... ─── ▶ │ (افتراضي) │ │ │ ──┐ └────────────┘
└────────────┘ │ │ ─┐└────── ▶ -o لمحة
-i libvirtxml ───────── ▶ │ │ ┐└───────── ▶ -o rhev
└────────────┘ └────────── ▶ -o vdsm

يحتوي Virt-v2v على عدد من أوضاع الإدخال والإخراج الممكنة ، والتي يتم تحديدها باستخدام ملف -i -o
خيارات. يمكن تحديد وضع إدخال وإخراج واحد فقط لكل عملية تشغيل لـ Virt-v2v.

-i أسطوانة يستخدم للقراءة من صور القرص المحلي (بشكل أساسي للاختبار).

-i libvirt يستخدم للقراءة من أي مصدر libvirt. منذ libvirt يمكن الاتصال بالكثير
برامج Hypervisor مختلفة ، يتم استخدامها لقراءة الضيوف من VMware و RHEL 5 Xen والمزيد.
إنّ -ic الخيار يحدد مصدر libvirt الدقيق.

-i libvirtxml يستخدم للقراءة من ملفات libvirt XML. هذه هي الطريقة التي يستخدمها
Virt-p2v(1) وراء الكواليس.

-i البويضات يستخدم للقراءة من ملف مصدر ova VMware.

-o لمحة يُستخدم للكتابة إلى OpenStack Glance.

-o libvirt يستخدم للكتابة إلى أي هدف libvirt. يمكن ربط Libvirt بملفات
برامج Hypervisors KVM البعيدة. ال -أوك الخيار يحدد هدف libvirt الدقيق.

-o محلي يُستخدم للكتابة إلى صورة قرص محلي باستخدام ملف تكوين libvirt محلي
(بشكل أساسي للاختبار).

-o كيمو يكتب إلى صورة قرص محلي باستخدام برنامج نصي شل لإقلاع الضيف مباشرة في
qemu (بشكل أساسي للاختبار).

-o rhev يستخدم للكتابة إلى هدف RHEV-M / oVirt. -o com.vdsm يُستخدم فقط عند استخدام Virt-v2v
يعمل تحت سيطرة VDSM.

--في المكان يوجه Virt-v2v لتخصيص نظام التشغيل الضيف في الجهاز الظاهري للإدخال ،
بدلاً من إنشاء جهاز افتراضي جديد في برنامج Hypervisor المستهدف.

أمثلة

تحول تبدأ من في إم وير vCenter الخادم إلى محلي libvirt
لديك خادم VMware vCenter يسمى "vcenter.example.com" ، يسمى مركز البيانات
"Datacenter" ، و ESXi hypervisor يسمى "esxi". تريد تحويل ضيف يسمى
"vmware_guest" للتشغيل محليًا ضمن libvirt.

Virt-v2v -ic vpx: //vcenter.example.com/Datacenter/esxi vmware_guest

في هذه الحالة ، سيكون عليك على الأرجح تشغيل Virt-v2v كـ "root" ، لأنه يحتاج إلى التحدث
إلى البرنامج الخفي libvirt ونسخ أقراص الضيف إلى / var / lib / libvirt / images.

لمزيد من المعلومات ، راجع "الإدخال من خادم VMWARE VCENTER" أدناه.

تحول تبدأ من في إم وير إلى RHEV-M / أوفير
هذا هو نفس المثال السابق ، باستثناء أنك تريد إرسال الضيف إلى RHEV-M
تصدير مجال التخزين الموجود عن بعد (عبر NFS) في "rhev.nfs: / export_domain".
إذا لم تكن واضحًا بشأن موقع مجال تخزين التصدير ، فيجب عليك التحقق من
الإعدادات على وحدة التحكم في إدارة RHEV-M. واجهة (واجهات) شبكة الضيف متصلة بـ
الشبكة المستهدفة تسمى "rhevm".

Virt-v2v -ic vpx: //vcenter.example.com/Datacenter/esxi vmware_guest \
-o rhev -os rhev.nfs: / export_domain - شبكة rhevm

في هذه الحالة ، يعمل المضيف الذي يعمل على Virt-v2v كملف تحويل الخادم.

لاحظ أنه بعد التحويل ، سيظهر الضيف في مجال تخزين تصدير RHEV-M ،
من حيث ستحتاج إلى استيراده باستخدام واجهة المستخدم RHEV-M. (راجع "الإخراج إلى
RHEV ").

تحول أسطوانة صورة إلى كومة مفتوحة لمحة
إعطاء صورة قرص من برنامج Hypervisor آخر تريد تحويله للتشغيل على OpenStack
(يتم دعم OpenStack المستند إلى KVM فقط) ، يمكنك القيام بما يلي:

Virt-v2v -i disk disk.img -o لمحة

للتحكم في اسم الصورة في لمحة ، استخدم ملف أون الخيار.

تحول أسطوانة صورة إلى أسطوانة صورة
بالنظر إلى صورة قرص من برنامج Hypervisor آخر تريد تحويله لتشغيله على KVM ، فأنت
خياران. أبسط طريقة هي أن تجرب:

Virt-v2v -i disk disk.img -o local -os / فار / tmp

حيث تخمن Virt-v2v كل شيء عن المدخلات disk.img و (في هذه الحالة) يكتب ال
النتيجة المحولة إلى / فار / tmp.

هناك طريقة أكثر تعقيدًا تتمثل في كتابة بعض libvirt XML الذي يصف ضيف الإدخال (إذا أمكنك ذلك
احصل على برنامج hypervisor المصدر لتزويدك بـ libvirt XML ، ثم كان ذلك أفضل بكثير). أنت
يمكن بعد ذلك القيام بما يلي:

Virt-v2v -i libvirtxml guest-domain.xml -o local -os / فار / tmp

منذ الضيف domain.xml يحتوي على المسار (المسارات) إلى صورة (صور) قرص الضيف التي لا تحتاج إليها
حدد اسم صورة القرص في سطر الأوامر.

لتحويل صورة قرص محلي وتشغيله على الفور في qemu المحلي ، قم بما يلي:

Virt-v2v -i disk disk.img -o qemu -os / فار / tmp - qemu-التمهيد

الدعم MATRIX

برامج Hypervisors (إدخال)
إم وير ESXi
يجب أن تدار بواسطة VMware vCenter ≥ 5.0. المدخلات غير المُدارة والمباشرة من ESXi ليست كذلك
أيد.

تم تصدير OVA من برنامج VMware
لن تعمل OVAs من برامج Hypervisor الأخرى.

RHEL 5 زين
سيتريكس زن
لم يتم اختبار Citrix Xen مؤخرًا.

فرط-V
لم يتم اختباره مؤخرًا. يتطلب منك تصدير القرص أو استخدامه Virt-p2v(1) على Hyper-V.

مباشرة من صور القرص
فقط صور القرص التي تم تصديرها من برامج Hypervisor المدعومة ، وباستخدام تنسيقات الحاوية
بدعم من qemu.

آلات فيزيائية
باستخدام Virt-p2v(1) أداة.

برامج Hypervisors (انتاج)
QEMU و KVM فقط.

الافتراضية إدارة نظم (انتاج)
نظرة سريعة على OpenStack
Red Hat Enterprise Virtualization (RHEV) 2.2 والأحدث
libvirt المحلية
وبالتالي فيرش(1) مدير الفضيلة(1) وأدوات مماثلة.

قرص محلي

عدد الأشخاص
ريد هات إنتربرايز لينوكس 3 ، 4 ، 5 ، 6 ، 7
CentOS 3 و 4 و 5 و 6 و 7
لينكس العلمية 3، 4، 5، 6، 7
أوراكل لينكس
فيدورا
SLES 10 وما فوق
OpenSUSE 10 وما فوق
نظام التشغيل Windows XP إلى Windows 8.1 / Windows Server 2012 R2
نستخدم أرقام إصدارات Windows الداخلية ، راجع
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

حاليًا يتم دعم NT 5.2 إلى NT 6.3.

راجع "WINDOWS" أدناه للحصول على ملاحظات إضافية حول تحويل ضيوف Windows.

ضيف الثابتة
BIOS أو UEFI لجميع أنواع الضيوف (لكن انظر "UEFI" أدناه).

OPTIONS

--مساعدة
عرض المساعدة.

-b
--كوبري
يرى --شبكة الاتصال أدناه.

--مضغوط
اكتب ملف إخراج مضغوط. هذا مسموح به فقط إذا كان تنسيق الإخراج هو qcow2
(انظر -من أدناه) ، وهو ما يعادل -c الخيار qemu- إمغ(1).

--dcpath المجلد / مركز البيانات
NB: لا تحتاج إلى استخدام هذه المعلمة إذا كان لديك libvirt ≥ 1.2.20.

بالنسبة لبرنامج VMware vCenter ، تجاوز المعلمة "dcPath = ..." المستخدمة لتحديد مركز البيانات.
عادةً ما يمكن لـ Virt-v2v حساب ذلك من عنوان URI "vpx: //" ، ولكن إذا حدث خطأ ،
ثم يمكنك تجاوزه باستخدام هذا الإعداد. انتقل إلى واجهة مجلد الويب vCenter الخاص بك ،
على سبيل المثال "https://vcenter.example.com/folder" (بدون شرطة مائلة) ، وفحص
"dcPath =" المعلمة في عناوين URL التي تظهر على هذه الصفحة.

--debug-gc
تصحيح أخطاء جمع البيانات المهملة وتخصيص الذاكرة. هذا مفيد فقط عند التصحيح
مشاكل الذاكرة في Virt-v2v أو ارتباطات OCaml libguestfs.

- تراكبات الشذوذ
احفظ ملف (ملفات) التراكب الذي تم إنشاؤه أثناء التحويل. يستخدم هذا الخيار فقط لـ
تصحيح أخطاء Virt-v2v وقد تتم إزالته في إصدار مستقبلي.

-i أسطوانة
اضبط طريقة الإدخال على أسطوانة.

في هذا الوضع ، يمكنك قراءة صورة قرص جهاز ظاهري بدون بيانات وصفية. الفضيلة v2v
يحاول تخمين أفضل البيانات الوصفية الافتراضية. هذا عادة ما يكون كافيا ولكن يمكنك الحصول عليه
تحكم أدق (مثل الذاكرة ووحدات المعالجة المركزية الافتراضية) باستخدام -i libvirtxml بدلاً من. الضيوف فقط
التي تستخدم قرصًا واحدًا يمكن استيرادها بهذه الطريقة.

-i libvirt
اضبط طريقة الإدخال على libvirt. هذا هو الافتراضي.

في هذا الوضع ، يجب عليك تحديد اسم ضيف libvirt أو UUID في سطر الأوامر.
يمكنك أيضًا تحديد عنوان URI لاتصال libvirt (انظر -ic).

-i libvirtxml
اضبط طريقة الإدخال على libvirtxml.

في هذا الوضع ، يجب عليك تمرير ملف libvirt XML في سطر الأوامر. هذا الملف هو
اقرأ من أجل الحصول على بيانات وصفية حول الضيف المصدر (مثل اسمه ومقدار
الذاكرة) ، وكذلك لتحديد موقع أقراص الإدخال. راجع "MINIMAL XML FOR -i libvirtxml
OPTION "أدناه.

-i محلي
هذا هو نفس -i أسطوانة.

-i البويضات
اضبط طريقة الإدخال على البويضات.

في هذا الوضع يمكنك قراءة ملف ova VMware. سوف يقوم Virt-v2v بقراءة ملف بيان ova
وتحقق من مجلدات vmdk للتأكد من صحتها (المجاميع الاختبارية) وكذلك تحليل ملف ovf ،
ثم قم بتحويل الضيف. راجع "الإدخال من برنامج VMWARE OVA" أدناه

-ic libvirtURI
حدد عنوان URI لاتصال libvirt لاستخدامه عند قراءة الضيف. يستخدم هذا فقط
متى -أنا libvirt.

فقط اتصالات libvirt المحلية أو اتصالات VMware vCenter أو RHEL 5 Xen remote
يمكن استخدام الوصلات. لن تعمل اتصالات libvirt البعيدة الأخرى بشكل عام.

راجع أيضًا "الإدخال من خادم VMWARE VCENTER" ، "الإدخال من RHEL 5 XEN" أدناه.

-لو شكل
في حالة -i أسطوانة فقط ، هذا يحدد تنسيق صورة قرص الإدخال. لمدخلات أخرى
طرق يجب عليك تحديد تنسيق الإدخال في البيانات الوصفية.

--في المكان
لا تقم بإنشاء جهاز إخراج ظاهري في برنامج Hypervisor الهدف. بدلاً من ذلك ، اضبط ملف
ضيف OS في المصدر VM للتشغيل في Hypervisor المدخلات.

هذا الوضع مخصص للتكامل مع مجموعات الأدوات الأخرى التي تتحمل المسؤولية
لتحويل تكوين الجهاز الظاهري ، مما يوفر إمكانية التراجع في حالة حدوث أخطاء ،
تحويل التخزين ، إلخ.

يتعارض مع الجميع -o * خيارات.

- آلة مقروءة
يستخدم هذا الخيار لجعل الإخراج أكثر ملاءمة للآلة عند تحليله بواسطة
برامج أخرى. انظر "إخراج الجهاز القابل للقراءة" أدناه.

-n في خارج
-n خارج
--شبكة الاتصال في خارج
--شبكة الاتصال خارج
-b في خارج
-b خارج
--كوبري في خارج
--كوبري خارج
تعيين شبكة (أو جسر) يسمى "في" إلى شبكة (أو جسر) يسمى "خارج". في حالة عدم وجود "في:"
تم إعطاء البادئة ، يتم تعيين جميع الشبكات (أو الجسور) الأخرى إلى "خارج".

راجع "الشبكات والجسور" أدناه.

--لا توجد نسخة
لا تنسخ الأقراص. بدلاً من ذلك ، يتم إجراء التحويل (ويتم التخلص منه) ، و
تمت كتابة البيانات الوصفية ، ولكن لم يتم إنشاء أي أقراص. انظر أيضا مناقشة -o لاغية أدناه.

هذا مفيد في حالتين: إما أنك تريد اختبار ما إذا كان التحويل محتملًا
تنجح دون الحاجة إلى عملية النسخ الطويلة. أو أنك مهتم فقط بالنظر إلى
البيانات الوصفية.

هذا الخيار غير متوافق مع -o libvirt لأنه سيخلق ضيفًا خاطئًا
(واحد بدون أقراص).

هذا الخيار غير متوافق مع -o لمحة لأسباب فنية.

- لا تقليم الكل
- لا تقليم النائب [، النائب ...]
افتراضيًا يتم تشغيل Virt-v2v FSTR(8) لتقليل كمية البيانات التي يجب أن تكون
نسخ. من المعروف أن هذا يكسر بعض برامج تحميل الإقلاع التي تجرها الدواب مما يتسبب في فشل التمهيد بعد ذلك
التحويل (انظر على سبيل المثال https://bugzilla.redhat.com/show_bug.cgi؟id=1141145#c27).

يمكنك استخدام - لا تقليم الكل لتعطيل كل التشذيب. لاحظ أن هذا سيزيد بشكل كبير
كمية البيانات التي يجب نسخها ويمكن أن تجعل تشغيل Virt-v2v أبطأ بكثير.

يمكنك أيضًا تعطيل الاقتطاع في أنظمة الملفات المحددة فقط (المحددة بفاصلة-
قائمة منفصلة بنقطة (نقاط) التركيب الخاصة بهم في الضيف). عادة سوف تستخدم ملفات
- لا تقليم / التمهيد للتغلب على حشرة اليرقة المذكورة أعلاه.

يمكنك أيضًا تعطيل الاقتطاع على الأقسام باستخدام مخطط تسمية libguestfs لـ
الأجهزة ، على سبيل المثال: - لا تقليم / ديف / sdb2 يعني عدم تقليم القسم الثاني في الثاني
جهاز كتلة. يستخدم نظم ملفات Virt-files(1) لسرد أسماء أنظمة الملفات في ضيف.

-o أسطوانة
هذا هو نفس -o محلي.

-o لمحة
اضبط طريقة الإخراج على OpenStack Glance. في هذا الوضع الضيف المحول هو
تم الرفع إلى لمحة. يمكنك التحكم في اسم الصورة عن طريق تعيين ملف أون الخيار.

-o libvirt
اضبط طريقة الإخراج على libvirt. هذا هو الافتراضي.

في هذا الوضع ، يتم إنشاء الضيف المحول كضيف libvirt. يمكنك أيضا تحديد
وصلة libvirt URI (انظر -أوك).

راجع "الإخراج إلى LIBVIRT" أدناه.

-o محلي
اضبط طريقة الإخراج على محلي.

في هذا الوضع ، تتم كتابة الضيف المحول إلى دليل محلي محدد بواسطة -س
/ دير (يجب أن يكون الدليل موجودًا). تتم كتابة أقراص الضيف المحولة على النحو التالي:

/ دير / name-sda
/ dir / name-sdb
[إلخ]

ويتم إنشاء ملف libvirt XML يحتوي على بيانات تعريف الضيف:

/دير/name.xml

حيث "الاسم" هو اسم الضيف.

-o فارغة
اضبط طريقة الإخراج على فارغة.

يتم تحويل الضيف ونسخه (ما لم تحدد ذلك أيضًا --لا توجد نسخة) ، ولكن النتائج
يتم التخلص منها ولا تتم كتابة أي بيانات وصفية.

-o أوفيريت
هذا هو نفس -o rhev.

-o كيمو
اضبط طريقة الإخراج على كيمو.

هذا هو مماثل ل -o محلي، فيما عدا أنه تمت كتابة برنامج شيل يمكنك استخدامه
لتمهيد الضيف في qemu. تتم كتابة الأقراص المحولة وبرنامج shell النصي إلى ملف
الدليل المحدد بواسطة -س.

عند استخدام وضع الإخراج هذا ، يمكنك أيضًا تحديد ملف - qemu-التمهيد الخيار الذي الأحذية
الضيف تحت qemu على الفور.

-o rhev
اضبط طريقة الإخراج على rhev.

تتم كتابة الضيف المحول إلى مجال تخزين تصدير RHEV. ال -س المعلمة
يجب أيضًا استخدامها لتحديد موقع مجال تخزين التصدير. لاحظ هذا
لا يقوم بالفعل باستيراد الضيف إلى RHEV. عليك القيام بذلك يدويًا لاحقًا
باستخدام واجهة المستخدم.

راجع "الإخراج إلى RHEV" أدناه.

-o com.vdsm
اضبط طريقة الإخراج على com.vdsm.

هذا الوضع مشابه لـ -o rhev، ولكن يجب إعطاء المسار الكامل لمجال البيانات:
/ rhev / مركز البيانات / /. يستخدم هذا الوضع فقط عندما
يعمل Virt-v2v تحت تحكم VDSM.

-وا متناثر
-وا تم تخصيصه مسبقًا
اضبط وضع تخصيص ملف الإخراج. الافتراضي هو "متفرق".

-أوك libvirtURI
حدد اتصال libvirt لاستخدامه عند كتابة الضيف المحول. هذا فقط
تستخدم عندما -o libvirt. راجع "الإخراج إلى LIBVIRT" أدناه.

يمكن استخدام وصلات libvirt المحلية فقط. لن تعمل اتصالات libvirt البعيدة.

-من شكل
عند تحويل الضيف ، قم بتحويل الأقراص إلى التنسيق المحدد.

إذا لم يتم تحديده ، فسيتم استخدام تنسيق الإدخال.

أون الاسم
أعد تسمية الضيف عند تحويله. إذا لم يتم استخدام هذا الخيار ثم اسم الإخراج
هو نفس اسم الإدخال.

-س تخزين
موقع التخزين للضيف المحول.

في حالة -o libvirt، هذا هو تجمع دليل libvirt (انظر "قائمة تجمع virsh") أو UUID التجمع.

في حالة -o محلي -o كيمو، هذا اسم دليل. يجب أن يكون الدليل موجودًا.

في حالة -o rhev، يمكن أن يكون هذا مسار NFS لمجال تخزين التصدير للنموذج
" : "، على سبيل المثال:

rhev-storage.example.com:/rhev/export

يجب أن يكون تصدير NFS قابلاً للتثبيت وقابلاً للكتابة بواسطة المستخدم والمضيف الذي يعمل بنظام Virt-v2v ،
نظرًا لأن برنامج Virt-v2v يجب أن يقوم بتثبيته بالفعل عند تشغيله. لذا ربما أنت
يجب أن تقوم بتشغيل Virt-v2v كـ "جذر".

أو: يمكنك تحميل مجال تخزين التصدير بنفسك ، والإشارة -س إلى ال mountpoint.
لاحظ أن Virt-v2v سيظل بحاجة إلى الكتابة إلى هذا الدليل البعيد ، لذا فإن Virt-v2v سوف يفعل
لا تزال بحاجة إلى تشغيل باسم "الجذر".

ستظهر لك رسالة خطأ إذا تعذر على Virt-v2v التحميل / الكتابة في مساحة تخزين التصدير
نطاق.

--ملف كلمة المرور ملف
بدلاً من طلب كلمة (كلمات) المرور بشكل تفاعلي ، قم بتمرير كلمة المرور عبر ملف.
لاحظ أن الملف يجب أن يحتوي على كلمة المرور بأكملها ، بدون أي وقت زائدة خط جديدولل
الأمان يجب أن يحتوي الملف على الوضع 0600 حتى لا يتمكن الآخرون من قراءته.

- مصدر الطباعة
اطبع معلومات عن ضيف المصدر وتوقف. هذا الخيار مفيد عندما تكون كذلك
إعداد خرائط الشبكات والجسور. انظر "الشبكات والجسور".

- qemu-التمهيد
عند استخدام -o كيمو فقط ، يؤدي هذا إلى تشغيل الضيف فور انتهاء Virt-v2v.

-q
--هادئ
يؤدي هذا إلى تعطيل أشرطة التقدم والمخرجات الأخرى غير الضرورية.

--جذر تطلب
--جذر عزباء
--جذر أول
--جذر / ديف / SDX
--جذر / ديف / VG / LV
اختر نظام ملفات الجذر المراد تحويله.

في الحالة التي يكون فيها الجهاز الظاهري عبارة عن تمهيد مزدوج أو متعدد التمهيد ، أو في حالة وجود جهاز افتراضي
أنظمة الملفات الأخرى التي تشبه أنظمة التشغيل ، يمكن استخدام هذا الخيار لتحديد
نظام ملفات الجذر (المعروف أيضًا باسم محرك الأقراص "C:" أو /) لنظام التشغيل الذي سيتم
محولة. وحدة التحكم بالاسترداد لـ Windows ، وبعض محركات أقراص DVD المرفقة ، والأخطاء الموجودة في ملفات
استدلال libguestfs للتفتيش ، يمكن أن يجعل الضيف يبدو وكأنه تشغيل متعدد التمهيد
نظام.

الافتراضي في Virt-v2v ≤ 0.7.1 هو - جذر واحد، الأمر الذي يتسبب في موت Virt-v2v إذا كان a
تم العثور على نظام تشغيل متعدد التمهيد.

منذ Virt-v2v ≥ 0.7.2 أصبح الإعداد الافتراضي الآن - يسأل الجذر: إذا تبين أن الجهاز الظاهري متعدد
boot ، ثم يتوقف الأمر Virt-v2v ويسرد أنظمة ملفات الجذر الممكنة ويسأل المستخدم
التي يجب استخدامها. هذا يتطلب أن يتم تشغيل Virt-v2v بشكل تفاعلي.

- الجذور أولا يعني اختيار أول جهاز جذر في حالة التمهيد المتعدد
نظام التشغيل. نظرًا لأن هذا هو الكشف عن مجريات الأمور ، فقد يختار أحيانًا الخيار الخطأ.

يمكنك أيضًا تسمية جهاز جذر معين ، على سبيل المثال. - الجذر / ديف / sda2 قد يعني استخدام
القسم الثاني على القرص الصلب الأول. إذا كان جهاز الجذر المسمى غير موجود أو
لم يتم اكتشافه كجهاز جذر ، ثم ستفشل Virt-v2v.

لاحظ أن هناك خطأ في اليرقة يمنعه من تشغيل ملف
نظام متعدد التمهيد إذا تم تمكين VirtIO. Grub قادر فقط على تشغيل نظام التشغيل
من أول قرص VirtIO. خاصة، / التمهيد يجب أن يكون على قرص VirtIO الأول ، و
لا يمكن تحميل نظام تشغيل غير موجود في قرص VirtIO الأول.

--vdsm- صورة- uuid UUID
--vdsm- المجلد- uuid UUID
- vdsm- vm- uuid UUID
--vdsm-ovf الإخراج
عادةً ما يختار وضع إخراج RHEV معرّفات UUID عشوائية للضيف المستهدف. لكن VDSM
يحتاج إلى التحكم في UUIDs ويمرر هذه المعلمات عند تشغيل Virt-v2v تحت VDSM
يتحكم. التحكم في المعلمات:

· دليل الصور لكل قرص ضيف (--vdsm- صورة- uuid) (تم تجاوز هذا الخيار
مرة واحدة لكل قرص ضيف)

· UUIDs لكل قرص ضيف (--vdsm- المجلد- uuid) (يتم تمرير هذا الخيار مرة واحدة لكل منهما
قرص الضيف)

· اسم ملف OVF (- vdsm- vm- uuid).

· دليل الإخراج OVF (الدليل الحالي الافتراضي) (--vdsm-ovf الإخراج).

تنسيق UUIDs هو: "12345678-1234-1234-1234-123456789abc" (يمكن أن يكون كل رقم ست عشري
"0-9" أو "af") ، بما يتوافق مع OSF DCE 1.1.

لا يمكن استخدام هذه الخيارات إلا مع -o com.vdsm.

-v
- الإسراف
تفعيل الرسائل المطولة من أجل التصحيح.

-V
--الإصدار
عرض رقم الإصدار والخروج.

--vmtype سطح المكتب
--vmtype الخادم
بالنسبة -o rhev or -o com.vdsm الأهداف فقط ، حدد نوع الضيف. يمكنك ضبط هذا
إلى "سطح المكتب" أو "الخادم". إذا لم يتم توفير الخيار ، فسيكون الخيار الافتراضي المناسب
تم اختياره بناءً على نظام تشغيل الضيف المكتشف.

-x تفعيل تتبع مكالمات واجهة برمجة تطبيقات libguestfs.

XEN مميز ضيوفنا

يمكن للإصدارات الأقدم من Virt-v2v أن تحول ضيفًا شبه افتراضي (PV) إلى ضيف KVM بواسطة
تثبيت نواة جديدة. هذا الإصدار من Virt-v2v يفعل ليس محاولة تثبيت أي ملف
حبات. بدلا من ذلك سوف يعطيك خطأ إذا كان هناك فقط حبات Xen PV المتاحة.

لذلك قبل التحويل ، يجب عليك التحقق من تثبيت نواة عادية. بالنسبة للبعض
توزيعات Linux القديمة ، وهذا يعني تثبيت نواة من الجدول أدناه:

RHEL 3 (لا ينطبق ، حيث لم يكن هناك نواة Xen PV)

RHEL 4 i686 مع> 10 غيغابايت من ذاكرة الوصول العشوائي: قم بتثبيت "kernel-hugemem"
i686 SMP: تثبيت "kernel-smp"
i686 أخرى: تثبيت 'kernel'
x86-64 SMP مع> 8 وحدات معالجة مركزية: تثبيت "kernel-largesmp"
x86-64 SMP: تثبيت "kernel-smp"
x86-64 أخرى: قم بتثبيت 'kernel'

RHEL 5 i686: تثبيت "kernel-PAE"
x86-64: تثبيت "kernel"

SLES 10 i586 مع> 10 غيغابايت من ذاكرة الوصول العشوائي: تثبيت "kernel-bigsmp"
i586 SMP: تثبيت "kernel-smp"
i586 الآخر: تثبيت "kernel-default"
x86-64 SMP: تثبيت "kernel-smp"
x86-64 أخرى: قم بتثبيت "kernel-default"

SLES 11+ i586: تثبيت "kernel-pae"
x86-64: تثبيت "kernel-default"

Windows (لا ينطبق ، حيث لا يوجد Xen PV Windows kernel)

التمكين فيرتيو

"Virtio" هو اسم مجموعة من برامج التشغيل التي تجعل القرص (جهاز الكتلة) والشبكة و
تعمل عمليات الضيف الأخرى بشكل أسرع على KVM.

يمكن للإصدارات الأقدم من Virt-v2v تثبيت برامج التشغيل هذه لبعض ضيوف Linux. هذا
نسخة من Virt-v2v لا ليس تحاول تثبيت برامج تشغيل أو نواة Linux جديدة ، ولكنها ستفعل
تحذيرك إذا لم يتم تثبيتها بالفعل.

من أجل تمكين الفضيلة ، وبالتالي تحسين أداء الضيف بعد التحويل ،
يجب عليك التأكد من أن الحد الأدنى تم تثبيت إصدارات الحزم قبل التحويل،
من خلال الرجوع إلى الجدول أدناه.

RHEL 3 لا تتوفر برامج تشغيل Virtio

نواة RHEL 4> = 2.5.9-89.EL
lvm2> = 2.02.42-5.el4
جهاز مخطط> = 1.02.28-2.el4
استهداف سياسة selinux> = 1.17.30-2.152.el4
بوليسيكوتيلس> = 1.18.1-4.13

نواة RHEL 5> = 2.6.18-128.el5
lvm2> = 2.02.40-6.el5
استهداف سياسة selinux> = 2.4.6-203.el5

RHEL 6+ تدعم جميع الإصدارات Virtio

جميع إصدارات Fedora تدعم Virtio

SLES 11+ تدعم جميع الإصدارات Virtio

نواة SLES 10> = 2.6.16.60-0.85.1

OpenSUSE 11+ تدعم جميع الإصدارات Virtio

نواة OpenSUSE 10> = 2.6.25.5-1.1

يتم تثبيت برامج تشغيل Windows من الدليل المشار إليه بواسطة
متغير البيئة "VIRTIO_WIN"
(/ usr / share / Virtio-win افتراضيًا) إن وجدت

RHEL 4

SELinux إعادة التسمية يبدو إلى علق إلى الأبد
في RHEL ≤ 4.7 ، كان هناك خطأ يجعل إعادة تسمية SELinux تبدو معلقة إلى الأبد
في:

*** تحذير - يلزم إعادة تسمية SELinux. ***
*** تعطيل فرض الأمن. ***
*** قد تستغرق إعادة التسمية وقتًا طويلاً جدًا ، ***
*** حسب حجم نظام الملفات. ***

في الواقع ، تنتظر الضغط على مفتاح (ولكن لا يوجد مؤشر مرئي لـ
هذا). يمكنك إما الضغط على مفتاح "[Return]" ، وعندها سينتهي الضيف
إعادة التسمية وإعادة التشغيل ، أو يمكنك تثبيت Policycoreutils 1.18.1-4.13 قبل البدء
تحويل v2v. راجع أيضًا https://bugzilla.redhat.com/show_bug.cgi؟id=244636

WINDOWS

حذاء بالفشل: 0x0000007B
سبب فشل التمهيد هذا هو عدم تمكن Windows من العثور على برنامج تشغيل القرص الأيمن أو تحميله
(على سبيل المثال. viistor.sys). إذا واجهت هذا الخطأ ، فإليك بعض الأشياء التي يجب التحقق منها:

· تأكد أولاً من قيام الضيف بالتمهيد على برنامج Hypervisor المصدر قبل التحويل.

تحقق من توفر برامج تشغيل Windows Virtio بتنسيق / البيرة / حصة / Virtio-win، والتي
لم يطبع Virt-v2v أي تحذير حول عدم القدرة على تثبيت برامج تشغيل Virtio.

في Red Hat Enterprise Linux 7 ، ستحتاج إلى تثبيت برامج التشغيل الموقعة المتاحة
في حزمة "Virtio-win". إذا لم يكن لديك حق الوصول إلى برامج التشغيل الموقعة ، إذن
ربما تحتاج إلى تعطيل تسجيل برنامج التشغيل في قوائم التمهيد.

· تأكد من أنك تقدم واجهة Virtio-blk (ليس Virtio-scsi و ليس بيئة تطوير متكاملة) إلى
الضيف. في سطر الأوامر qemu / KVM ، يجب أن ترى شيئًا مشابهًا لهذا:

... ملف محرك الأقراص = windows-sda ، إذا = Virtio ...

في libvirt XML ، يجب أن تشاهد:



· تحقق من أن نهج مجموعة Windows لا يمنع تثبيت برنامج التشغيل أو
مستخدم. حاول حذف Windows Group Policy قبل التحويل.

· تحقق من عدم وجود برنامج مكافحة فيروسات أو برامج أخرى تنفذ نهج المجموعة
حظر تثبيت أو استخدام برامج تشغيل جديدة.

تمكين التصحيح التمهيد والتحقق من viistor.sys يتم تحميل السائق.

كومة مفتوحة ويندوز تنشيط
لا يقدم OpenStack عناوين ثابتة للأجهزة / PCI للضيوف. في كل مرة تخلق
أو يبدأ ضيفًا ، فإنه يعيد إنشاء libvirt XML لذلك الضيف من البداية. ال
لن يكون لدى libvirt XML أي مجالات. سيقوم Libvirt بعد ذلك بتعيين عناوين للأجهزة ،
بطريقة يمكن التنبؤ بها. قد تتغير العناوين إذا تحقق أي مما يلي:

تمت إضافة قرص أو جهاز شبكة جديد أو إزالته من الضيف.

إصدار OpenStack أو (ربما) libvirt قد تغير.

نظرًا لأن Windows لا يحب تغييرات "الأجهزة" من هذا النوع ، فقد يؤدي ذلك إلى تشغيل Windows
إعادة التنشيط.

يمكن أن يؤدي هذا أيضًا إلى منع التشغيل بخطأ 7B [انظر القسم السابق] إذا كان الضيف لديه
سياسة المجموعة التي تحتوي على "قيود تثبيت الجهاز".

UEFI

يسمح لك برنامج VMware بتقديم برامج UEFI الثابتة للضيوف (بدلاً من BIOS لجهاز الكمبيوتر العادي).
يمكن لـ Virt-v2v تحويل هؤلاء الضيوف ، لكنه يتطلب دعم UEFI بواسطة الهدف
المشرف.

يدعم KVM حاليًا OVMF ، وهو برنامج ثابت مفتوح المصدر جزئيًا لـ UEFI ، ويمكنه تشغيل هذه البرامج
الضيوف.

نظرًا لأنه تمت إضافة دعم OVMF مؤخرًا إلى KVM (في 2014/2015) ، لم يكن الهدف كله
البيئات تدعم ضيوف UEFI حتى الآن:

UEFI على libvirt ، qemu
أيد. سوف يقوم Virt-v2v بإنشاء ملف libvirt XML الصحيح (البيانات الوصفية) تلقائيًا ،
لكن لاحظ أنه يجب تثبيت الإصدار نفسه من OVMF على مضيف التحويل كما هو
مثبتًا على برنامج Hypervisor الهدف ، وإلا فسيتعين عليك ضبط المسارات في ملف
البيانات الوصفية.

UEFI على OpenStack
غير مدعوم.

UEFI على RHEV
غير مدعوم.

NETWORKS لأي لبس الجسور

عادة ما يكون الضيوف متصلين بشبكة واحدة أو أكثر ، وعند التحويل إلى الهدف
برنامج Hypervisor الذي تريد عادةً إعادة توصيل هذه الشبكات في الوجهة. الخيارات
--شبكة الاتصال --كوبري تسمح لك بفعل ذلك.

إذا لم تكن متأكدًا من الشبكات والجسور المستخدمة في برنامج Hypervisor المصدر ، إذن
يمكنك فحص البيانات الوصفية المصدر (libvirt XML ، معلومات vCenter ، إلخ). أو يمكنك ذلك
قم بتشغيل Virt-v2v مع - مصدر الطباعة الخيار الذي يتسبب في طباعة Virt-v2v لملف
المعلومات التي يحتويها عن الضيف على المصدر ثم الخروج.

في مجلة - مصدر الطباعة الناتج سترى قسمًا يعرض واجهة شبكة الضيف
البطاقات (بطاقات NIC):

$ Virt-v2v [-i ...] - اسم مصدر الطباعة
[...]
بطاقات NIC:
الشبكة "الافتراضي" mac: 52: 54: 00: d0: cf: 0e

هذا نموذجي لضيف libvirt: يحتوي على واجهة شبكة واحدة متصلة بملف
شبكة تسمى "الافتراضي".

لتعيين شبكة معينة إلى شبكة مستهدفة ، على سبيل المثال "افتراضي" على المصدر
"rhevm" على الهدف ، استخدم:

Virt-v2v [...] - الشبكة الافتراضية: rhevm

لتعيين كل شبكة إلى شبكة مستهدفة ، استخدم:

Virt-v2v [...] - تردد الشبكة

يتم التعامل مع الجسور بنفس الطريقة ، ولكن عليك استخدام --كوبري الخيار بدلا من ذلك. ل
مثال:

$ Virt-v2v [-i ...] - اسم مصدر الطباعة
[...]
بطاقات NIC:
جسر "br0"

$ Virt-v2v [...] --bridge br0: targetbr

INPUT من عند VMWARE مركز VCENTER الخادم

يمكن لـ Virt-v2v استيراد الضيوف من خادم VMware vCenter.

مطلوب vCenter ≥ 5.0. إذا لم يكن لديك vCenter ، فمن المستحسن استخدام OVA بدلاً من ذلك
(راجع "الإدخال من برنامج VMWARE OVA" أدناه) ، أو إذا لم يكن ذلك ممكنًا ، فراجع "الإدخال من
برنامج VMWARE ESXi HYPERVISOR ".

يستخدم Virt-v2v libvirt للوصول إلى vCenter ، وبالتالي يجب أن يكون وضع الإدخال -i
libvirt. نظرًا لأن هذا هو الإعداد الافتراضي ، فلن تحتاج إلى تحديده في سطر الأوامر.

مركز فينسيتر: إزالة VMWARE آدوات من عند WINDOWS ضيوفنا
لضيوف Windows ، يجب عليك إزالة أدوات VMware قبل التحويل. على الرغم من أن هذا
ليس ضروريًا تمامًا ، وسيظل الضيف قادرًا على الجري ، إذا لم تقم بذلك بعد ذلك
سيشتكي الضيف المحول عند كل صندوق. لا يمكن إزالة الأدوات بعد
التحويل لأن برنامج إلغاء التثبيت يتحقق مما إذا كان يعمل على برنامج VMware ويرفض البدء
(وهو أيضًا سبب عدم قدرة Virt-v2v على إزالتها).

هذا ليس ضروريًا لضيوف Linux ، حيث يمكن لـ Virt-v2v إزالة أدوات VMware.

مركز فينسيتر: URI
يبدو عنوان libvirt URI لخادم vCenter مثل هذا:

vpx: // user @ server / Datacenter / esxi

حيث:

"مستخدم@"
هو المستخدم (اختياري ، لكن موصى به) للاتصال بصفته.

إذا كان اسم المستخدم يحتوي على شرطة مائلة للخلف (مثل "المجال \ USER") ، فستحتاج إلى URI-
إلغاء هذا الحرف باستخدام٪ 5c: "DOMAIN٪ 5cUSER" (5c هو رمز ASCII الست عشري لـ
شرطة مائلة للخلف.) قد يلزم أيضًا تخطي علامات الترقيم الأخرى.

"الخادم"
هو خادم vCenter (ليس برنامج Hypervisor).

"مركز البيانات"
هو اسم مركز البيانات.

إذا كان الاسم يحتوي على مسافة ، فاستبدله برمز URI-escape٪ 20.

"esxi"
هو اسم برنامج مراقبة ESXi الذي يقوم بتشغيل الضيف.

إذا كان نشر VMware يستخدم مجلدات ، فقد تحتاج إلى إضافتها إلى URI ، على سبيل المثال:

vpx: // user @ server / Folder / Datacenter / esxi

للحصول على تفاصيل كاملة حول libvirt URIs ، راجع: http://libvirt.org/drvesx.html

تتضمن الأخطاء النموذجية من libvirt / virsh عندما يكون URI خاطئًا:

· تعذر العثور على مركز البيانات المحدد في [...]

· تعذر العثور على مورد الحساب المحدد في [...]

· المسار [...] لا يحدد مورد حساب

· المسار [...] لا يحدد نظام مضيف

· تعذر العثور على النظام المضيف المحدد في [...]

مركز فينسيتر: الاختبار ليبيرت CONNECTION إلى مركز VCENTER
استخدم فيرش(1) أمر لسرد الضيوف على خادم vCenter مثل هذا:

$ virsh -c 'vpx: //[البريد الإلكتروني محمي]/ قائمة مركز البيانات / esxi - الكل
أدخل كلمة مرور الجذر لـ vcenter.example.com: ***

حالة اسم المعرف
-------------------------------------------------- -
- إغلاق فيدورا 20
- تم إيقاف تشغيل Windows 2003

إذا تلقيت خطأ "لا يمكن مصادقة شهادة النظير بشهادات CA المقدمة"
أو ما شابه ، يمكنك إما استيراد شهادة مضيف vCenter ، أو تجاوز التوقيع
التحقق من خلال إضافة علامة "؟ no_verify = 1":

$ virsh -c 'vpx: //[البريد الإلكتروني محمي]/ Datacenter / esxi؟ no_verify = 1 'قائمة - الكل

يجب أيضًا محاولة تفريغ البيانات الوصفية من أي ضيف على الخادم الخاص بك ، مثل هذا:

$ virsh -c 'vpx: //[البريد الإلكتروني محمي]/ Datacenter / esxi 'dumpxml "Windows 2003"

نظام التشغيل Windows 2003
[...]


If هيه فوق الأوامر do ليس عمل، then الفضيلة v2v is ليس الذهاب إلى العمل إما. إصلاح الخاص بك
تكوين libvirt و / أو خادم VMware vCenter الخاص بك قبل المتابعة.

مركز فينسيتر: استيراد A الذهبي
لاستيراد ضيف معين من خادم vCenter ، قم بما يلي:

$ Virt-v2v -ic 'vpx: //[البريد الإلكتروني محمي]/ Datacenter / esxi؟ no_verify = 1 '\
"Windows 2003" \
-o محلي -os / فار / tmp

حيث "Windows 2003" هو اسم الضيف (الذي يجب إغلاقه).

لاحظ أنه قد يُطلب منك كلمة مرور vCenter مرتين. يحدث هذا مرة واحدة لأن
يحتاج libvirt إليه ، ومرة ​​ثانية لأن Virt-v2v نفسها تتصل مباشرة بملف
الخادم. يستخدم --ملف كلمة المرور لتوفير كلمة مرور عبر ملف.

في هذه الحالة ، يتم تعيين إشارات الإخراج لكتابة الضيف المحول إلى مؤقت
الدليل لأن هذا مجرد مثال ، ولكن يمكنك أيضًا الكتابة إلى libvirt أو أي ملف آخر
الهدف المدعوم.

مركز فينسيتر: غير المشرف دور
بدلاً من استخدام دور vCenter Administrator ، يمكنك إنشاء غير مسؤول مخصص
دور لأداء التحويل. ومع ذلك ، سوف تحتاج إلى إعطائها حدًا أدنى من
الأذونات على النحو التالي:

1. إنشاء دور مخصص في vCenter.

2. قم بتمكين (تحقق) الكائنات التالية:

مخزن البيانات:
- تصفح مخزن البيانات
- عمليات ملف منخفضة المستوى

جلسة:
- التحقق من الدورة

آلة افتراضية:
التزويد:
- السماح بالوصول إلى القرص
- السماح بالوصول إلى القرص للقراءة فقط
- إدارة نظام تشغيل الضيف بواسطة VIX API

INPUT من عند VMWARE OVA

يمكن لـ Virt-v2v استيراد الضيوف من ملفات OVA (Open Virtualization Appliance) الخاصة بـ VMware.
ستعمل فقط OVAs المصدرة من VMware vSphere.

البويضات: إزالة VMWARE آدوات من عند WINDOWS ضيوفنا
لضيوف Windows ، يجب عليك إزالة أدوات VMware قبل التحويل. على الرغم من أن هذا
ليس ضروريًا تمامًا ، وسيظل الضيف قادرًا على الجري ، إذا لم تقم بذلك بعد ذلك
سيشتكي الضيف المحول عند كل صندوق. لا يمكن إزالة الأدوات بعد
التحويل لأن برنامج إلغاء التثبيت يتحقق مما إذا كان يعمل على برنامج VMware ويرفض البدء
(وهو أيضًا سبب عدم قدرة Virt-v2v على إزالتها).

هذا ليس ضروريًا لضيوف Linux ، حيث يمكن لـ Virt-v2v إزالة أدوات VMware.

البويضات: خلق OVA
لإنشاء OVA في vSphere ، استخدم خيار "تصدير قالب OVF" (من سياق VM
القائمة ، أو من قائمة "ملف"). إما "مجلد الملفات" (OVF) أو "ملف واحد" (OVA)
العمل ، ولكن ربما يكون التعامل مع OVA أسهل. ملفات OVA هي في الحقيقة نوع tar غير مضغوط
حتى تتمكن من استخدام أوامر مثل "tar tf VM.ova" لعرض محتوياتها.

إنشاء OVA مع أوفتول

يمكنك أيضًا استخدام "ovftool" الخاص بـ VMware:

oofftool - noSSL تحقق \
vi: // المستخدم:[البريد الإلكتروني محمي]/ VM \
VM.ova

للاتصال بـ vCenter:

oofftool - noSSL تحقق \
vi: // المستخدم:[البريد الإلكتروني محمي]/ DATACENTER-NAME / vm / VM \
VM.ova

للمصادقة المدركة لـ Active Directory ، يجب عليك التعبير عن الحرف "@" في ملف
شكل الكود السداسي الأسكي الخاص به (٪ 5c):

vi: // المجال٪ 5cUSER: كلمة المرور @ ...

البويضات: استيراد A الذهبي
لاستيراد ملف OVA يسمى VM.ova، يفعل؛

$ Virt-v2v -i ova VM.ova -o local -os / فار / tmp

إذا قمت بتصدير الضيف كـ "مجلد ملفات" ، or إذا قمت بإخراج تار OVA
بنفسك ، إذًا يمكنك الإشارة إلى Virt-v2v في الدليل الذي يحتوي على الملفات:

$ Virt-v2v -i ova / المسار / إلى / الملفات -o local -os / فار / tmp

INPUT من عند VMWARE ESXi المشرف

لا يمكن لـ Virt-v2v الوصول إلى برنامج مراقبة ESXi مباشرةً. يجب عليك استخدام طريقة OVA أعلاه
(راجع "الإدخال من برنامج VMWARE OVA") إن أمكن ، لأنه أسرع بكثير ويتطلب أقل بكثير
مساحة القرص من الطريقة الموضحة في هذا القسم.

يمكنك استخدام Virt-v2v- نسخ إلى محلي(1) أداة لنسخ الضيف من برنامج Hypervisor إلى ملف
ملف محلي ، ثم قم بتحويله.

إسكسي: إزالة VMWARE آدوات من عند WINDOWS ضيوفنا
لضيوف Windows ، يجب عليك إزالة أدوات VMware قبل التحويل. على الرغم من أن هذا
ليس ضروريًا تمامًا ، وسيظل الضيف قادرًا على الجري ، إذا لم تقم بذلك بعد ذلك
سيشتكي الضيف المحول عند كل صندوق. لا يمكن إزالة الأدوات بعد
التحويل لأن برنامج إلغاء التثبيت يتحقق مما إذا كان يعمل على برنامج VMware ويرفض البدء
(وهو أيضًا سبب عدم قدرة Virt-v2v على إزالتها).

هذا ليس ضروريًا لضيوف Linux ، حيث يمكن لـ Virt-v2v إزالة أدوات VMware.

إسكسي: URI
سيبدو libvirt URI لـ VMware ESXi Hypervisors كما يلي:

esx: //[البريد الإلكتروني محمي]؟ no_verify = 1

تعمل المعلمة "؟ no_verify = 1" على تعطيل فحص شهادة TLS.

إسكسي: الاختبار ليبيرت CONNECTION إلى ESXi المشرف
استخدم فيرش(1) أمر لاختبار URI وسرد الضيوف البعيدين المتاحين:

$ virsh -c esx: //[البريد الإلكتروني محمي]؟ no_verify = قائمة واحدة - الكل
أدخل كلمة مرور الجذر لـ esxi.example.com: ***
حالة اسم المعرف
-------------------------------------------------- -
- اغلاق الضيف

إسكسي: COPY ال الذهبي إلى ال LOCAL آلة
استخدام libvirt URI باعتباره ملف -ic الخيار ، نسخ أحد الضيوف إلى الجهاز المحلي:

$ Virt-v2v-copy-to-local -ic esx: //[البريد الإلكتروني محمي]؟ no_verify = ضيف ​​واحد

هذا يصنع Guest.xml, ضيف القرص 1...

إسكسي: DO ال فيرت-V2V تحويلات
قم بإجراء تحويل الضيف باستخدام Virt-v2v:

$ Virt-v2v -i libvirtxml guest.xml -o local -os / فار / tmp

إسكسي: كلين UP
إزالة Guest.xml قرص الضيف * الملفات.

INPUT من عند RHEL 5 XEN

يمكن لـ Virt-v2v استيراد ضيوف Xen من مضيفي RHEL 5 Xen.

يستخدم Virt-v2v libvirt للوصول إلى مضيف Xen البعيد ، وبالتالي وضع الإدخال
ينبغي أن تكون -i libvirt. نظرًا لأن هذا هو الإعداد الافتراضي ، فلن تحتاج إلى تحديده في الأمر
الخط.

زين: طقم UP وكيل SSH ACCESS إلى XEN HOST
يجب عليك حاليًا تمكين وصول SSH بدون كلمة مرور إلى مضيف Xen البعيد من Virt-v2v
خادم التحويل.

يجب عليك أيضًا استخدام ssh-agent ، وإضافة مفتاح ssh العام إلى /root/.ssh/authorized_keys (على
مضيف Xen).

بعد القيام بذلك ، يجب عليك التحقق من أن الوصول بدون كلمة مرور يعمل من خادم Virt-v2v
لمضيف Xen. على سبيل المثال:

$ ssh [البريد الإلكتروني محمي]
[يسجل الدخول مباشرة إلى القشرة ، ولا يُطلب كلمة مرور]

لاحظ أن الوصول إلى كلمة المرور التفاعلية ووصول Kerberos هما ليس أيد. أنت لديك لإعداد
الوصول إلى ssh باستخدام ssh-agent و author_keys.

زين: الاختبار ليبيرت CONNECTION إلى REMOTE XEN HOST
استخدم فيرش(1) أمر لسرد الضيوف على مضيف Xen البعيد:

$ virsh -c xen + ssh: //[البريد الإلكتروني محمي] قائمة جميع
حالة اسم المعرف
-------------------------------------------------- -
0 المجال - 0 قيد التشغيل
- إيقاف تشغيل rhel49-x86_64-pv

يجب أيضًا محاولة تفريغ البيانات الوصفية من أي ضيف على الخادم الخاص بك ، مثل هذا:

$ virsh -c xen + ssh: //[البريد الإلكتروني محمي] dumpxml rhel49-x86_64-pv

rhel49-x86_64-الكهروضوئية
[...]


If هيه فوق الأوامر do ليس عمل، then الفضيلة v2v is ليس الذهاب إلى العمل إما. إصلاح الخاص بك
تكوين libvirt أو الخادم البعيد قبل المتابعة.

If هيه ضيف أقراص . تقع on a مضيف منع جهاز، ثم ستفشل عملية التحويل. يرى
"تحويلات XEN أو SSH من BLOCK DEVICES" أدناه لحل بديل.

زين: استيراد A الذهبي
لاستيراد ضيف معين من خادم Xen ، قم بما يلي:

$ Virt-v2v -ic 'xen + ssh: //[البريد الإلكتروني محمي]'\
rhel49-x86_64-pv \
-o محلي -os / فار / tmp

حيث "rhel49-x86_64-pv" هو اسم الضيف (الذي يجب إغلاقه).

في هذه الحالة ، يتم تعيين إشارات الإخراج لكتابة الضيف المحول إلى مؤقت
الدليل لأن هذا مجرد مثال ، ولكن يمكنك أيضًا الكتابة إلى libvirt أو أي ملف آخر
الهدف المدعوم.

XEN OR SSH التحويلات من عند BLOCK الأجهزة
حاليًا لا يمكن لـ Virt-v2v الوصول مباشرة إلى ضيف Xen (أو أي ضيف موجود في مكان بعيد
ssh) إذا كانت أقراص هذا الضيف موجودة على أجهزة كتلة المضيف.

لمعرفة ما إذا كان ضيف Xen يستخدم أجهزة حظر المضيف ، انظر إلى XML الضيف. سوف ترى:





حيث "type = 'block'" و "source dev =" و "/ dev / ..." كلها مؤشرات على أن القرص
موجود على جهاز كتلة مضيف.

يحدث هذا لأن برنامج تشغيل qemu ssh block الذي نستخدمه للوصول إلى الأقراص البعيدة يستخدم ملف
ssh sftp ، ولا يمكن لهذا البروتوكول اكتشاف حجم كتلة المضيف بشكل صحيح
الأجهزة.

الحل هو نسخ الضيف إلى خادم التحويل ، باستخدام ملف
Virt-v2v- نسخ إلى محلي(1) أداة ، متبوعة بتشغيل Virt-v2v. سوف تحتاج إلى ما يكفي
مساحة على خادم التحويل لتخزين نسخة كاملة من الضيف.

Virt-v2v-copy-to-local -ic xen + ssh: //[البريد الإلكتروني محمي] ضيف
Virt-v2v -i libvirtxml guest.xml -o local -os / فار / tmp
rm guest.xml guest-disk *

OUTPUT إلى ليبيرت

إنّ -o libvirt يتيح لك الخيار تحميل الضيف المحول إلى مضيف يديره libvirt.
هناك عدة قيود:

يمكنك فقط استخدام اتصال libvirt محلي [انظر أدناه للتعرف على كيفية حل هذا].

· ال -س تجمع الخيار يجب أن يحدد تجمع دليل ، وليس أي شيء أكثر غرابة مثل
بروتوكول iSCSI [لكن انظر أدناه].

يمكنك تحميل برنامج Hypervisor الخاص بـ KVM فقط.

إلى الناتج إلى a عن بعد libvirt مثل و / أو a غير دليل تخزين تجمع عليك أن تستخدم
الحل التالي:

1. استخدم Virt-v2v في -o محلي الوضع لتحويل أقراص الضيف والبيانات الوصفية إلى ملف محلي
دليل مؤقت:

Virt-v2v [...] -o محلي -وس / فار / tmp

يؤدي ذلك إلى إنشاء ملفين (أو أكثر) بتنسيق / فار / tmp اتصل:

/var/tmp/NAME.xml # libvirt XML (البيانات الوصفية)
/ var / tmp / NAME-sda # القرص الأول للضيف

(بالنسبة لـ "NAME" ، استبدل اسم الضيف).

2. قم بتحميل القرص (الأقراص) المحول في مجمع التخزين المسمى "POOL":

الحجم = $ (stat -c٪ s / var / tmp / NAME-sda)
virsh vol-create-as POOL NAME-sda $ size --format raw
virsh vol-upload --pool POOL NAME-sda / var / tmp / NAME-sda

3. تصحيح /var/tmp/NAME.xml لتغيير / var / tmp / NAME-sda لاسم التجمع. بعبارة أخرى،
حدد موقع الجزء التالي من XML:







وتغيير شيئين: يجب تغيير السمة "type = 'file'" إلى "type = 'volume'" ،
و ال " يجب تغيير "عنصر" ليشمل سمات "التجمع" و "الحجم":







4. حدد الضيف الأخير في libvirt:

حدد virsh /var/tmp/NAME.xml

OUTPUT إلى rhev

ينطبق هذا القسم فقط على -o rhev وضع الإخراج. إذا كنت تستخدم Virt-v2v من RHEV-M
واجهة المستخدم ، ثم تتم إدارة الاستيراد خلف الكواليس بواسطة VDSM باستخدام ملف -o com.vdsm
وضع الإخراج (الذي يجب على المستخدمين النهائيين عدم محاولة استخدامه مباشرة).

عليك أن تحدد -o rhev و -س الخيار الذي يشير إلى تخزين تصدير RHEV-M
اِختِصاص. يمكنك إما تحديد خادم NFS و mountpoint ، على سبيل المثال.
"-os rhev-storage: / rhev / export" ، أو يمكنك تحميل ذلك أولاً والإشارة إلى الدليل
حيث يتم تركيبه ، على سبيل المثال. "-os / tmp / mnt". احرص على عدم الإشارة إلى تخزين البيانات
المجال عن طريق الصدفة لأن ذلك لن يعمل.

عند الانتهاء بنجاح ، سيكون موقع Virt-v2v قد كتب الضيف الجديد إلى مخزن التصدير
المجال ، لكنه لن يكون جاهزًا للتشغيل بعد. يجب استيراده إلى RHEV باستخدام واجهة المستخدم
قبل استخدامها.

في RHEV ≥ 2.2 يتم ذلك من علامة التبويب التخزين. حدد مجال التصدير الذي كان الضيف عليه
مكتوب ل. سيظهر جزء أسفل قائمة مجال التخزين يعرض العديد منها
علامات التبويب ، أحدها "استيراد VM". سيتم إدراج الضيف المحول هنا. حدد ملف
الضيف المناسب انقر فوق "استيراد". راجع وثائق RHEV للحصول على تفاصيل إضافية.

إذا قمت بتصدير عدة ضيوف ، فيمكنك استيرادهم جميعًا في نفس الوقت من خلال ملف
UI.

الموارد المتطلبات

شبكة
يبدو أن أهم مورد لـ Virt-v2v هو النطاق الترددي للشبكة. يجب أن يكون Virt-v2v
تكون قادرًا على نسخ بيانات الضيف بسرعات جيجابت إيثرنت أو أعلى.

تأكد من أن اتصالات الشبكة بين الخوادم (خادم التحويل ، خادم NFS ،
vCenter، Xen) أسرع وأقل زمن انتقال ممكن.

أسطوانة الفضاء
يضع Virt-v2v ملفات مؤقتة كبيرة محتملة في $ TMPDIR (وهو / فار / tmp إذا كنت
لا تضعه). استخدام tmpfs فكرة سيئة.

لكل قرص ضيف ، يتم تخزين تراكب مؤقتًا. هذا يخزن التغييرات التي تم إجراؤها
أثناء التحويل ، ويستخدم كذاكرة تخزين مؤقت. التراكبات ليست كبيرة بشكل خاص - عشرات
أو أقل من مئات ميغا بايت لكل قرص نموذجي. بالإضافة إلى التراكب (التراكب) ، المدخلات
وطرق الإخراج قد تستخدم مساحة القرص ، كما هو موضح في الجدول أدناه.

-i البويضات
يؤدي هذا مؤقتًا إلى وضع نسخة كاملة من أقراص المصدر غير المضغوطة في $ TMPDIR.

-o لمحة
يؤدي هذا مؤقتًا إلى وضع نسخة كاملة من أقراص الإخراج في $ TMPDIR.

-o محلي
-o كيمو
يجب عليك التأكد من وجود مساحة كافية في دليل الإخراج لملف
زائر.

-o فارغة
يؤدي هذا مؤقتًا إلى وضع نسخة كاملة من أقراص الإخراج في $ TMPDIR.

في إم وير vCenter موارد
النسخ من VMware vCenter حاليًا بطيء جدًا ، لكننا نعتقد أن هذه مشكلة
مع برنامج VMware. التأكد من تشغيل برنامج VMware ESXi hypervisor و vCenter على أجهزة سريعة
مع الكثير من الذاكرة يجب أن يخفف من هذا.

إحصاء قوة رامات
Virt-v2v لا يستخدم بشكل خاص في الحوسبة أو ذاكرة الوصول العشوائي المكثفة. إذا كنت تقوم بتشغيل العديد من الموازي
التحويلات ، فقد تفكر في تخصيص نواة وحدة معالجة مركزية واحدة وما بين 512 ميجابايت و 1 جيجابايت من
ذاكرة الوصول العشوائي لكل مثيل قيد التشغيل.

يمكن تشغيل Virt-v2v في جهاز افتراضي.

ما بعد التحويل المهام

ضيف شبكة ترتيب
لا يمكن لـ Virt-v2v حاليًا إعادة تكوين تكوين شبكة الضيف. إذا تم تحويل
الضيف غير متصل بنفس الشبكة الفرعية مثل المصدر ، قد يكون تكوين الشبكة الخاص به
يجب تحديثها. أنظر أيضا Virt-تخصيص(1).

التحول a ويندوز ضيف
عند تحويل ضيوف Windows ، يتم تقسيم عملية التحويل إلى مرحلتين:

1. تحويل دون اتصال.

2. التمهيد الأول.

سيكون الضيف قابلاً للتمهيد بعد مرحلة التحويل في وضع عدم الاتصال ، ولكن لن يكون لديه كل شيء بعد
تم تثبيت برامج التشغيل اللازمة للعمل بشكل صحيح. سيتم تثبيت هذه الملفات تلقائيًا
أول مرة يقوم الضيف بالتمهيد.

ملحوظة: احرص على عدم مقاطعة عملية التثبيت التلقائي لبرنامج التشغيل عند تسجيل الدخول
للضيف للمرة الأولى ، لأن هذا قد يمنع الضيف من التمهيد لاحقًا
بشكل صحيح.

مجاني SPACE لأي تحويلات

يتحقق Virt-v2v من وجود مساحة خالية كافية في نظام ملفات الضيف لتنفيذ ملف
تحويل. يتحقق حاليًا من:

نظام ملفات جذر Linux أو محرك أقراص Windows "C:"
أقل مساحة خالية: 20 ميجا بايت

لينكس / التمهيد
أقل مساحة خالية: 50 ميجا بايت

هذا لأننا نحتاج إلى بناء initramfs جديدة لبعض Enterprise Linux
التحويلات.

أي نظام ملفات آخر قابل للتركيب
أقل مساحة خالية: 10 ميجا بايت

الركض و المشي فيرت-V2V AS ROOT OR غير الجذر

لا شيء في Virt-v2v يحتاج بطبيعته إلى الوصول إلى الجذر ، وسوف يعمل بشكل جيد كجذر غير جذر
مستخدم. ومع ذلك ، قد تتطلب بعض الميزات الخارجية إما جذرًا أو مستخدمًا خاصًا:

تركيب مجال تخزين التصدير
عند استخدام -o rhev -س الخادم: / esd يجب أن يكون لـ Virt-v2v امتيازات كافية لـ NFS
تحميل مجال تخزين التصدير من "الخادم".

يمكنك تجنب الحاجة إلى الجذر هنا بتثبيته بنفسك قبل تشغيل Virt-v2v و
مرور -س / mountpoint بدلاً من ذلك ، ولكن أولاً وقبل كل شيء اقرأ القسم التالي ...

الكتابة إلى مجال تخزين التصدير بالشكل 36:36
لا يمكن لـ RHEV-M قراءة الملفات والدلائل من مجال تخزين التصدير إلا إذا كانت
لديك UID: GID 36:36. سترى مشاكل استيراد الجهاز الظاهري إذا كان UID: GID غير صحيح.

عند تشغيل Virt-v2v -o rhev كجذر ، يحاول Virt-v2v إنشاء ملفات وملفات
الدلائل ذات الملكية الصحيحة. إذا قمت بتشغيل Virt-v2v على أنها ليست جذر ، فستفعل ذلك
ربما لا تزال تعمل ، لكنك ستحتاج إلى تغيير الملكية يدويًا بعد أن يعمل Virt-v2v
تم الانتهاء من.

الكتابة إلى libvirt
عند استخدام -o libvirt، قد تحتاج إلى تشغيل Virt-v2v كجذر حتى يتمكن من الكتابة إليه
مثيل نظام libvirt (أي "qemu: /// system") والموقع الافتراضي لـ
صور القرص (عادة / var / lib / libvirt / images).

يمكنك تجنب ذلك عن طريق إعداد مصادقة اتصال libvirt ، راجع
http://libvirt.org/auth.html. بدلا من ذلك ، استخدم -أوك qemu: /// جلسة، والتي سوف
الكتابة إلى مثيل libvirt الخاص بك لكل مستخدم.

الكتابة إلى لمحة
هذا لا ليس تحتاج إلى الجذر (في الواقع ربما لن تعمل) ، ولكنها قد تتطلب إما
مستخدم خاص و / أو لك لمصدر نص برمجي يحدد بيئة المصادقة
المتغيرات. راجع وثائق النظرة.

تفكيك RHEV-M استيراد الإخفاقات

عندما تقوم بالتصدير إلى مجال تخزين تصدير RHEV-M ، ثم تقوم باستيراد ذلك الضيف من خلال
واجهة مستخدم RHEV-M ، فقد تواجه فشل استيراد. تشخيص هذه الإخفاقات
صعب للغاية لأن واجهة المستخدم تخفي بشكل عام السبب الحقيقي للفشل.

هناك نوعان من ملفات السجل ذات الأهمية. يتم تخزين الأول على خادم RHEV-M نفسه ، و
يسمى /var/log/ovirt-engine/engine.log

الملف الثاني ، وهو الأكثر فائدة ، موجود في مضيف SPM (يرمز SPM
"مدير تجمع التخزين"). هذه عقدة RHEV منتخبة للقيام بجميع البيانات الوصفية
التعديلات في مركز البيانات ، مثل إنشاء الصور أو اللقطة. يمكنك معرفة
أي مضيف هو SPM الحالي من علامة التبويب "المضيفين" عمود "حالة Spm". حالما تمتلك
حدد موقع SPM ، وقم بتسجيل الدخول إليه واحصل على الملف /var/log/vdsm/vdsm.log التي سوف تحتوي
رسائل خطأ مفصلة من أوامر منخفضة المستوى.

MINIMAL XML لأي -i libvirtxml OPTION

عند استخدام -i libvirtxml الخيار ، عليك توفير بعض libvirt XML. كتابة هذا
من البداية صعب ، لذا فإن النموذج أدناه مفيد.

ملاحظات ينبغي فقط be مستعمل لـ تجريب و / أو أين لصحتك! علم ماذا أنت على تفعل! إذا كنت
لديك بيانات تعريف libvirt للضيف ، استخدمها دائمًا بدلاً من ذلك.


اسم
1048576
2

هفم














<mac address='52:54:00:01:02:03'/>

آلة مقروء OUTPUT

إنّ - آلة مقروءة يمكن استخدام الخيار لجعل الإخراج أكثر ملاءمة للآلة ، والتي
يكون مفيدًا عند استدعاء Virt-v2v من برامج أخرى أو واجهات رسومية وما إلى ذلك.

هناك طريقتان لاستخدام هذا الخيار.

أولاً ، استخدم الخيار بمفرده للاستعلام عن إمكانيات النظام الثنائي Virt-v2v.
يبدو الإخراج النموذجي كما يلي:

$ Virt-v2v - يمكن قراءته بالآلة
الفضيلة v2v
libguestfs- إعادة كتابة
الإدخال: القرص
[...]
الإخراج: محلي
[...]
تحويل: مؤسسة لينكس
تحويل: windows

تتم طباعة قائمة بالميزات ، واحدة لكل سطر ، وينتهي البرنامج بالحالة 0.

تشير ميزات "الإدخال:" و "الإخراج:" -i -o (وضع الإدخال والإخراج)
بدعم من هذا الثنائي. تشير ميزات "التحويل:" إلى أنواع الضيف التي يستخدمها هذا الثنائي
يعرف كيفية التحويل.

ثانيًا ، استخدم الخيار جنبًا إلى جنب مع الخيارات الأخرى لعمل البرنامج العادي
إخراج آلة أكثر ودية.

هذا يعني في الوقت الحالي:

1. يمكن تحليل رسائل شريط التقدم من stdout بالبحث عن هذا العادي
التعبير:

^ [0-9] + / [0-9] + $

2. يجب أن يتعامل البرنامج المتصل مع الرسائل المرسلة إلى stdout (باستثناء شريط التقدم
رسائل) كرسائل حالة. يمكن تسجيلها و / أو عرضها للمستخدم.

3. يجب أن يتعامل البرنامج المتصل مع الرسائل المرسلة إلى stderr على أنها رسائل خطأ. في
بالإضافة إلى ذلك ، فإن Virt-v2v تخرج برمز حالة غير صفري إذا كان هناك خطأ فادح.

لم يدعم Virt-v2v ≤ 0.9.1 - آلة مقروءة الخيار على الإطلاق. كان الخيار
تمت إضافته عند إعادة كتابة Virt-v2v في عام 2014.

استخدم Virt-v2v عبر الإنترنت باستخدام خدمات onworks.net