ນີ້ແມ່ນຄໍາສັ່ງ guestfs-internals ທີ່ສາມາດດໍາເນີນການໄດ້ໃນ OnWorks ຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງຟຣີໂດຍໃຊ້ຫນຶ່ງໃນຫຼາຍໆບ່ອນເຮັດວຽກອອນໄລນ໌ຂອງພວກເຮົາເຊັ່ນ Ubuntu Online, Fedora Online, Windows online emulator ຫຼື MAC OS online emulator
ໂຄງການ:
NAME
guestfs-internals - ສະຖາປັດຕະຍະກໍາແລະພາຍໃນຂອງ libguestfs
ລາຍລະອຽດ
ຫນ້າຄູ່ມືນີ້ແມ່ນສໍາລັບແຮກເກີທີ່ຕ້ອງການເຂົ້າໃຈວ່າ libguestfs ເຮັດວຽກພາຍໃນແນວໃດ.
ນີ້ແມ່ນພຽງແຕ່ຄໍາອະທິບາຍກ່ຽວກັບວິທີ libguestfs ເຮັດວຽກໃນປັດຈຸບັນ, ແລະມັນອາດຈະປ່ຽນແປງໄດ້ທຸກເວລາໃນ
ອະນາຄົດ.
ARCHITECTURE
ພາຍໃນ, libguestfs ຖືກປະຕິບັດໂດຍການແລ່ນເຄື່ອງໃຊ້ (ປະເພດພິເສດຂະຫນາດນ້ອຍ
virtual machine) ໂດຍໃຊ້ whoa(1). Qemu ດໍາເນີນການເປັນຂະບວນການເດັກນ້ອຍຂອງໂຄງການຕົ້ນຕໍ.
┌────────────────────┐
│ ໂປຣແກມຫຼັກ │
││
│ │ ຂະບວນການເດັກ / ເຄື່ອງໃຊ້
│ │ ┌───────────────────────────┐
│ │ │ qemu │
.
│ libguestfs ◀╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍ ▶ guestfsd │ │
│ │ │ ├─────────────────┤ │
└────────────────────┘ │ │ Linux kernel │ │
│ └──────────┬───────┘ │
└─────────────────│───────────┘
│
│ virtio-scsi
┌──────┴──────┐
│ ອຸປະກອນ ຫຼື │
│ຮູບແຜ່ນ │
└──────────────┘
ຫ້ອງສະຫມຸດ, ເຊື່ອມຕໍ່ກັບໂຄງການຕົ້ນຕໍ, ສ້າງຂະບວນການເດັກນ້ອຍແລະເພາະສະນັ້ນເຄື່ອງໃຊ້
ໃນຟັງຊັນ "guestfs_launch".
ພາຍໃນເຄື່ອງໃຊ້ແມ່ນ Linux kernel ແລະອຸປະກອນທີ່ສົມບູນຂອງ userspace (ເຊັ່ນ:
ໂຄງການ LVM ແລະ ext2) ແລະ daemon ຄວບຄຸມຂະຫນາດນ້ອຍທີ່ເອີ້ນວ່າ "guestfsd". ຫໍສະໝຸດ
ສົນທະນາກັບ "guestfsd" ໂດຍໃຊ້ຂັ້ນຕອນການໂທທາງໄກ (RPC). ສ່ວນຫຼາຍແມ່ນຫນຶ່ງຕໍ່ຫນຶ່ງ
ການຕອບຮັບລະຫວ່າງ libguestfs API calls ແລະ RPC calls to the daemon. ສຸດທ້າຍແຜ່ນ
ຮູບພາບແມ່ນຕິດກັບຂະບວນການ qemu ທີ່ແປການເຂົ້າເຖິງອຸປະກອນໂດຍ
kernel Linux ຂອງເຄື່ອງໃຊ້ເຂົ້າໃນການເຂົ້າເຖິງຮູບພາບ.
ຄວາມເຂົ້າໃຈຜິດທົ່ວໄປແມ່ນວ່າເຄື່ອງໃຊ້ "ແມ່ນ" ເຄື່ອງ virtual. ເຖິງແມ່ນວ່າ
ຮູບດິສກ໌ທີ່ທ່ານຕິດຢູ່ນັ້ນອາດຈະຖືກໃຊ້ໂດຍເຄື່ອງ virtual ບາງອັນ, libguestfs
ບໍ່ຮູ້ ຫຼືສົນໃຈເລື່ອງນີ້. (ແຕ່ທ່ານຈະສົນໃຈວ່າຂະບວນການ qemu ຂອງ libguestfs ແລະ
ເຄື່ອງ virtual ຂອງທ່ານກໍາລັງພະຍາຍາມປັບປຸງຮູບພາບແຜ່ນໃນເວລາດຽວກັນ, ນັບຕັ້ງແຕ່ເຫຼົ່ານີ້
ປົກກະຕິແລ້ວເຮັດໃຫ້ການສໍ້ລາດບັງຫຼວງຂອງແຜ່ນຂະຫນາດໃຫຍ່).
STATE ເຄື່ອງຈັກ
libguestfs ໃຊ້ເຄື່ອງຂອງລັດເພື່ອສ້າງແບບຈໍາລອງຂະບວນການເດັກ:
|
guestfs_create / guestfs_create_flags
|
|
____V_____
/ \
| CONFIG |
\__________/
^ ^ \
| \ \ guestfs_ເປີດຕົວ
| _\__V______
| / \
| | ເປີດຕົວ |
| \___________/
| /
| guestfs_launch
| /
__|____ວ
/ \
| ພ້ອມ |
\________/
ການຫັນປ່ຽນປົກກະຕິແມ່ນ (1) CONFIG (ເມື່ອຕົວຈັບໄດ້ຖືກສ້າງຂື້ນ, ແຕ່ບໍ່ມີລູກ
ຂະບວນການ), (2) ການເປີດ (ໃນເວລາທີ່ຂະບວນການຂອງເດັກແມ່ນໄດ້ເລີ່ມຕົ້ນ), (3) ກຽມພ້ອມຫມາຍຄວາມວ່າ.
ເຄື່ອງໃຊ້ແມ່ນຂຶ້ນ, ການປະຕິບັດສາມາດອອກໄປຫາ, ແລະດໍາເນີນການໂດຍຂະບວນການເດັກ.
ແຂກອາດຈະຖືກຂ້າໂດຍ "guestfs_kill_subprocess", ຫຼືອາດຈະຕາຍແບບບໍ່ຊິ້ງຢູ່ບ່ອນໃດນຶ່ງ.
ທີ່ໃຊ້ເວລາ (ເຊັ່ນ: ເນື່ອງຈາກຄວາມຜິດພາດພາຍໃນບາງ) ແລະທີ່ເຮັດໃຫ້ລັດທີ່ຈະຫັນກັບຄືນໄປບ່ອນ
ຕັ້ງຄ່າ.
ຄໍາສັ່ງການຕັ້ງຄ່າສໍາລັບ qemu ເຊັ່ນ "guestfs_set_path" ສາມາດອອກໄດ້ພຽງແຕ່ໃນເວລາທີ່ຢູ່ໃນ
ຕັ້ງຄ່າສະຖານະ.
API ສະຫນອງການໂທຫນຶ່ງທີ່ໄປຈາກ CONFIG ໂດຍຜ່ານການເປີດຕົວໄປຫາ READY.
"guestfs_launch" ຕັນຈົນກ່ວາຂະບວນການເດັກນ້ອຍແມ່ນພ້ອມທີ່ຈະຍອມຮັບຄໍາສັ່ງ (ຫຼືຈົນກ່ວາບາງ.
ຄວາມລົ້ມເຫຼວຫຼືຫມົດເວລາ). "guestfs_launch" ພາຍໃນຍ້າຍສະຖານະຈາກ CONFIG ໄປຫາ LAUNCHING
ໃນຂະນະທີ່ມັນແລ່ນ.
ຄຳສັ່ງ API ເຊັ່ນ "guestfs_mount" ສາມາດອອກໄດ້ເມື່ອຢູ່ໃນສະຖານະ READY ເທົ່ານັ້ນ. API ເຫຼົ່ານີ້
calls block ລໍຖ້າຄໍາສັ່ງທີ່ຈະດໍາເນີນການ. ບໍ່ມີການຂັດຂວາງ
ສະບັບ, ແລະບໍ່ມີວິທີທີ່ຈະອອກຫຼາຍກ່ວາຫນຶ່ງຄໍາສັ່ງຕໍ່ handle ໃນເວລາດຽວກັນ.
ສຸດທ້າຍ, ຂະບວນການເດັກສົ່ງຂໍ້ຄວາມ asynchronous ກັບຄືນໄປບ່ອນໂຄງການຕົ້ນຕໍ, ເຊັ່ນ:
ຂໍ້ຄວາມບັນທຶກ kernel. ທ່ານສາມາດລົງທະບຽນການໂທກັບເພື່ອຮັບຂໍ້ຄວາມເຫຼົ່ານີ້.
ພາຍໃນ
ປະຕິບັດ BOOT PROCESS
ຂະບວນການນີ້ໄດ້ພັດທະນາແລະສືບຕໍ່ພັດທະນາ. ຄໍາອະທິບາຍຢູ່ທີ່ນີ້ແມ່ນກົງກັນເທົ່ານັ້ນ
ສະບັບປະຈຸບັນຂອງ libguestfs ແລະຖືກສະຫນອງໃຫ້ສໍາລັບຂໍ້ມູນເທົ່ານັ້ນ.
ເພື່ອປະຕິບັດຕາມຂັ້ນຕອນທີ່ກ່ຽວຂ້ອງຂ້າງລຸ່ມນີ້, ເປີດໃຊ້ການດີບັກ libguestfs (ຕັ້ງຄ່າ
ຕົວແປສະພາບແວດລ້ອມ "LIBGUESTFS_DEBUG=1").
ສ້າງເຄື່ອງໃຊ້
"supermin --build" ຖືກເອີ້ນໃຫ້ສ້າງແກ່ນ, ເປັນ initrd ຂະຫນາດນ້ອຍແລະເຄື່ອງໃຊ້.
ອຸປະກອນຖືກເກັບໄວ້ໃນ /var/tmp/.guestfs- (ຫຼືຢູ່ໃນໄດເລກະທໍລີອື່ນຖ້າ
"LIBGUESTFS_CACHEDIR" ຫຼື "TMPDIR" ຖືກຕັ້ງ).
ສໍາລັບລາຍລະອຽດຄົບຖ້ວນສົມບູນຂອງວິທີການສ້າງເຄື່ອງໃຊ້ແລະຖານຄວາມຈໍາ, ອ່ານທີ່
ຊຸບເປີມິນ(1) ຫນ້າຜູ້ຊາຍ.
ເລີ່ມ qemu ແລະ boot kernel ໄດ້
qemu ໄດ້ຖືກເອີ້ນໃຫ້ boot kernel.
ແລ່ນ initrd
"supermin --build" ສ້າງ initrd ຂະຫນາດນ້ອຍ. initrd ບໍ່ແມ່ນເຄື່ອງໃຊ້. ໄດ້
ຈຸດປະສົງຂອງ initrd ແມ່ນເພື່ອໂຫຼດໂມດູນແກ່ນພຽງພໍເພື່ອໃຫ້ເຄື່ອງໃຊ້
ຕົວຂອງມັນເອງສາມາດຕິດຕັ້ງແລະເລີ່ມຕົ້ນ.
initrd ແມ່ນບ່ອນເກັບມ້ຽນ cpio ທີ່ເອີ້ນວ່າ /var/tmp/.guestfs- /appliance.d/initrd.
ເມື່ອ initrd ໄດ້ເລີ່ມຕົ້ນທ່ານຈະເຫັນຂໍ້ຄວາມສະແດງໃຫ້ເຫັນວ່າໂມດູນ kernel ແມ່ນ
ຖືກໂຫລດ, ຄ້າຍຄືກັບນີ້:
supermin: ext2 mini initrd ເລີ່ມຂຶ້ນ
supermin: ການຕິດຕັ້ງ / sys
supermin: ພາຍໃນ insmod libcrc32c.ko
supermin: ພາຍໃນ insmod crc32c-intel.ko
ຊອກຫາ ແລະຕິດຕັ້ງອຸປະກອນເຄື່ອງໃຊ້
ເຄື່ອງໃຊ້ເປັນໄຟລ໌ກະແຈກກະຈາຍທີ່ມີລະບົບໄຟລ໌ ext2 ເຊິ່ງປະກອບດ້ວຍເຄື່ອງທີ່ຄຸ້ນເຄີຍ
(ເຖິງແມ່ນວ່າຈະຫຼຸດລົງໃນຂະຫນາດ) ລະບົບປະຕິບັດການ Linux. ມັນມັກຈະຖືກເອີ້ນວ່າ
/var/tmp/.guestfs- /appliance.d/root.
ແຜ່ນປົກກະຕິທີ່ຖືກກວດກາໂດຍ libguestfs ແມ່ນອຸປະກອນທໍາອິດທີ່ເປີດເຜີຍໂດຍ qemu
(ເຊັ່ນ: /dev/vda).
ແຜ່ນສຸດທ້າຍທີ່ເພີ່ມໃສ່ qemu ແມ່ນເຄື່ອງໃຊ້ຂອງມັນເອງ (ຕົວຢ່າງ. /dev/vdb ຖ້າມີພຽງແຕ່
ແຜ່ນປົກກະຕິຫນຶ່ງ).
ດັ່ງນັ້ນ, ວຽກງານສຸດທ້າຍຂອງ initrd ແມ່ນເພື່ອຊອກຫາແຜ່ນເຄື່ອງໃຊ້, ຕິດຕັ້ງມັນ, ແລະສະຫຼັບ
ຮາກເຂົ້າໄປໃນເຄື່ອງໃຊ້, ແລະດໍາເນີນການ /ໃນມັນ ຈາກເຄື່ອງໃຊ້.
ຖ້າອັນນີ້ເຮັດວຽກສຳເລັດທ່ານຈະເຫັນຂໍ້ຄວາມເຊັ່ນ:
supermin: ເລືອກ /sys/block/vdb/dev ເປັນອຸປະກອນຮາກ
supermin: ສ້າງ /dev/root ເປັນ block ພິເສດ 252:16
supermin: ຕິດຕັ້ງຮາກໃໝ່ໃສ່ / root
supermin: chroot
ກຳລັງເລີ່ມ /init script...
ໃຫ້ສັງເກດວ່າ "Starting /init script ... " ຊີ້ໃຫ້ເຫັນວ່າເຄື່ອງໃຊ້ init script ແມ່ນ
ໃນປັດຈຸບັນແລ່ນ.
ເລີ່ມຕົ້ນເຄື່ອງໃຊ້
ປະຈຸບັນເຄື່ອງໃຊ້ເອງເລີ່ມຕົ້ນຕົວມັນເອງ. ນີ້ກ່ຽວຂ້ອງກັບການເລີ່ມຕົ້ນຂະບວນການສະເພາະໃດຫນຶ່ງ
ເຊັ່ນ "udev", ອາດຈະພິມຂໍ້ມູນດີບັກບາງຢ່າງ, ແລະສຸດທ້າຍແລ່ນ daemon
("guestfsd").
ເດມອນ
ສຸດທ້າຍ daemon ("guestfsd") ແລ່ນພາຍໃນເຄື່ອງໃຊ້. ຖ້າມັນແລ່ນທ່ານຄວນເບິ່ງ:
verbose daemon ເປີດໃຊ້ງານ
daemon ຄາດວ່າຈະເຫັນພອດ virtio-serial ທີ່ມີຊື່ເປີດເຜີຍໂດຍ qemu ແລະເຊື່ອມຕໍ່
ປາຍອື່ນໆໄປຫາຫ້ອງສະຫມຸດ.
daemon ເຊື່ອມຕໍ່ກັບພອດນີ້ (ແລະດ້ວຍເຫດນີ້ໄປທີ່ຫ້ອງສະຫມຸດ) ແລະສົ່ງສີ່ byte
ຂໍ້ຄວາມ "GUESTFS_LAUNCH_FLAG", ເຊິ່ງລິເລີ່ມໂປຣໂຕຄໍການສື່ສານ (ເບິ່ງຂ້າງລຸ່ມນີ້).
ການສື່ສານ ໂປຣແກຣມ PROTOCOL
ຢ່າອີງໃສ່ການໃຊ້ໂປຣໂຕຄໍນີ້ໂດຍກົງ. ພາກນີ້ບັນທຶກວິທີການປະຈຸບັນ
ເຮັດວຽກ, ແຕ່ມັນອາດຈະປ່ຽນແປງໄດ້ທຸກເວລາ.
ໂປຣໂຕຄໍທີ່ໃຊ້ເພື່ອສົນທະນາລະຫວ່າງຫ້ອງສະໝຸດ ແລະ daemon ທີ່ແລ່ນຢູ່ໃນ qemu
virtual machine ເປັນກົນໄກ RPC ງ່າຍດາຍທີ່ສ້າງຂຶ້ນເທິງຂອງ XDR (RFC 1014, RFC 1832, RFC
4506).
ຮູບແບບລາຍລະອຽດຂອງໂຄງສ້າງແມ່ນຢູ່ໃນ src/guestfs_protocol.x (ໝາຍເຫດ: ໄຟລ໌ນີ້ແມ່ນ
ສ້າງອັດຕະໂນມັດ).
ມີສອງກໍລະນີກວ້າງ, ຫນ້າທີ່ທໍາມະດາທີ່ບໍ່ມີ "FileIn" ແລະ "FileOut" ໃດໆ.
ຕົວກໍານົດການ, ເຊິ່ງຖືກຈັດການດ້ວຍຂໍ້ຄວາມການຮ້ອງຂໍ / ຕອບກັບທີ່ງ່າຍດາຍຫຼາຍ. ຫຼັງຈາກນັ້ນ, ມີ
ຟັງຊັນທີ່ມີຕົວກໍານົດ "FileIn" ຫຼື "FileOut", ເຊິ່ງໃຊ້ຄໍາຮ້ອງຂໍດຽວກັນແລະ
ຕອບກັບຂໍ້ຄວາມ, ແຕ່ພວກມັນອາດຈະຖືກຕິດຕາມດ້ວຍໄຟລ໌ທີ່ສົ່ງໂດຍໃຊ້ການເຂົ້າລະຫັດແບບ chunked.
ທຳ ມະດາ FUNCTIONS (NO FILEIN/FILEOUT PARAMS)
ສໍາລັບຫນ້າທີ່ທໍາມະດາ, ຂໍ້ຄວາມຮ້ອງຂໍແມ່ນ:
ຄວາມຍາວທັງຫມົດ (header + arguments,
ແຕ່ບໍ່ລວມທັງຄໍາທີ່ຍາວຂອງຕົນເອງ)
ໂຄງສ້າງ guestfs_message_header (ເຂົ້າລະຫັດເປັນ XDR)
ໂຄງສ້າງ guestfs_ _args (ເຂົ້າລະຫັດເປັນ XDR)
ພາກສະຫນາມຄວາມຍາວທັງຫມົດອະນຸຍາດໃຫ້ daemon ຈັດສັນ buffer ຂະຫນາດຄົງທີ່ເຂົ້າໄປໃນມັນ
slurps ສ່ວນທີ່ເຫຼືອຂອງຂໍ້ຄວາມ. ດັ່ງນັ້ນ, ຄວາມຍາວທັງຫມົດແມ່ນຈໍາກັດ
"GUESTFS_MESSAGE_MAX" ໄບຕ໌ (ປະຈຸບັນແມ່ນ 4MB), ຊຶ່ງໝາຍເຖິງຂະໜາດທີ່ມີປະສິດທິພາບຂອງການຮ້ອງຂໍໃດໆ.
ຖືກຈໍາກັດຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງພາຍໃຕ້ຂະຫນາດນີ້.
ໃຫ້ສັງເກດວ່າຫຼາຍຫນ້າທີ່ບໍ່ເອົາການໂຕ້ຖຽງໃດໆ, ໃນກໍລະນີນີ້
"ແຂກ_foo_args" ຖືກລະເວັ້ນຢ່າງສົມບູນ.
ສ່ວນຫົວມີໝາຍເລກຂັ້ນຕອນ ("guestfs_proc") ເຊິ່ງເປັນວິທີທີ່ຜູ້ຮັບຮູ້
ປະເພດຂອງໂຄງສ້າງ args ທີ່ຈະຄາດຫວັງ, ຫຼືບໍ່ມີຢູ່ໃນທັງຫມົດ.
ສໍາລັບຫນ້າທີ່ທີ່ໃຊ້ເວລາການໂຕ້ຖຽງທາງເລືອກ, arguments ທາງເລືອກແມ່ນໄດ້ເຂົ້າລະຫັດໃນ
"ແຂກ_foo_args" ໂຄງສ້າງໃນລັກສະນະດຽວກັນກັບການໂຕ້ຖຽງທົ່ວໄປ. bitmask ໃນ
header ຊີ້ບອກວ່າການໂຕ້ຖຽງທາງເລືອກໃດມີຄວາມໝາຍ. bitmask ຍັງຖືກກວດສອບ
ເບິ່ງວ່າມັນປະກອບດ້ວຍບິດທີ່ daemon ບໍ່ຮູ້ກ່ຽວກັບ (ເຊັ່ນ: ຖ້າທາງເລືອກເພີ່ມເຕີມ
arguments ໄດ້ຖືກເພີ່ມໃນສະບັບຕໍ່ມາຂອງຫ້ອງສະຫມຸດ), ແລະນີ້ເຮັດໃຫ້ການໂທເປັນ
ຖືກປະຕິເສດ.
ຂໍ້ຄວາມຕອບສໍາລັບຫນ້າທີ່ທໍາມະດາແມ່ນ:
ຄວາມຍາວທັງໝົດ (header + ret,
ແຕ່ບໍ່ລວມທັງຄໍາທີ່ຍາວຂອງຕົນເອງ)
ໂຄງສ້າງ guestfs_message_header (ເຂົ້າລະຫັດເປັນ XDR)
ໂຄງສ້າງ guestfs_ _ret (ເຂົ້າລະຫັດເປັນ XDR)
ດັ່ງຂ້າງເທິງ "guestfs_foo_ret" ໂຄງປະກອບການອາດຈະຖືກຍົກເວັ້ນຢ່າງສົມບູນສໍາລັບຫນ້າທີ່
return ບໍ່ມີຄ່າຜົນຕອບແທນຢ່າງເປັນທາງການ.
ດັ່ງທີ່ຂ້າງເທິງຄວາມຍາວທັງໝົດຂອງການຕອບຖືກຈຳກັດໄວ້ທີ່ "GUESTFS_MESSAGE_MAX".
ໃນກໍລະນີທີ່ມີຄວາມຜິດພາດ, ທຸງຕັ້ງຢູ່ໃນຫົວຂໍ້, ແລະຂໍ້ຄວາມຕອບກັບແມ່ນເລັກນ້ອຍ
ປ່ຽນ:
ຄວາມຍາວທັງໝົດ (ສ່ວນຫົວ + ຂໍ້ຜິດພາດ,
ແຕ່ບໍ່ລວມທັງຄໍາທີ່ຍາວຂອງຕົນເອງ)
ໂຄງສ້າງ guestfs_message_header (ເຂົ້າລະຫັດເປັນ XDR)
ໂຄງສ້າງ guestfs_message_error (ເຂົ້າລະຫັດເປັນ XDR)
ໂຄງສ້າງ "guestfs_message_error" ມີຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດເປັນສະຕຣິງ.
FUNCTIONS ທີ່ ມີ FILEIN PARAMETERS
ຕົວກໍານົດການ "FileIn" ຊີ້ໃຫ້ເຫັນວ່າພວກເຮົາໂອນໄຟລ໌ ເຂົ້າໄປໃນ ແຂກ. ຄໍາຮ້ອງສະຫມັກປົກກະຕິ
ຂໍ້ຄວາມຖືກສົ່ງ (ເບິ່ງຂ້າງເທິງ). ຢ່າງໃດກໍຕາມ, ນີ້ແມ່ນປະຕິບັດຕາມລໍາດັບຂອງ chunks ໄຟລ໌.
ຄວາມຍາວທັງຫມົດ (header + arguments,
ແຕ່ບໍ່ໄດ້ລວມທັງຄໍາຍາວຕົວມັນເອງ,
ແລະບໍ່ລວມທັງການ chunks)
ໂຄງສ້າງ guestfs_message_header (ເຂົ້າລະຫັດເປັນ XDR)
ໂຄງສ້າງ guestfs_ _args (ເຂົ້າລະຫັດເປັນ XDR)
ລໍາດັບຂອງ chunks ສໍາລັບ FileIn param #0
ລໍາດັບຂອງ chunks ສໍາລັບ FileIn param #1 ແລະອື່ນໆ.
"ລໍາດັບຂອງ chunks" ແມ່ນ:
ຄວາມຍາວຂອງ chunk (ບໍ່ລວມທັງຄໍາຍາວຕົວມັນເອງ)
ໂຄງສ້າງ guestfs_chunk (ເຂົ້າລະຫັດເປັນ XDR)
ຄວາມຍາວຂອງຕ່ອນ
ໂຄງສ້າງ guestfs_chunk (ເຂົ້າລະຫັດເປັນ XDR)
...
ຄວາມຍາວຂອງຕ່ອນ
ໂຄງສ້າງ guestfs_chunk (ມີ data.data_len == 0)
ຊິ້ນສຸດທ້າຍມີຊ່ອງຂໍ້ມູນ "data_len" ຖືກຕັ້ງເປັນສູນ. ນອກຈາກນັ້ນ, ທຸງຖືກຕັ້ງຢູ່ໃນ
chunk ສຸດທ້າຍເພື່ອຊີ້ບອກວ່າທັງການສໍາເລັດສົບຜົນສໍາເລັດຫຼືການຍົກເລີກໄວ.
ໃນເວລາຂຽນບໍ່ມີຫນ້າທີ່ທີ່ມີຫຼາຍກວ່າຫນຶ່ງຕົວກໍານົດການ FileIn.
ຢ່າງໃດກໍຕາມ, ນີ້ແມ່ນສະຫນັບສະຫນູນ (ທາງທິດສະດີ), ໂດຍການສົ່ງລໍາດັບຂອງ chunks ສໍາລັບແຕ່ລະຄົນ
ຕົວກໍານົດການ FileIn ຫນຶ່ງຫຼັງຈາກອື່ນ (ຈາກຊ້າຍຫາຂວາ).
ທັງຫ້ອງສະຫມຸດ (ຜູ້ສົ່ງ) ແລະ daemon (ຜູ້ຮັບ) ອາດຈະຍົກເລີກການໂອນ. ຫໍສະໝຸດ
ເຮັດນີ້ໂດຍການສົ່ງ chunk ທີ່ມີທຸງພິເສດທີ່ກໍານົດໄວ້ເພື່ອຊີ້ບອກການຍົກເລີກ. ໃນເວລາທີ່
daemon ເຫັນນີ້, ມັນຍົກເລີກ RPC ທັງຫມົດ, ເຮັດ ບໍ່ ສົ່ງຄໍາຕອບໃດໆ, ແລະກັບຄືນໄປຫາ
ອ່ານຄໍາຮ້ອງຂໍຕໍ່ໄປ.
daemon ອາດຈະຍົກເລີກເຊັ່ນກັນ. ມັນເຮັດສິ່ງນີ້ໂດຍການຂຽນຄໍາພິເສດ "GUESTFS_CANCEL_FLAG"
ກັບເຕົ້າຮັບ. ຫ້ອງສະຫມຸດຟັງສໍາລັບການນີ້ໃນລະຫວ່າງການໂອນ, ແລະຖ້າຫາກວ່າມັນໄດ້ຮັບມັນ, ມັນ
ຈະຍົກເລີກການຍົກຍ້າຍ (ມັນຈະສົ່ງ chunk ຍົກເລີກການ). ຄໍາທີ່ພິເສດແມ່ນໄດ້ຮັບການຄັດເລືອກດັ່ງນັ້ນ
ເຖິງແມ່ນວ່າການຍົກເລີກຈະເກີດຂຶ້ນທັນທີໃນຕອນທ້າຍຂອງການໂອນ (ຫຼັງຈາກຫ້ອງສະຫມຸດມີ
ສໍາເລັດຮູບຂຽນແລະໄດ້ເລີ່ມຕົ້ນການຟັງສໍາລັບການຕອບ), "spurious" ທຸງຍົກເລີກຈະ
ຢ່າສັບສົນກັບຂໍ້ຄວາມຕອບ.
ອະນຸສັນຍານີ້ອະນຸຍາດໃຫ້ການໂອນໄຟລ໌ຂະຫນາດຕົນເອງ (ບໍ່ມີຈໍາກັດ 32 bit), ແລະຍັງ
ໄຟລ໌ທີ່ຂະຫນາດບໍ່ໄດ້ຮູ້ລ່ວງຫນ້າ (ເຊັ່ນ: ຈາກທໍ່ຫຼືເຕົ້າຮັບ). ແນວໃດກໍ່ຕາມ
chunks ແມ່ນຂ້ອນຂ້າງນ້ອຍ ("GUESTFS_MAX_CHUNK_SIZE"), ດັ່ງນັ້ນບໍ່ມີຫ້ອງສະຫມຸດຫຼືຫ້ອງສະຫມຸດ.
daemon ຈໍາເປັນຕ້ອງເກັບຮັກສາຫຼາຍໃນຄວາມຊົງຈໍາ.
FUNCTIONS ທີ່ ມີ ໄຟລ໌ PARAMETERS
ໂປໂຕຄອນສໍາລັບຕົວກໍານົດການ FileOut ແມ່ນຄືກັນກັບຕົວກໍານົດການ FileIn, ແຕ່ວ່າມີ
ພາລະບົດບາດຂອງ daemon ແລະຫ້ອງສະຫມຸດປີ້ນກັບກັນ.
ຄວາມຍາວທັງໝົດ (header + ret,
ແຕ່ບໍ່ໄດ້ລວມທັງຄໍາຍາວຕົວມັນເອງ,
ແລະບໍ່ລວມທັງການ chunks)
ໂຄງສ້າງ guestfs_message_header (ເຂົ້າລະຫັດເປັນ XDR)
ໂຄງສ້າງ guestfs_ _ret (ເຂົ້າລະຫັດເປັນ XDR)
ລໍາດັບຂອງ chunks ສໍາລັບ FileOut param #0
ລໍາດັບຂອງ chunks ສໍາລັບ FileOut param #1 ແລະອື່ນໆ.
INITIAL ຂໍ້ຄວາມ
ເມື່ອ daemon ເປີດຕົວມັນຈະສົ່ງຄໍາເລີ່ມຕົ້ນ ("GUESTFS_LAUNCH_FLAG") ເຊິ່ງຊີ້ໃຫ້ເຫັນ.
ວ່າແຂກແລະ daemon ແມ່ນມີຊີວິດຢູ່. ນີ້ແມ່ນສິ່ງທີ່ "guestfs_launch" ລໍຖ້າ.
ໂຄງການ ແຈ້ງການ MESSAGES
daemon ອາດຈະສົ່ງຂໍ້ຄວາມການແຈ້ງເຕືອນຄວາມຄືບຫນ້າໄດ້ທຸກເວລາ. ເຫຼົ່ານີ້ແມ່ນຈໍາແນກ
ໂດຍຄໍາທີ່ມີຄວາມຍາວປົກກະຕິຖືກແທນທີ່ດ້ວຍ "GUESTFS_PROGRESS_FLAG", ຕິດຕາມດ້ວຍການແກ້ໄຂ
ຂໍ້ຄວາມຄວາມຄືບຫນ້າຂະຫນາດ.
ຫ້ອງສະໝຸດປ່ຽນພວກມັນໃຫ້ກາຍເປັນການເອີ້ນຄືນຄວາມຄືບໜ້າ (ເບິ່ງ "GUESTFS_EVENT_PROGRESS") ຖ້າມີ
ໂທກັບທີ່ລົງທະບຽນ, ຫຼືຍົກເລີກພວກມັນຖ້າບໍ່ແມ່ນ.
daemon ຕົນເອງຈໍາກັດຄວາມຖີ່ຂອງຂໍ້ຄວາມຄວາມຄືບຫນ້າທີ່ມັນສົ່ງ (ເບິ່ງ
"daemon/proto.c:notify_progress"). ບໍ່ແມ່ນການໂທທັງໝົດຈະສ້າງຂໍ້ຄວາມຄວາມຄືບໜ້າ.
FIXED ປະຕິບັດ
ເມື່ອ libguestfs (ຫຼືເຄື່ອງມື libguestfs) ຖືກແລ່ນ, ພວກເຂົາຄົ້ນຫາເສັ້ນທາງທີ່ຊອກຫາ
ເຄື່ອງໃຊ້. ເສັ້ນທາງດັ່ງກ່າວຖືກສ້າງຂຶ້ນໃນ libguestfs, ຫຼືສາມາດຕັ້ງຄ່າໄດ້ໂດຍໃຊ້ "LIBGUESTFS_PATH"
environment variable
ປົກກະຕິແລ້ວເຄື່ອງໃຊ້ຊຸບເປີມິນຕັ້ງຢູ່ເທິງເສັ້ນທາງນີ້ (ເບິ່ງ "SUPERMIN APPLIANCE" ໃນ
ຊຸບເປີມິນ(1)). libguestfs reconstructs ນີ້ເຂົ້າໄປໃນເຄື່ອງໃຊ້ຢ່າງເຕັມທີ່ໂດຍການແລ່ນ "supermin
-- ກໍ່ສ້າງ".
ຢ່າງໃດກໍ່ຕາມ, "ເຄື່ອງໃຊ້ຄົງທີ່" ທີ່ງ່າຍກວ່າຍັງສາມາດຖືກນໍາໃຊ້. libguestfs ກວດພົບນີ້ໂດຍການເບິ່ງ
ສໍາລັບໄດເລກະທໍລີຢູ່ໃນເສັ້ນທາງທີ່ມີໄຟລ໌ຕໍ່ໄປນີ້ທັງຫມົດ:
· kernel
· ເລີ່ມຕົ້ນ
· ຮາກ
· README. ແກ້ໄຂ (ສັງເກດວ່າມັນ ຕ້ອງ ຢູ່ເຊັ່ນດຽວກັນ)
ຖ້າພົບອຸປະກອນຄົງທີ່, libguestfs ຂ້າມ supermin ທັງຫມົດແລະພຽງແຕ່ດໍາເນີນການ.
virtual machine (ໃຊ້ qemu ຫຼື backend ປະຈຸບັນ, ເບິ່ງ "BACKEND") ກັບ kernel, initrd
ແລະຮາກແຜ່ນຈາກອຸປະກອນຄົງທີ່.
ດັ່ງນັ້ນເຄື່ອງໃຊ້ຄົງທີ່ສາມາດຖືກນໍາໃຊ້ໃນເວລາທີ່ເວທີຫຼືການແຈກຢາຍ Linux ບໍ່ໄດ້
ສະຫນັບສະຫນູນ supermin. ທ່ານສ້າງເຄື່ອງໃຊ້ຄົງທີ່ໃນເວທີທີ່ສະຫນັບສະຫນູນ supermin
ການນໍາໃຊ້ libguestfs-make-fixed-appliance(1), ຄັດລອກມັນ, ແລະໃຊ້ມັນເພື່ອດໍາເນີນການ libguestfs.
ໃຊ້ guestfs-internals ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net
