[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] libxl: Add suppress-vmdesc to QEMU -machine pc options
On Tue, Oct 20, 2020 at 11:40 AM Anthony PERARD <anthony.perard@xxxxxxxxxx> wrote: > > On Mon, Oct 19, 2020 at 04:00:50PM -0400, Jason Andryuk wrote: > > The device model state saved by QMP xen-save-devices-state doesn't > > include the vmdesc json. When restoring an HVM, xen-load-devices-state > > always triggers "Expected vmdescription section, but got 0". This is > > not a problem when restore comes from a file. However, when QEMU runs > > in a linux stubdom and comes over a console, EOF is not received. This > > causes a delay restoring - though it does restore. > > > > Setting suppress-vmdesc skips looking for the vmdesc during restore and > > avoids the wait. > > > > This is a libxl change for the non-xenfv case to match the xenfv change > > made in qemu > > > > Signed-off-by: Jason Andryuk <jandryuk@xxxxxxxxx> > > --- > > > > Should this also add suppress-vmdesc to xenfv for backwards > > compatibility? In that case, the change in QEMU is redundent. Since > > this only really matters for the stubdom case, it could be conditioned > > on that. > > QEMU doesn't complain about having suppress-vmdesc set on the command > line and as a default for the xenfv machine, so I don't mind adding it > to the xenfv machine in libxl, while keeping the change in QEMU. Okay. > The change is already applied to QEMU, so unless there's an issue, I > don't want to revert it. It might be useful for tool stacks that don't > use libxl. Good point about the alternative toolstacks. > Also, the change matters as well for non-stubdom cases as it removed a > cryptic error message from qemu-dm's logs :-). :) Yes, as I explained for the QEMU change it is the correct thing to do. It's just kinda a shame that libxl will need a compatibility change kept around indefinitely. Regards, Jason
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |