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