On 02/17/2013 11:50 AM, Alon Levy wrote: > Hi Martin, > >> On 02/04/2013 04:16 PM, Christophe Fergeau wrote: >>> QXL devices have an associated 'revision' which is raised when >>> new features have been introduced which would break migration >>> to older versions. This commit makes it possible to set this >>> revision as QEMU sometimes support newer QXL revisions than what >>> it defaults to. >> >> This could help a lot, but few questions, if I may: >> - This only helps when the revision is specified, otherwise not, >> right? > > If by "helps" you mean "changes the revision", then it's a bit more complex - > the revision is determined by order of precedence by the following: > default > machine type (i.e. via -M) > global (which this patch sets) >
Even though this is not the root cause neither the place we want to fix it; so the theoretical migration problem occurs because the machine type doesn't specify the revision, right? Just asking to make sure I understand. >> - Isn't there a way how to get the current supported (running) >> revision >> of QEMU's qxl video? >> >> If we don't know the current (and supported) revision, we are >> exposing a >> parameter we know completely nothing about and thus can only try to >> start qemu with it and wait if it initializes (I know that's how we >> do >> it with devices, but there's no other option). Transferring current >> revision during migration (even when unspecified) would help >> determining >> such errors before starting QEMU on destination. >> >> There's not much info about the revisions if you don't look in QEMU >> sources, so I'm not sure what our possibilities are. It's a good >> thing >> that the 'revision' parameter is supported since the same commit as >> qxl >> driver, though. > > There is no "introspection" from the help, sorry. So like you said the only > way to know what supported revisions are is to: > 1) start a vm with -vga qxl as stopped, query the revision of the qxl device, > you get R, then [1..R] are supported (i.e. inclusive) This could be pretty doable. We already query some information from qemu, although not device-relevant. I have to look in the code, but good to know it is gettable from the monitor. Maybe we can run the initial '-M none' with '-vga qxl' or '-device qxl-[vga]' to get the revision. > 2) to find out which higher revisions are supported, you'll have to start > with each successive higher revision until you get an error code (you can > wait for the machine start event, that is sent after all devices are > initialized) > > Of course we can fix qemu to report it now, but it won't help for any of the > older versions.. > Thanks for the info, Martin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
