On 06/01/2016 01:33 PM, Matt Riedemann wrote:
>
> Sounds like there was a bad check in nova which is fixed here:
>
> https://review.openstack.org/#/c/323467/
>
> And a d-g change depends on that here:
>
> https://review.openstack.org/#/c/320925/
>
> Is there anything more to do for this? I'm
On 5/31/2016 8:36 AM, Daniel P. Berrange wrote:
On Tue, May 31, 2016 at 08:19:33AM -0400, Sean Dague wrote:
On 05/30/2016 06:25 AM, Kashyap Chamarthy wrote:
On Thu, May 26, 2016 at 10:55:47AM -0400, Sean Dague wrote:
On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
On Wed, May 25, 2016 at 05:
On Tue, May 31, 2016 at 08:24:03AM -0400, Sean Dague wrote:
> On 05/31/2016 05:39 AM, Daniel P. Berrange wrote:
> > On Tue, May 24, 2016 at 01:59:17PM -0400, Sean Dague wrote:
> >> The team working on live migration testing started with an experimental
> >> job on Ubuntu 16.04 to try to be using th
On Tue, May 31, 2016 at 08:19:33AM -0400, Sean Dague wrote:
> On 05/30/2016 06:25 AM, Kashyap Chamarthy wrote:
> > On Thu, May 26, 2016 at 10:55:47AM -0400, Sean Dague wrote:
> >> On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
> >>> On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrot
On 05/31/2016 05:39 AM, Daniel P. Berrange wrote:
> On Tue, May 24, 2016 at 01:59:17PM -0400, Sean Dague wrote:
>> The team working on live migration testing started with an experimental
>> job on Ubuntu 16.04 to try to be using the latest and greatest libvirt +
>> qemu under the assumption that a
On 05/30/2016 06:25 AM, Kashyap Chamarthy wrote:
> On Thu, May 26, 2016 at 10:55:47AM -0400, Sean Dague wrote:
>> On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
>>> On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:
>>>
>>> [...]
>>>
So, in short, the central issue seems to b
On Tue, May 24, 2016 at 01:59:17PM -0400, Sean Dague wrote:
> The team working on live migration testing started with an experimental
> job on Ubuntu 16.04 to try to be using the latest and greatest libvirt +
> qemu under the assumption that a set of issues we were seeing are
> solved. The short an
On Thu, May 26, 2016 at 10:55:47AM -0400, Sean Dague wrote:
> On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
> > On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:
> >
> > [...]
> >
> >> So, in short, the central issue seems to be this: the custom 'gate64'
> >> model is not bein
On 05/24/2016 01:59 PM, Sean Dague wrote:
> So, we have a number of open questions:
>
> * Have our cloud providers standardized enough that we might get away
> without this custom cpu model? (Have some of them done it and only use
> those for multinode?)
This is definitely not true on RAX. Exper
On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
> On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:
>
> [...]
>
>> So, in short, the central issue seems to be this: the custom 'gate64'
>> model is not being trasnalted by libvirt into a model that QEMU can
>> recognize.
>
> An u
On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:
[...]
> So, in short, the central issue seems to be this: the custom 'gate64'
> model is not being trasnalted by libvirt into a model that QEMU can
> recognize.
An update:
Upstream libvirt points out that this turns to be regres
On Tue, May 24, 2016 at 01:59:17PM -0400, Sean Dague wrote:
Thanks for the summary, Sean.
[...]
> It turns out it works fine because libvirt *actually* seems to take the
> data from cpu_map.xml and do a translation to what it believes qemu will
> understand. On these systems apparently this turn
The team working on live migration testing started with an experimental
job on Ubuntu 16.04 to try to be using the latest and greatest libvirt +
qemu under the assumption that a set of issues we were seeing are
solved. The short answer is, it doesn't look like this is going to work.
We run tests o
13 matches
Mail list logo
