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