mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-25 01:34:11 +03:00
2dd86bbe5a
VMware uses a mix of percent-, pipe- and base64-encoding in different combinations in different places. Add a testcase for this.
114 lines
5.0 KiB
Plaintext
114 lines
5.0 KiB
Plaintext
|
|
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.
|