On Wed, Apr 13, 2016 at 05:37:05PM -0600, Jim Fehlig wrote:
To ensure the libvirt libxl driver will build with future versions
of Xen where the libxl API may change in incompatible ways,
explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
does use new libxl APIs that have been added since
On Thu, Apr 14, 2016 at 04:35:12PM -0600, Jim Fehlig wrote:
To ensure the libvirt libxl driver will build with future versions
of Xen where the libxl API may change in incompatible ways,
explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
does use new libxl APIs that have been added since
On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
Hi All,
I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
Summit, but the list is certainly a better place to discuss such a topic. What
do folks think about finally removing the old, legacy, xend-based driver
On Thu, Feb 02, 2017 at 11:15:41AM -0700, Jim Fehlig wrote:
On 02/02/2017 04:42 AM, Wei Liu wrote:
I saw this mail but didn't realise it required my input, sorry.
I suppose it didn't and I was shamelessly fishing for a review - so you have my
apologies :-). But the patch does fix an annoying,
On Tue, Oct 04, 2016 at 06:02:27PM +0100, Ian Jackson wrote:
Currently, osstest wrongly thinks that ARM can do save/restore,
because `virsh help' does mention the save command (on all
architectures).
Additionally, check the virth capabilities xpath
/capabilities/host/migration_features
to try
On Wed, Oct 05, 2016 at 06:06:29PM -0600, Jim Fehlig wrote:
On 10/04/2016 11:02 AM, Ian Jackson wrote:
Currently, osstest wrongly thinks that ARM can do save/restore,
because `virsh help' does mention the save command (on all
architectures).
Additionally, check the virth capabilities xpath
/
On Thu, Oct 06, 2016 at 10:59:06AM +0100, Ian Jackson wrote:
Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt
save/restore when migration not advertised"):
Since offline migration (as in migrating a domain between hosts without
being running) is not that u
On Thu, Nov 03, 2016 at 01:50:17PM +, Wei Liu wrote:
Hi
Xen Project's CI system found a build failure between libvirt changes
06a7b1ff..478ddedc. I don't think this is Xen specific FWIW.
My guess is either 680d2f49dad425395de627a31006cb84848cfa65 or
0c62ccf927c60c9c248db52a23670ec2f9bce2
On Tue, Mar 24, 2015 at 02:43:42PM -0600, Jim Fehlig wrote:
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When
On Tue, Mar 31, 2015 at 08:16:09AM -0600, Jim Fehlig wrote:
Martin Kletzander wrote:
On Tue, Mar 24, 2015 at 02:43:42PM -0600, Jim Fehlig wrote:
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is us
On Wed, Mar 25, 2015 at 02:08:34PM -0600, Jim Fehlig wrote:
Let callers of libxlDomainStart decide when it is appropriate to
acquire a job on the associated virDomainObj.
This makes sense, I see many bugs this fixes, but how come
libxlDomainShutdownThread(), libxlDomainRestoreFlags() and
libxl
On Thu, Mar 26, 2015 at 03:29:51PM -0600, Jim Fehlig wrote:
Konrad Rzeszutek Wilk wrote:
On Wed, Mar 25, 2015 at 02:08:35PM -0600, Jim Fehlig wrote:
A job should be acquired at the beginning of a domain destroy operation,
not at the end when cleaning up the domain. Fix two occurances of this
On Wed, Apr 01, 2015 at 11:08:54AM -0600, Jim Fehlig wrote:
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When
13 matches
Mail list logo
