Virtualization – ວິທີກວດສອບ ແລະ ແກ້ໄຂບັນຫາ

Markmc, Crobinso, Voxadam Version unspecified Last review: 2018-05-20 Needs a review!
ກຳລັງດຳເນີນການ!

ໜ້ານີ້ຖືກຄັດລອກມາຈາກເອກະສານ Fedora Wiki ສະບັບກ່ອນ.

ມັນໄດ້ຖືກປັບປຸງເພື່ອເຜີຍແຜ່ຢູ່ທີ່ນີ້ໃນ Fedora Docs Portal, ແຕ່ຍັງບໍ່ທັນໄດ້ຮັບການກວດສອບຄວາມຖືກຕ້ອງທາງດ້ານເຕັກນິກເທື່ອ.

ຢ່າຟ້າວນຳໃຊ້ໃນເວລານີ້. ມັນອາດຈະ

  • ມີບັນຫາເລື່ອງຮູບແບບ

  • ຫຼ້າສະໄໝ

  • ຕ້ອງການການປັບປຸງເພີ່ມເຕີມ

ການກວດສອບຄວາມຖືກຕ້ອງທາງດ້ານເຕັກນິກແມ່ນເປັນສິ່ງທີ່ດີຫຼາຍ. ຖ້າທ່ານຕ້ອງການຊ່ວຍ, ໃຫ້ເບິ່ງທີ່ ໄຟລ໌ README ໃນຄັງເກັບຂໍ້ມູນຕົ້ນສະບັບສຳລັບຄຳແນະນຳ.

ຍອມຮັບການດຶງຂໍ້ມູນການປ່ຽນແປງ (Pull requests) ທີ່ https://forge.fedoraproject.org/docs/quick-docs

ເມື່ອທ່ານແກ້ໄຂໜ້ານີ້ແລ້ວ, ໃຫ້ລຶບແຈ້ງການນີ້ອອກ.

ການລາຍງານບັກທີ່ມີປະສິດທິພາບ

ການລາຍງານບັກຢ່າງມີປະສິດທິພາບແມ່ນທັກສະທີ່ສຳຄັນສຳລັບຜູ້ໃຊ້ ຫຼື ຜູ້ພັດທະນາ Fedora ທຸກຄົນ.

ການຈຳກັດສາເຫດທີ່ອາດເປັນໄປໄດ້ຂອງບັກ ແລະ ການໃຫ້ຂໍ້ມູນທີ່ຖືກຕ້ອງໃນລາຍງານບັກ ຈະຊ່ວຍໃຫ້ບັກຖືກແກ້ໄຂໄດ້ໄວຂຶ້ນ. ການສົ່ງລາຍງານບັກທີ່ມີຂໍ້ມູນໜ້ອຍ ອາດເຮັດໃຫ້ບັກຂອງທ່ານບໍ່ໄດ້ຮັບການແກ້ໄຂ ຈົນກວ່າເວີຊັນຂອງລະບົບຈະໝົດອາຍຸການໃຊ້ງານ (end of life).

ເບິ່ງ ວິທີສົ່ງລາຍງານບັກ ສຳລັບຂໍ້ມູນທົ່ວໄປກ່ຽວກັບການສົ່ງບັກ. ໜ້ານີ້ມີຂໍ້ມູນສະເພາະສຳລັບບັກທີ່ກ່ຽວກັບ virtualization.

ຂໍ້ມູນເວີຊັນ

ເມື່ອທ່ານໝັ້ນໃຈແລ້ວວ່າໄດ້ຕິດຕັ້ງການອັບເດດຫຼ້າສຸດແລ້ວ , ໃຫ້ຮວບຮວມລາຍລະອຽດຂອງເລກເວີຊັນຂອງແພັກເກັດເຫຼົ່ານັ້ນ ເຊັ່ນ:

$ rpm -q qemu-kvm qemu-common python-virtinst virt-viewer virt-manager

ເພື່ອເບິ່ງວ່າທ່ານກຳລັງໃຊ້ເວີຊັນເຄີເນິນ (kernel) ໃດ ແລະ ໃຊ້ສະຖາປັດຕະຍະກຳເຄື່ອງແບບໃດ:

