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 > 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 :-). Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list