ted, this bug seems to only occur with VMware 6.7+,
> > and
> > > > it sounds to me like they should take action on it. Does someone
> track
> > > this
> > > > with VMware?
> > > > * Do I understand correctly that the issue only occurs when the
&
, then the above
steps could help.
Cheers,
Gabriel.
Em qua., 27 de mai. de 2020 às 15:43, Riepl, Gregor (SWISS TXT) <
gregor.ri...@swisstxt.ch> escreveu:
> Thank you, Andrija!
>
> We will keep that in mind when we upgrade to 6.7.
> ____________
> From:
Thank you, Andrija!
We will keep that in mind when we upgrade to 6.7.
From: Andrija Panic
Sent: 20 May 2020 23:02
To: users
Cc: dev
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
@gregor - the legacy should be fine with UEFI (what I had run on some of my
ound.
> >
> > Regards,
> > Gregor
> >
> > From: Andrija Panic
> > Sent: 19 May 2020 21:11
> > To: users
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
> >
&
it isn't a proper fix
> or workaround.
>
> Regards,
> Gregor
>
> From: Andrija Panic
> Sent: 19 May 2020 21:11
> To: users
> Cc: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
>
> Hi all,
>
> In my humble opin
temporarily), there should
definitely some sort of safeguard around it, even if it isn't a proper fix or
workaround.
Regards,
Gregor
From: Andrija Panic
Sent: 19 May 2020 21:11
To: users
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache CloudStack 4.14.0.
2020 20:56
> To: users
> Cc: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
>
> Thanks Bobby,
> All, I've been closely working with Bobby and seen the same things. Does
> anybody see any issues releasing 4.14 based on this code? I ca
: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
Thanks Bobby,
All, I've been closely working with Bobby and seen the same things. Does
anybody see any issues releasing 4.14 based on this code? I can confirm
that it is not Pavernalli's UEFI PR and we should not create a new PR to
revert it.
tha
Thanks Bobby,
All, I've been closely working with Bobby and seen the same things. Does
anybody see any issues releasing 4.14 based on this code? I can confirm
that it is not Pavernalli's UEFI PR and we should not create a new PR to
revert it.
thanks for all of your patience,
(this is me giving a b
Hi guys,
I've done more testing around this and I can now confirm it has nothing to do
with cloudstack code.
I've tested it with rc3, reverted UEFI PR and 4.13.1 (which does not happen to
have the feature at all). Also I've used a matrix of VMware version of 6.0u2,
6.5u2 and 6.7u3.
The bug
Indeed it is severe, but please note it's a corner case which was unearthed
almost by accident. It falls down to using a new feature of selecting a boot
protocol and the template must be corrupted. So with already existing templates
I would not expect to encounter it.
As for recovery, we've ma
On Mon, 18 May 2020, 23:12 Daan Hoogland, wrote:
>
> On Mon, 18 May 2020, 22:01 Marcus, wrote:
>
>> ...
>
>> Does it only affect new templates, or is there a risk that an existing
>> template out in vSphere could suddenly cause problems?
>>
> The boot mode and type are entered at deploy time, s
Hey Marcus, i tried to partially disable it today but it seems I can still
corrupt a system so, I'll create a block for all of the VMware
functionality tomorrow.
On Mon, 18 May 2020, 22:01 Marcus, wrote:
> The issue sounds severe enough that a release note probably won't suffice -
> unless there
The issue sounds severe enough that a release note probably won't suffice -
unless there's a documented way to recover we'd never want to leave a
system susceptible to being unrecoverable, even if it's rarely triggered.
What's involved in "failing gracefully"? Is this a small fix, or an
overhaul?
Hi guys,
A little further info on this, it appears when we use a corrupted template and
UEFI/Legacy mode when deploy a VM, it breaks the connection between cloudstack
and vCenter.
All hosts become unreachable and basically the cluster is not functional, have
not investigated a way to recover
I'll have to -1 RC3, we've discovered details about an issue which is causing
severe consequences with a particular hypervisor in the afternoon. We'll need
more time to investigate before disclosing.
Bobby.
On 15.05.20, 9:12, "Boris Stoyanov" wrote:
+1 (binding)
I've executed
+1 (binding)
involved in many things around this one, overall looking good.
On Fri, 15 May 2020 at 08:13, Boris Stoyanov
wrote:
> +1 (binding)
>
> I've executed upgrade tests with the following configurations:
>
> 4.13.1 with KVM on CentOS7 hosts
> 4.13 with VMware6.5 hosts
> 4.11.3 with KVM on
+1 (binding)
I've executed upgrade tests with the following configurations:
4.13.1 with KVM on CentOS7 hosts
4.13 with VMware6.5 hosts
4.11.3 with KVM on CentOS7 hosts
4.11.2 with XenServer7 hosts
4.11.1 with VMware 6.7
4.9.3 with XenServer 7 hosts
4.9.2 with KVM on CentOS 7 hosts
Also I'
isplay issue
> here. DB entries are all in UTC.
>
> Regards
> Liridon
> ____________
> Von: Andrija Panic
> Gesendet: Montag, 11. Mai 2020 17:11
> An: dev ; users
> Betreff: [VOTE] Apache CloudStack 4.14.0.0 RC3
>
> Hi All,
>
> I've
ja Panic
Gesendet: Montag, 11. Mai 2020 17:11
An: dev ; users
Betreff: [VOTE] Apache CloudStack 4.14.0.0 RC3
Hi All,
I've created a 4.14.0.0 release (RC3), with the following artefacts up for
testing and a vote:
Git Branch and Commit SH:
https://gitbox.apache.org/repos/asf?p=cloudstack.git
+1 (binding)
*Environment configurations:*
- Apache CloudStack: Management server + DB (Ubuntu 18.04)
- Hosts: KVM (Ubuntu 18.04)
- Primary Storage: KVM Local Filesystem, NFS, and Ceph
- Secondary Storage: NFS
- Zone Network: Advanced Network with Security Groups
*Tests:*
- build 4.14.0.0 from so
Hi All,
I've created a 4.14.0.0 release (RC3), with the following artefacts up for
testing and a vote:
Git Branch and Commit SH:
https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200511T1503
Commit: 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e
Source release (
22 matches
Mail list logo