$ uname -a

ແນ່ນອນ, ທ່ານຄວນກວດສອບໃຫ້ແນ່ໃຈວ່າໄດ້ສົ່ງບັກໂດຍໃຊ້ເວີຊັນ Fedora ທີ່ເໝາະສົມ. ຜູ້ໃຊ້ Rawhide ຄວນສົ່ງບັກໂດຍໃຊ້ເວີຊັນ "rawhide".

ຂໍ້ມູນຮາດແວ

ຄວາມສາມາດດ້ານ virtualization ຂອງ Fedora ແມ່ນຂຶ້ນກັບຄວາມສາມາດຂອງຮາດແວຢ່າງຫຼວງຫຼາຍ, ສະນັ້ນ ເວລາສົ່ງບັກ ກະລຸນາໃສ່ຂໍ້ມູນໃຫ້ຄົບຖ້ວນກ່ຽວກັບຮາດແວຂອງທ່ານ ລວມທັງ:

$ cat /proc/cpuinfo
$ lspci -vvv
$ virt-host-validate

ທ່ານຍັງສາມາດກວດສອບໄດ້ວ່າເຄື່ອງຂອງທ່ານມີຄວາມສາມາດ virtualization ໃດແດ່ ໂດຍການລັນຄຳສັ່ງ:

$ virsh capabilities

ການຕັ້ງຄ່າເກສ (Guest)

ເມື່ອສົ່ງບັກທີ່ກ່ຽວຂ້ອງກັບບັນຫາທີ່ພົບໃນເກສ (guest), ໃຫ້ໃສ່ລາຍລະອຽດທັງໝົດຂອງການຕັ້ງຄ່າເກສ ລວມທັງສະຖາປັດຕະຍະກຳ CPU, ຂະໜາດ RAM, ອຸປະກອນ ແລະ ອື່ນໆ. ວິທີທີ່ງ່າຍທີ່ສຸດຄືການໃສ່ຜົນຈາກຄຳສັ່ງ virsh dumpxml MyGuest ຫຼື ໃນກໍລະນີຂອງ qemu ແມ່ນໃຫ້ໃສ່ຄຳສັ່ງ qemu ແແບບເຕັມ.

Virt Manager

Virt Manager ເກັບໄຟລ໌ບັນທຶກ (logfile) ໄວ້ໃນ ~/.cache/virt-manager/virt-manager.log.

ກວດເບິ່ງໄຟລ໌ບັນທຶກ ແລະ ໃສ່ຂໍ້ມູນສ່ວນທີ່ເບິ່ງຄືວ່າຈະເປັນປະໂຫຍດໃນລາຍງານບັກ. ຖ້າບໍ່ໝັ້ນໃຈ, ໃຫ້ແນບໄຟລ໌ທັງໝົດໄປກັບບັກ.

ທ່ານຍັງສາມາດລັນ virt-manager ຈາກຄຳສັ່ງ (command line) ໂດຍໃຊ້ virt-manager --no-fork ແລະ ກວດເບິ່ງວ່າມີຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງສະແດງອອກມາຫຼືບໍ່.

virt-install

virt-install ເກັບໄຟລ໌ບັນທຶກໄວ້ໃນ ~/.cache/virtinst/virt-install.log.

ລັນ virt-install ໂດຍໃຊ້ຕົວເລືອກ --debug ເພື່ອຮັບຂໍ້ມູນການແກ້ໄຂບັນຫາ (debug) ທີ່ລະອຽດ.

ເພື່ອໃຫ້ສາມາດເຂົ້າເຖິງຄອນໂຊນຊີຣຽວໃນລະຫວ່າງການຕິດຕັ້ງ, ທ່ານສາມາດໃຊ້ -x "console=ttyS0". ການໃຊ້ຄອນໂຊນຊີຣຽວຮ່ວມກັບການຕິດຕັ້ງຜ່ານ VNC ແມ່ນມີປະໂຫຍດຫຼາຍສຳລັບການກວດສອບຂໍ້ຜິດພາດ ເຊັ່ນ: --nographics -x "console=ttyS0 vnc"

