qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseri


From: Andrea Bolognani
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)
Date: Wed, 21 Dec 2016 09:38:17 +0100

On Wed, 2016-12-21 at 15:52 +1100, David Gibson wrote:
> > > I'm not sure if we need a knob.  I think in general enabling for
> > > pseries-2.9 and later machine types is correct.  The difficulty is
> > > that for HV guests, we can only enable it if the host kernel also has
> > > support.  Explicitly setting "resize-hpt=enable" means qemu will not
> > > start if the kernel doesn't support it.
>
> > I thought that would be the case for resize-hpt=required,
> > not resized-hpt=enabled.
> 
> resize-hpt=enabled requires the host to support resizing, but not the
> guest.  resize-hpt=required requires both the host and the guest to
> support resizing.
> 
> If you can think of a less ambiguous word for it, let me know.

The name makes sense, we just need to document the host
kernel requirement properly. The error message should of
course mention it as well.

> > Moreover, do you foresee any situation in which users
> > might reasonably want to turn the feature off even though
> > the entire stack (host kernel, QEMU, guest kernel)
> > understands it?
> 
> Nothing clearly compelling.  In the nearish term, being able to turn
> it off to isolate possible bugs could be useful of course.  It's also
> possible that you could have a VM where the latency of each resize
> could be too much downtime - although in that case I doubt you'd want
> to hotplug memory anyway.

It seems like the use case would be fairly narrow, if it
existed at all. Given that, I think we should avoid adding
yet another knob to libvirt until its value can be
unquestionably proven.

-- 
Andrea Bolognani / Red Hat / Virtualization



reply via email to

[Prev in Thread] Current Thread [Next in Thread]