[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.


> 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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.