mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-05 04:41:20 +00:00
359c6365b9
Now that the virAuthGet*Path API's generate all the error messages we can remove them from the callers. This means that we will no longer overwrite the error from the API. Signed-off-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> |
||
|---|---|---|
| .. | ||
| esx_driver.c | ||
| esx_driver.h | ||
| esx_interface_driver.c | ||
| esx_interface_driver.h | ||
| esx_network_driver.c | ||
| esx_network_driver.h | ||
| esx_private.h | ||
| esx_storage_backend_iscsi.c | ||
| esx_storage_backend_iscsi.h | ||
| esx_storage_backend_vmfs.c | ||
| esx_storage_backend_vmfs.h | ||
| esx_storage_driver.c | ||
| esx_storage_driver.h | ||
| esx_stream.c | ||
| esx_stream.h | ||
| esx_util.c | ||
| esx_util.h | ||
| esx_vi_generator.input | ||
| esx_vi_generator.py | ||
| esx_vi_methods.c | ||
| esx_vi_methods.h | ||
| esx_vi_types.c | ||
| esx_vi_types.h | ||
| esx_vi.c | ||
| esx_vi.h | ||
| Makefile.inc.am | ||
| README | ||
Some links to relevant documentation ==================================== VI/vSphere API: http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/ http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/ http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/ VMX config: http://www.sanbarrow.com/vmx.html CPUID: http://www.sandpile.org/ia32/cpuid.htm Memory model: http://www.vmware.com/pdf/esx3_memory.pdf http://www.vmware.com/pdf/usenix_resource_mgmt.pdf Virtual serial port (network backed): http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.vm.device.VirtualSerialPort.URIBackingInfo.html http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/vsp41_usingproxy_virtual_serial_ports.pdf Automatic question handling =========================== What is a question in the ESX context? -------------------------------------- The VI API contains methods that start tasks, for example PowerOnVM_Task(). Such tasks may be blocked by questions if the ESX host detects an issue with the virtual machine that requires user interaction. An example: If a virtual machine has a serial port that is realized via a file, the ESX host will ask a question on power-on of this virtual machine whether new content should be appended to this file or the file should be replaced. Until this question is answered the power-on task is blocked and the virtual machine won't get powered on. The ESX driver cannot prompt the user to answer a question, libvirt doesn't have an API for something like this. The VI API provides the AnswerVM() method to programmatically answer such questions. A question comes together with a list of possible answers. One of this answers is marked as the default one. For all questions I've seen so far the default answer is always a non-destructive one. There are two options how to handle a question that is blocking a task: either answer it automatically or report it as error and try to cancel the blocked task. The auto_answer query parameter defines how the driver should handle questions. Possible values are 0 for the report-error-and-try-to-cancel option and 1 for the automatic-answer option. How is automatic question handling implemented? ----------------------------------------------- Before any new task is started the driver checks if there is a pending task blocked by a question. If automatic question handling is disabled the driver reports an error that includes the question and returns from the driver function. If automatic question handling is enabled the driver answers the question with the default answer and returns from the driver function. In both cases the actual desired task is not started. If the question was not answered the blocked task is still blocked and because task can't be executed in parallel in general it's of no use to start yet another task. If the question was answered the blocked task may already perform the desired action and one must wait for its completion, so it's of no use to start yet another task. If there is no question blocking a task or another pending task that had not finished yet the driver starts the desired task and waits for its completion. While polling for status updates of the task it also checks for question that may have been triggered by the current task and handles them according to the value of the auto_answer query parameter. If automatic question handling is enabled the driver answers the question with the default answer and continues polling for status updates. If automatic question handling is disabled the driver reports an error that includes the question, tries to cancel the blocked task and returns from the driver function. It tries to cancel the blocked task, but this may not be possible, because there are task like the power-on task that is marked as non-cancelable. So the driver may leave blocked tasks behind if automatic question handling is disabled. Different escaping schemes used in different places =================================================== A domain name in the vSphere API has [%/\] escaped as %XX (percent-encoding), where XX is the ASCII code of the escaped char in hex. A domainName entry in a VMX config file is percent-encoded and has [|"] escaped as |XX (pipe-encoding). A annotation entry in a VMX config file is pipe-encoded. A datastore item name has the special Windows path characters ["*<>:|?] replaced by underscores (_). The result is escaped using percent-encoding and base64-encoding. This isn't a bijective encoding. Therefore, escaped datastore item names cannot be unescaped completely. For base64-encoding sequences of chars that don't match [a-zA-Z0-9'(),. _-] are replaced by their base64 form (the padding is omitted). An encoded sequence begins with a plus (+), ends with a minus (-) and can contain a plus (+). The minus (-) is omitted if the string ends in a base64-encoded sequence. VMware uses the comma (,) instead of the slash (/) in the base64 alphabet to avoid conflicts with the slash as path separator.