On 05/11/2016 11:21 PM, Jim Fehlig wrote:
On 05/11/2016 05:22 AM, Joao Martins wrote:
> On 05/11/2016 06:01 AM, Jim Fehlig wrote:
>> Commit 6879be48 moved adding of an implicit video device after XML
>> parsing. As a result, libxlDomainDeviceDefPostParse() is no longer
>> called to set the default vram when adding an implicit device.
>> Commit 6879be48 assumes virDomainVideoDefaultRAM() will set the
>> default vram, but it returns 0 if the domain virtType is
>> VIR_DOMAIN_VIRT_XEN. Attempting to start an HVM domain with vram=0
>> results in
>>
>> error: unsupported configuration: videoram must be at least 4MB for CIRRUS
>>
>> The default vram setting for Xen HVM domains depends on the device
>> model used (qemu-xen vs qemu-traditional), hence setting the
>> default is deferred to libxlDomainDeviceDefPostParse().
>>
>> This patch addresses the problem during creation of the video
>> device. If vram is 0, it is assumed unset and the default
>> (depending on qemu-xen vs qemu-traditional) is applied.
> Hmm, What about letting (xen) libxl decide that? If vram is set to 0 we would
> set video_memkb to LIBXL_MEMKB_DEFAULT and have (xen) libxl decide the defaults
> and latter update def with the value libxl set back?
Yeah, that sounds like a good cleanup for the existing code. But I think fixing
the logic broken by commit 6879be48 is also in order, which Jan has kindly done
in place of this hack
https://www.redhat.com/archives/libvir-list/2016-May/msg00728.html
Yeap, I saw it shortly after my reply.
> Altough these values are
> well established defaults, these might change on libxl in which case prevent
> domain creation.
Yep. Good reason for a follow-up patch along the lines of your suggestion :-).
Ah,
sounds good!
Regards,
Jim