libvirt

ທຸກໂປຣແກຣມທີ່ໃຊ້ libvirt ສາມາດກວດສອບ (debug) ໄດ້ໂດຍໃຊ້ຕົວປ່ຽນສະພາບແວດລ້ອມ LIBVIRT_DEBUG=1 ເຊັ່ນ:

$ LIBVIRT_DEBUG=1 virt-manager --no-fork
$ LIBVIRT_DEBUG=1 virsh list --all

ຖ້າບັນຫາຂອງທ່ານເບິ່ງຄືວ່າກ່ຽວຂ້ອງກັບ libvirtd, ໃຫ້ລອງເບິ່ງໃນ /var/log/messages ເພື່ອຫາຂໍ້ຄວາມຜິດພາດຕ່າງໆ.

ທ່ານຍັງສາມາດໃຊ້ ການຕັ້ງຄ່າບັນທຶກໃນ /etc/libvirt/libvirtd.conf ເພື່ອບັນທຶກຂໍ້ມູນ debug ລົງໃນໄຟລ໌:

log_level = 1
log_outputs = 0:file:/tmp/libvirtd.log

ຫຼື ທ່ານອາດຈະລອງລັນ libvirtd ຈາກຄຳສັ່ງ ໂດຍເປີດໃຊ້ຕົວເລືອກການແກ້ໄຂບັນຫາ (debugging):

$ sudo systemctl stop libvirtd
$ sudo LIBVIRT_DEBUG=1 libvirtd --verbose

libguestfs

ຖ້າ libguestfs, guestfish, virt-df ແລະ ອື່ນໆ ມີບັນຫາ, ໃຫ້ລັນຄຳສັ່ງ:

$ sudo libguestfs-test-tool

ຖ້າທຸກຢ່າງເຮັດວຽກປົກກະຕິ, ຢູ່ໃກ້ໆທ້າຍຂອງຂໍ້ມູນທີ່ສະແດງອອກມາ ທ່ານຈະເຫັນຂໍ້ຄວາມ

===== TEST FINISHED OK =====.

ຖ້າຫາກມັນບໍ່ເຮັດວຽກ, ໃຫ້ສົ່ງຂໍ້ມູນທີ່ສະແດງອອກມາຈາກຄຳສັ່ງນັ້ນ ແບບສົມບູນ ແລະ ບໍ່ໄດ້ຜ່ານການແກ້ໄຂ ລົງໃນລາຍງານບັກ.

ລະບົບເຄືອຂ່າຍ

ຖ້າທ່ານມີບັນຫາກັບເກສ (guests) ທີ່ເຊື່ອມຕໍ່ກັບ ເຄືອຂ່າຍສະເໝືອນ ຂອງ libvirt, ອິນເຕີເຟດກາຍະພາບທີ່ໃຊ້ຮ່ວມກັນ (shared physical interface) ຫຼື ບຣິດ (bridge), ໃຫ້ລອງໃຊ້ຄຳສັ່ງເຫຼົ່ານີ້:

$ sudo virsh net-list --all
$ sudo brctl show
$ sudo sysctl net.bridge.bridge-nf-call-iptables
$ sudo iptables -L -v -n
$ sudo ps -ef | grep dnsmasq
$ sudo ifconfig -a
$ sudo cat /proc/sys/net/ipv4/ip_forward
$ sudo service libvirtd reload

ຖ້າທ່ານພົບວ່າ /proc/sys/net/ipv4/ip_forward ບໍ່ໄດ້ຖືກຕັ້ງເປັນ 1 ໃນເວລາບູດເຄື່ອງ, ໃຫ້ລອງເບິ່ງລຳດັບການເຮັດວຽກຂອງບໍລິການ libvirtd ແລະ NetworkManager:

$ sudo find /etc/rc.d -regex '.*rc[35].d/S.*\(libvirtd\|NetworkManager\)'
$ sudo rm -f /etc/chkconfig.d/libvirtd /etc/chkconfig.d/NetworkManager
$ sudo chkconfig libvirtd resetpriorities
$ sudo chkconfig NetworkManager resetpriorities
$ sudo find /etc/rc.d -regex '.*rc[35].d/S.*\(libvirtd\|NetworkManager\)'

