[libvirt] [PATCHv2] qemu: Do fake auto-allocation of ports when generating native command
Peter Krempa
pkrempa at redhat.com
Mon May 6 21:04:14 UTC 2013
On 05/06/13 19:09, Eric Blake wrote:
> On 05/02/2013 03:16 AM, Peter Krempa wrote:
>> When attempting to generate the native command line from an XML file
>> that uses graphics port auto allocation, the generated commandline
>> wouldn't be valid.
>>
>> This patch adds fake autoallocation of ports as done when starting the
>> actual machine.
>> ---
>>
>> Notes:
>> Version 2:
>> - rebased after context-conflict with 11fc1beab6e018a88182f80056d35217c150b3de
>>
>> src/qemu/qemu_driver.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>
> ACK.
>
>>
>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>> index 9492850..45fcf05 100644
>> --- a/src/qemu/qemu_driver.c
>> +++ b/src/qemu/qemu_driver.c
>> @@ -5274,6 +5274,58 @@ static char *qemuConnectDomainXMLToNative(virConnectPtr conn,
>> if (qemuDomainAssignAddresses(def, qemuCaps, NULL) < 0)
>> goto cleanup;
>>
>> + /* do fake auto-alloc of graphics ports, if such config is used */
>> + for (i = 0 ; i < def->ngraphics; ++i) {
>> + virDomainGraphicsDefPtr graphics = def->graphics[i];
>> + if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC &&
>> + !graphics->data.vnc.socket && graphics->data.vnc.autoport) {
>> + graphics->data.vnc.port = 5900;
>
> I don't know if using QEMU_REMOTE_PORT_MIN instead of hard-coding the
> magic number is any better, but we already discussed that for purposes
> of command-line generation, ANY port number will do, so it doesn't
> really invalidate your patch.
>
Thanks for the reviews. This patch is now pushed. As this is a fix that
we generate a valid commandline for qemu, when somebody tries to use the
domxml-to-native command/API I don't think it's necessary to spend more
time on it. I was considering if it's even worth doing this at all. I
decided that we should do it this way, as nobody can expect that
autoallocation should work outside of libvirt's control.
Peter
More information about the libvir-list
mailing list