kvm

ເບິ່ງເພີ່ມເຕີມທີ່ [http://www.linux-kvm.org/page/Bugs ໜ້າ KVM wiki ກ່ຽວກັບການລາຍງານບັກ].

ຜົນຂອງທຸກຄຳສັ່ງ <code>qemu-kvm</code> ທີ່ລັນໂດຍ <code>libvirtd</code> ແມ່ນຖືກເກັບໄວ້ໃນ <code>/var/log/libvirt/qemu/GuestName.log</code>.

[[Testing_KVM_with_kvm_autotest|kvm-autotest]] ແມ່ນວິທີທີ່ດີທີ່ສຸດໃນການທົດສອບການເຮັດວຽກພື້ນຖານຂອງ KVM.

Xen

ຂໍ້ມູນທີ່ມີປະໂຫຍດບາງຢ່າງກ່ຽວກັບວິທີແກ້ໄຂບັນຫາ Xen ສາມາດເບິ່ງໄດ້ໃນໜ້າ Wiki [http://wiki.xen.org/wiki/Debugging_Xen Debugging Xen]. ຖ້າທ່ານຄິດວ່າທ່ານພົບພາບບັກແທ້ໆ, ທ່ານອາດຈະປະຕິບັດຕາມຂັ້ນຕອນທີ່ລະບຸໄວ້ໃນໜ້າ Wiki [http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen Reporting Bugs against Xen], ຫຼື ໃນໂພສບລັອກ [http://blog.xen.org/index.php/2013/06/04/reporting-a-bug-against-the-xen-hypervisor/ ນີ້].

ບັກທີ່ໄດ້ຮັບການລາຍງານ ແລະ ກຳລັງຖືກຕິດຕາມໂດຍຜູ້ພັດທະນາ Xen ແມ່ນໄດ້ຖືກຮວບຮວມໄວ້ໃນ [http://bugs.xenproject.org/xen/ Xen Hypervisor Bug Tracker], ດັ່ງນັ້ນທ່ານອາດຈະລອງເຂົ້າໄປເບິ່ງບ່ອນນັ້ນ ເພື່ອເບິ່ງວ່າບັກທີ່ທ່ານພົບນັ້ນໄດ້ຮັບການແກ້ໄຂແລ້ວຫຼືບໍ່.

ຂໍ້ມູນທີ່ມີປະໂຫຍດເພີ່ມເຕີມ:

  • ໄຟລ໌ບັນທຶກ (log files) ມີໃຫ້ເບິ່ງຢູ່ທີ່ <code>/var/log/xen/</code>, ສຳລັບທັງເກສແບບ HVM ແລະ PV (ໃຫ້ຊອກຫາຊື່ເກສ ແລະ Domain ID ຂອງທ່ານ)

  • ຖ້າເກສຂອງທ່ານຄ້າງ (crashing), ພວກເຮົາແນະນຳໃຫ້ທ່ານເຮັດດັ່ງນີ້:

    • ຕັ້ງຄ່າ "on_crash=preserve" ໃນໄຟລ໌ການຕັ້ງຄ່າໂດເມນຂອງທ່ານ

    • ຄັດລອກ System.map ຂອງເຄີເນິນເກສ ໄປໄວ້ທີ່ໂຮສ (host)

    • ເມື່ອເກສຄ້າງແລ້ວ, ໃຫ້ລັນຄຳສັ່ງ <code>/usr/lib/xen/bin/xenctx -s System.map <domid></code>

ຄຳແນະນຳທົ່ວໄປ

ໄຟລ໌ບັນທຶກເຫດການຂອງລະບົບ

ໃຫ້ກວດເບິ່ງໃນ <code>dmesg</code>, <code>/var/log/messages</code> ແລະ ອື່ນໆ ສະເໝີເພື່ອຫາຂໍ້ມູນທີ່ເປັນປະໂຫຍດ.

strace

<code>strace</code> ມັກຈະຊ່ວຍໃຫ້ເຫັນສາເຫດຂອງບັກ - ເຊັ່ນ: ຖ້າທ່ານລັນ <code>virt-manager</code>, ຫຼື <code>libvirtd</code> ຫຼື <code>qemu-kvm</code> ພາຍໃຕ້ strace ທ່ານຈະສາມາດເຫັນໄດ້ວ່າພວກມັນເຂົ້າເຖິງໄຟລ໌ໃດ, ໃຊ້ຄຳສັ່ງໃດ, ຫຼື ຮ້ອງໃຊ້ລະບົບ (system calls) ໃດແດ່:

<pre> $> strace -ttt -f libvirtd </pre>

ຖ້າໂປຣແກຣມດັ່ງກ່າວກຳລັງເຮັດວຽກຢູ່ແລ້ວ, ທ່ານສາມາດເຊື່ອມຕໍ່ກັບມັນໄດ້ໂດຍໃຊ້ <code>strace -p</code>.

gdb

<code>gdb</code> ມັກຈະມີປະໂຫຍດໃນການຕິດຕາມການເຮັດວຽກຂອງໂປຣແກຣມ. ເຖິງຢ່າງໃດກໍຕາມ, ເພື່ອໃຫ້ໄດ້ຂໍ້ມູນທີ່ນຳໃຊ້ໄດ້, ທ່ານຈະຕ້ອງຕິດຕັ້ງແພັກເກັດ "debuginfo". ເບິ່ງຂໍ້ມູນເພີ່ມເຕີມໃນໜ້າ .

ເອສອີລີນຸກສ໌

ຖ້າທ່ານເຫັນຂໍ້ຄວາມ "AVC denied" ຫຼື "setroubleshoot" ໃນ <code>/var/log/messages</code>, ບັກຂອງທ່ານອາດຈະເກີດຈາກບັນຫານະໂຍບາຍຂອງ SELinux. ໃຫ້ລອງປ່ຽນ SELinux ໃຫ້ເປັນໂໝດ "permissive" ຊົ່ວຄາວດ້ວຍຄຳສັ່ງ:

<pre> $> setenforce 0 </pre>

ຖ້າສິ່ງນີ້ເຮັດໃຫ້ບັກຂອງທ່ານຫາຍໄປ ມັນບໍ່ໄດ້ໝາຍຄວາມວ່າບັກນັ້ນຖືກແກ້ໄຂແລ້ວ, ແຕ່ມັນຊ່ວຍຈຳກັດສາເຫດໃຫ້ແຄບລົງ! ທ່ານຄວນໃສ່ລາຍລະອຽດ AVC ຈາກ <code>ausearch -m AVC -ts recent</code> ລົງໃນລາຍງານບັກ, ຫຼື ຖ້າຂໍ້ຄວາມມີຄຳສັ່ງ <code>sealert -l</code> ໃຫ້ໃສ່ລາຍລະອຽດທີ່ສະແດງອອກມາຈາກຄຳສັ່ງນັ້ນນຳ.

ສາເຫດທົ່ວໄປໜຶ່ງຂອງບັນຫາ SELinux ແມ່ນການຕິດປ້າຍກຳກັບໄຟລ໌ (label) ທີ່ຜິດພາດ. ໃຫ້ລອງ:

<pre> $> restorecon /path/to/file/in/selinux/message </pre>

ຖ້າທ່ານກຳລັງຕິດຕັ້ງໂດຍໃຊ້ ISO ໃນການເມາທ໌ (mount) ແບບ NFS, ທ່ານຕ້ອງໝັ້ນໃຈວ່າມັນຖືກເມາທ໌ໂດຍໃຊ້ປ້າຍກຳກັບ <code>virt_content_t</code>:

<pre> $> mount -o context="system_u:object_r:virt_content_t:s0" …​ </pre>

ຖ້າທ່ານກຳລັງໃຊ້ libvirt storage pools, ເຊັ່ນ nfs, ຫຼື USB pass-through, ທ່ານອາດຈະຕ້ອງກວດສອບ ຫຼື ເປີດໃຊ້ຄ່າບູລີນ (booleans) ຂອງ SELinux ຢ່າງໃດຢ່າງໜຶ່ງຕໍ່ໄປນີ້: virt_use_comm, virt_use_fusefs, virt_use_nfs, virt_use_samba, virt_use_usb.

<pre> $> getsebool virt_use_nfs virt_use_nfs -→ off $> setsebool -P virt_use_nfs on </pre>

ການແກ້ໄຂບັນຫາ

ບັນຫາເລື່ອງສິດການເຂົ້າເຖິງ

ກ່ອນ Fedora 11/libvirt 0.6.1, ເຄື່ອງສະເໝືອນ (VMs) ທັງໝົດທີ່ລັນຜ່ານ libvirt ຈະຖືກລັນໃນນາມ root, ເຊິ່ງໃຫ້ສິດຜູ້ດູແລລະບົບຢ່າງເຕັມທີ່. ເຖິງວ່າມັນຈະຊ່ວຍໃຫ້ການຈັດການ VM ງ່າຍຂຶ້ນ, ແຕ່ມັນບໍ່ຄ່ອຍປອດໄພ: VM ທີ່ຖືກບຸກລຸກອາດຈະໄດ້ຮັບສິດຜູ້ດູແລລະບົບໃນເຄື່ອງໂຮສ (host).

ໃນ Fedora 11/libvirt-0.6.1, ຄວາມປອດໄພເລີ່ມໄດ້ຮັບການປັບປຸງດ້ວຍການເພີ່ມ [[Features/SVirt_Mandatory_Access_Control|svirt]]. ສະຫຼຸບສັ້ນໆຄື libvirt ຈະພະຍາຍາມຕິດປ້າຍກຳກັບ selinux ໃຫ້ກັບທຸກໆໄຟລ໌ທີ່ VM ຕ້ອງການໃຊ້ໂດຍອັດຕະໂນມັດ ເຊັ່ນ ໄຟລ໌ດິສອິເມຈ (disk images). ຖ້າ VM ພະຍາຍາມເປີດໄຟລ໌ທີ່ libvirt ບໍ່ໄດ້ຕິດປ້າຍກຳກັບໃຫ້, ສິດການເຂົ້າເຖິງຈະຖືກປະຕິເສດ.

Fedora 12 ມີການປັບປຸງຫຼາຍຂຶ້ນກວ່າເກົ່າ. ໃນ libvirt-0.6.5, VMs ຈະຖືກລັນດ້ວຍການຫຼຸດຄວາມສາມາດຂອງໂປຣເຊສ (process capabilities). ສິ່ງນີ້ຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ VM ເຮັດບາງຢ່າງ ເຊັ່ນ: ການປ່ຽນແປງການຕັ້ງຄ່າເຄືອຂ່າຍຂອງໂຮສ (ເຊິ່ງໂດຍປົກກະຕິແລ້ວມັນບໍ່ຈຳເປັນຕ້ອງເຮັດ). ແລະ ໃນ libvirt-0.7.0, ໂປຣເຊສຈຳລອງ VM ຈະບໍ່ຖືກລັນໃນນາມ 'root' ໂດຍຄ່າເລີ່ມຕົ້ນອີກຕໍ່ໄປ, ແຕ່ຈະຖືກລັນໃນນາມຜູ້ໃຊ້ 'qemu' ທີ່ບໍ່ມີສິດພິເສດແທນ.

ເຖິງວ່າການປ່ຽນແປງທັງໝົດນີ້ຈະດີຕໍ່ຄວາມປອດໄພ, ແຕ່ພວກມັນກໍເຮັດໃຫ້ການຕັ້ງຄ່າທີ່ເຄີຍໃຊ້ງານໄດ້ມາກ່ອນມີບັນຫາ ເນື່ອງຈາກເຄີຍອາໄສສິດ VM ທີ່ຜ່ອນຜັນ. ບັນຫາສ່ວນໃຫຍ່ມີວິທີແກ້ໄຂແຕ່ຕ້ອງແ