Multiple Management Servers Support on agents

2021-12-07 Thread benoit lair 
Hello folks,

I am looking after solutions for Ha of mgmt servers
I would like to avoid use of external load balancer

I see this in doc :
https://docs.cloudstack.apache.org/en/4.16.0.0/adminguide/reliability.html#management-server-load-balancing
and in the cwiki it talks about KVM agent :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+Management+Servers+Support+on+agents

Does this mean it does not work with some Xcp-ng servers ?
Xcp-ng can't know which mgmt server must be contacted in case of failure ?

Regards, Benoit

Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

2021-12-07 Thread Gabriel Bräscher 
Paul, I confused the issues then.

The one I mentioned fits only with what Wido reported in this thread.
The CPU flag matches with the ones raised on that bug. Flags like *npt* &
*nrip-save* which are present when SVM is enabled.
Therefore, affected by kernel commit -- 52297436199d ("kvm: svm: Update
svm_xsaves_supported").
Additionally, the OS/Qemu versions also do fit with what is reported on
Ubuntu' qemu package "bug #1887490".

Regards

On Tue, Dec 7, 2021 at 12:10 PM Paul Angus 
wrote:

> The qemu-ev 2.10 bug was first reported a year or two ago in the mailing
> lists.
>
> -Original Message-
> From: Gabriel Bräscher 
> Sent: Tuesday, December 7, 2021 9:41 AM
> To: dev 
> Subject: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04
>
> Just adding to the "qemu-ev 2.10" & "qemu-ev 2.12" point.
>
> > migration fails from qemu-ev 2.10 to qemu-ev 2.12, this is definitely
> > a bug in my point of view.
> >
>
> On the comment 53 (at "bug #1887490"):
>
> > It seems *one of the patches also introduced a regression*:
> > * lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patch
> > adds various SVM-related flags. Specifically *npt and nrip-save are
> > now expected to be present by default* as shown in the updated testdata.
> > This however breaks migration from instances using EPYC or EPYC-IBPB
> > CPU models started with libvirt versions prior to this one because the
> > instance on the target host has these extra flags
>
>
> From the tests reported there, it fails in both ways.
> 1. From *older* qemu package to *newer*:
> *source* host does not map the CPU flag; however, *target* host
> expects the flag to be there, by default.
> 2. From *newer* qemu package to *older*:
> the instance "domain.xml" in the *source* host has a CPU flag that is
> not mapped by qemu in the *target* host.
>
>
>
> On Tue, Dec 7, 2021 at 10:22 AM Sven Vogel  wrote:
>
> > Let me check. We had the same problem on RHEL/CentOS but I am not sure
> > if this a bug. What I know there was a change in the XML. Let me ask
> > one on my colleges in my team.
> >
> > 
> >
> >
> > __
> >
> > Sven Vogel
> > Senior Manager Research and Development - Cloud and Infrastructure
> >
> > EWERK DIGITAL GmbH
> > Brühl 24, D-04109 Leipzig
> > P +49 341 42649 - 99
> > F +49 341 42649 - 98
> > s.vo...@ewerk.com
> > www.ewerk.com
> >
> > Geschäftsführer:
> > Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> > Registergericht: Leipzig HRB 9065
> >
> > Support:
> > +49 341 42649 555
> >
> > Zertifiziert nach:
> > ISO/IEC 27001:2013
> > DIN EN ISO 9001:2015
> > DIN ISO/IEC 2-1:2018
> >
> > ISAE 3402 Typ II Assessed
> >
> > EWERK-Blog | LinkedIn<
> > https://www.linkedin.com/company/ewerk-group> | Xing<
> > https://www.xing.com/company/ewerk> | Twitter<
> > https://twitter.com/EWERK_Group> | Facebook<
> > https://de-de.facebook.com/EWERK.Group/>
> >
> >
> > Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
> >
> > Disclaimer Privacy:
> > Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
> > ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht
> > der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> > Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> > informieren Sie in diesem Fall unverzüglich den Absender und löschen
> > Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
> System.
> > Vielen Dank.
> >
> > The contents of this e-mail (including any attachments) are
> > confidential and may be legally privileged. If you are not the
> > intended recipient of this e-mail, any disclosure, copying,
> > distribution or use of its contents is strictly prohibited, and you
> > should please notify the sender immediately and then delete it
> (including any attachments) from your system. Thank you.
> > Von: Gabriel Bräscher 
> > Datum: Dienstag, 7. Dezember 2021 um 09:57
> > An: dev 
> > Betreff: Re: Live migration between AMD Epyc and Ubuntu 18.04 and
> > 20.04 Wei, I agree.
> > This is not necessarily a bug per se.
> >
> > The main point here is: the issue we are seeing is the "bug #1887490"
> > raised in Ubuntu's qemu package.
> > CPU features were added on the newer releases, which caused the
> > compatibility issue when (live) migrating VMs between compatible
> > hardware but different qemu packages.
> >
> >
> > On Tue, Dec 7, 2021 at 9:26 AM Wei ZHOU  wrote:
> >
> > > Hi Gabriel,
> > >
> > > In my opinion, migration should work from lower version to higher
> > version,
> > > but no guarantee from higher version to lower version, like we
> > > upgrade cloudstack.
> > > Therefore, migrate should work from ubuntu 18.04 to ubuntu 20.04.
> > > But it
> > is
> > > not a bug if migration fails from ubuntu 20.04 to ubuntu 18.04.
> > >
> > > As Paul said, migration fails from qemu-ev 2.10 to qemu-ev 2.12,
> > > this is definitely a bug in my point of view.
> > >
> > > -Wei
> > >
> > > On Mon, 6 Dec 2021

Case Study: IKOULA and Apache CloudStack

2021-12-07 Thread Ivet Petrova 
Hello all,

Hope your winter mood is great :)

I am writing to share a case study our community did with the leading French 
web hosting company IKOULA and XCP-ng.

For the management of their cloud environment, IKOULA decided to choose the 
open-source way by combining the power of CloudStack with the simplicity of the 
open-source hypervisor XCP-ng. Тhe turnkey combination was carefully selected 
following the long-term company strategy to guarantee a constant product 
evolution, reliability and simplicity for their customers. As a result, IKOULA 
is now among the most innovative cloud and managed services providers in 
Europe, with an extensive portfolio of cloud solutions. Moreover, a large 
number of customers use their CloudStack-orchestrated infrastructure to deploy 
memory-oriented and storage-oriented VMs or Kubernetes clusters.

Check the full Case Study here: 
https://blogs.apache.org/cloudstack/entry/case-study-ikoula-xcpng-cloudstack

Some shares on social media will be appreciated:
Twitter: https://twitter.com/CloudStack/status/1468183496724254724
LinkedIn: 
https://www.linkedin.com/feed/update/urn:li:activity:6873944528517169152/


Kind regards,

RE: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

2021-12-07 Thread Paul Angus 
The qemu-ev 2.10 bug was first reported a year or two ago in the mailing lists.

-Original Message-
From: Gabriel Bräscher  
Sent: Tuesday, December 7, 2021 9:41 AM
To: dev 
Subject: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

Just adding to the "qemu-ev 2.10" & "qemu-ev 2.12" point.

> migration fails from qemu-ev 2.10 to qemu-ev 2.12, this is definitely 
> a bug in my point of view.
>

On the comment 53 (at "bug #1887490"):

> It seems *one of the patches also introduced a regression*:
> * lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patch
> adds various SVM-related flags. Specifically *npt and nrip-save are 
> now expected to be present by default* as shown in the updated testdata.
> This however breaks migration from instances using EPYC or EPYC-IBPB 
> CPU models started with libvirt versions prior to this one because the 
> instance on the target host has these extra flags


From the tests reported there, it fails in both ways.
1. From *older* qemu package to *newer*:
*source* host does not map the CPU flag; however, *target* host expects the 
flag to be there, by default.
2. From *newer* qemu package to *older*:
the instance "domain.xml" in the *source* host has a CPU flag that is not 
mapped by qemu in the *target* host.



On Tue, Dec 7, 2021 at 10:22 AM Sven Vogel  wrote:

> Let me check. We had the same problem on RHEL/CentOS but I am not sure 
> if this a bug. What I know there was a change in the XML. Let me ask 
> one on my colleges in my team.
>
> 
>
>
> __
>
> Sven Vogel
> Senior Manager Research and Development - Cloud and Infrastructure
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> s.vo...@ewerk.com
> www.ewerk.com
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 2-1:2018
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog | LinkedIn< 
> https://www.linkedin.com/company/ewerk-group> | Xing< 
> https://www.xing.com/company/ewerk> | Twitter< 
> https://twitter.com/EWERK_Group> | Facebook< 
> https://de-de.facebook.com/EWERK.Group/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) 
> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht 
> der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
> informieren Sie in diesem Fall unverzüglich den Absender und löschen 
> Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are 
> confidential and may be legally privileged. If you are not the 
> intended recipient of this e-mail, any disclosure, copying, 
> distribution or use of its contents is strictly prohibited, and you 
> should please notify the sender immediately and then delete it (including any 
> attachments) from your system. Thank you.
> Von: Gabriel Bräscher 
> Datum: Dienstag, 7. Dezember 2021 um 09:57
> An: dev 
> Betreff: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 
> 20.04 Wei, I agree.
> This is not necessarily a bug per se.
>
> The main point here is: the issue we are seeing is the "bug #1887490"
> raised in Ubuntu's qemu package.
> CPU features were added on the newer releases, which caused the 
> compatibility issue when (live) migrating VMs between compatible 
> hardware but different qemu packages.
>
>
> On Tue, Dec 7, 2021 at 9:26 AM Wei ZHOU  wrote:
>
> > Hi Gabriel,
> >
> > In my opinion, migration should work from lower version to higher
> version,
> > but no guarantee from higher version to lower version, like we 
> > upgrade cloudstack.
> > Therefore, migrate should work from ubuntu 18.04 to ubuntu 20.04. 
> > But it
> is
> > not a bug if migration fails from ubuntu 20.04 to ubuntu 18.04.
> >
> > As Paul said, migration fails from qemu-ev 2.10 to qemu-ev 2.12, 
> > this is definitely a bug in my point of view.
> >
> > -Wei
> >
> > On Mon, 6 Dec 2021 at 16:05, Gabriel Bräscher 
> > wrote:
> >
> > > Hi Paul (& all),
> > >
> > > I strongly believe that this is a bug in QEMU.
> > > I was looking for bugs and found something that looks related to 
> > > what
> we
> > > are seeing. Precisely at Ubuntu's bug #*1887490*
> > > :
> > > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490
> > >
> > > In the link above, there was the following comment:
> > >
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/comments/5
> 3
> > >
> > > It seems one of the patches also introduced a regression:* 
> > > lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patchadds various 
> > > SVM-related

[GitHub] [cloudstack-terraform-provider] harikrishna-patnala closed issue #21: Can't create port forwarding rule

2021-12-07 Thread GitBox 


harikrishna-patnala closed issue #21:
URL: https://github.com/apache/cloudstack-terraform-provider/issues/21


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [cloudstack-terraform-provider] harikrishna-patnala commented on issue #21: Can't create port forwarding rule

2021-12-07 Thread GitBox 


harikrishna-patnala commented on issue #21:
URL: 
https://github.com/apache/cloudstack-terraform-provider/issues/21#issuecomment-987779393


   Closing this issue as the related PR is merged


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [cloudstack-terraform-provider] harikrishna-patnala merged pull request #27: Fix port forwarding to update state only if there are no errors

2021-12-07 Thread GitBox 


harikrishna-patnala merged pull request #27:
URL: https://github.com/apache/cloudstack-terraform-provider/pull/27


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [cloudstack-terraform-provider] harikrishna-patnala commented on pull request #27: Fix port forwarding to update state only if there are no errors

2021-12-07 Thread GitBox 


harikrishna-patnala commented on pull request #27:
URL: 
https://github.com/apache/cloudstack-terraform-provider/pull/27#issuecomment-987778350


   Fixed the indentation. Thanks all.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [cloudstack-terraform-provider] rhtyd commented on pull request #27: Fix port forwarding to update state only if there are no errors

2021-12-07 Thread GitBox 


rhtyd commented on pull request #27:
URL: 
https://github.com/apache/cloudstack-terraform-provider/pull/27#issuecomment-987765073


   @harikrishna-patnala pl fix your editor to run `gofmt` or use tabs


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [cloudstack-terraform-provider] sureshanaparti commented on a change in pull request #27: Fix port forwarding to update state only if there are no errors

2021-12-07 Thread GitBox 


sureshanaparti commented on a change in pull request #27:
URL: 
https://github.com/apache/cloudstack-terraform-provider/pull/27#discussion_r763822209



##
File path: cloudstack/resource_cloudstack_port_forward.go
##
@@ -109,13 +109,12 @@ func resourceCloudStackPortForwardCreate(d 
*schema.ResourceData, meta interface{
forwards := 
resourceCloudStackPortForward().Schema["forward"].ZeroValue().(*schema.Set)
 
err := createPortForwards(d, meta, forwards, nrs)
-
-   // We need to update this first to preserve the correct state
-   d.Set("forward", forwards)
-
-   if err != nil {
+   if err != nil {
return err
}
+
+// We need to update this first to preserve the correct state
+d.Set("forward", forwards)

Review comment:
   seems indentation is missed here




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

2021-12-07 Thread Gabriel Bräscher 
Just adding to the "qemu-ev 2.10" & "qemu-ev 2.12" point.

> migration fails from qemu-ev 2.10 to qemu-ev 2.12, this is definitely a
> bug in my point of view.
>

On the comment 53 (at "bug #1887490"):

> It seems *one of the patches also introduced a regression*:
> * lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patch
> adds various SVM-related flags. Specifically *npt and nrip-save are now
> expected to be present by default* as shown in the updated testdata.
> This however breaks migration from instances using EPYC or EPYC-IBPB CPU
> models started with libvirt versions prior to this one because the instance
> on the target host has these extra flags


>From the tests reported there, it fails in both ways.
1. From *older* qemu package to *newer*:
*source* host does not map the CPU flag; however, *target* host expects
the flag to be there, by default.
2. From *newer* qemu package to *older*:
the instance "domain.xml" in the *source* host has a CPU flag that is
not mapped by qemu in the *target* host.



On Tue, Dec 7, 2021 at 10:22 AM Sven Vogel  wrote:

> Let me check. We had the same problem on RHEL/CentOS but I am not sure if
> this a bug. What I know there was a change in the XML. Let me ask one on my
> colleges in my team.
>
> 
>
>
> __
>
> Sven Vogel
> Senior Manager Research and Development - Cloud and Infrastructure
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> s.vo...@ewerk.com
> www.ewerk.com
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 2-1:2018
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog | LinkedIn<
> https://www.linkedin.com/company/ewerk-group> | Xing<
> https://www.xing.com/company/ewerk> | Twitter<
> https://twitter.com/EWERK_Group> | Facebook<
> https://de-de.facebook.com/EWERK.Group/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are confidential
> and may be legally privileged. If you are not the intended recipient of
> this e-mail, any disclosure, copying, distribution or use of its contents
> is strictly prohibited, and you should please notify the sender immediately
> and then delete it (including any attachments) from your system. Thank you.
> Von: Gabriel Bräscher 
> Datum: Dienstag, 7. Dezember 2021 um 09:57
> An: dev 
> Betreff: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04
> Wei, I agree.
> This is not necessarily a bug per se.
>
> The main point here is: the issue we are seeing is the "bug #1887490"
> raised in Ubuntu's qemu package.
> CPU features were added on the newer releases, which caused the
> compatibility issue when (live) migrating VMs between compatible hardware
> but different qemu packages.
>
>
> On Tue, Dec 7, 2021 at 9:26 AM Wei ZHOU  wrote:
>
> > Hi Gabriel,
> >
> > In my opinion, migration should work from lower version to higher
> version,
> > but no guarantee from higher version to lower version, like we upgrade
> > cloudstack.
> > Therefore, migrate should work from ubuntu 18.04 to ubuntu 20.04. But it
> is
> > not a bug if migration fails from ubuntu 20.04 to ubuntu 18.04.
> >
> > As Paul said, migration fails from qemu-ev 2.10 to qemu-ev 2.12, this is
> > definitely a bug in my point of view.
> >
> > -Wei
> >
> > On Mon, 6 Dec 2021 at 16:05, Gabriel Bräscher 
> > wrote:
> >
> > > Hi Paul (& all),
> > >
> > > I strongly believe that this is a bug in QEMU.
> > > I was looking for bugs and found something that looks related to what
> we
> > > are seeing. Precisely at Ubuntu's bug #*1887490*
> > > :
> > > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490
> > >
> > > In the link above, there was the following comment:
> > >
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/comments/53
> > >
> > > It seems one of the patches also introduced a regression:*
> > > lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patchadds various
> > > SVM-related flags. Specifically npt and nrip-save are now expected to
> be
> > > present by default as shown in the updated testdata.This however breaks
> > > migration from instances using *EPYC* or *EPYC-IBPB* CPU models started
> > > with libvirt versions prior to this one because the instance on the
> >

AW: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

2021-12-07 Thread Sven Vogel 
Let me check. We had the same problem on RHEL/CentOS but I am not sure if this 
a bug. What I know there was a change in the XML. Let me ask one on my colleges 
in my team.




__

Sven Vogel
Senior Manager Research and Development - Cloud and Infrastructure

EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
s.vo...@ewerk.com
www.ewerk.com

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065

Support:
+49 341 42649 555

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2018

ISAE 3402 Typ II Assessed

EWERK-Blog | 
LinkedIn | 
Xing | 
Twitter | 
Facebook


Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist 
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der 
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die 
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.
Von: Gabriel Bräscher 
Datum: Dienstag, 7. Dezember 2021 um 09:57
An: dev 
Betreff: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04
Wei, I agree.
This is not necessarily a bug per se.

The main point here is: the issue we are seeing is the "bug #1887490"
raised in Ubuntu's qemu package.
CPU features were added on the newer releases, which caused the
compatibility issue when (live) migrating VMs between compatible hardware
but different qemu packages.


On Tue, Dec 7, 2021 at 9:26 AM Wei ZHOU  wrote:

> Hi Gabriel,
>
> In my opinion, migration should work from lower version to higher version,
> but no guarantee from higher version to lower version, like we upgrade
> cloudstack.
> Therefore, migrate should work from ubuntu 18.04 to ubuntu 20.04. But it is
> not a bug if migration fails from ubuntu 20.04 to ubuntu 18.04.
>
> As Paul said, migration fails from qemu-ev 2.10 to qemu-ev 2.12, this is
> definitely a bug in my point of view.
>
> -Wei
>
> On Mon, 6 Dec 2021 at 16:05, Gabriel Bräscher 
> wrote:
>
> > Hi Paul (& all),
> >
> > I strongly believe that this is a bug in QEMU.
> > I was looking for bugs and found something that looks related to what we
> > are seeing. Precisely at Ubuntu's bug #*1887490*
> > :
> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490
> >
> > In the link above, there was the following comment:
> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/comments/53
> >
> > It seems one of the patches also introduced a regression:*
> > lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patchadds various
> > SVM-related flags. Specifically npt and nrip-save are now expected to be
> > present by default as shown in the updated testdata.This however breaks
> > migration from instances using *EPYC* or *EPYC-IBPB* CPU models started
> > with libvirt versions prior to this one because the instance on the
> target
> > host has these extra flags
> >
> >
> > More about #*1887490*
> >  can be
> found
> > at the mail
> >
> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5842376.html.
> > We can see that the specific bug was addressed in "linux (5.4.0-49.53)
> > focal".
> >
> > linux (5.4.0-49.53) focal; urgency=medium
> >
> >   * Add/Backport EPYC-v3 and EPYC-Rome CPU model (LP: #1887490)
> > - kvm: svm: Update svm_xsaves_supported
> >
> >
> > Regards,
> > Gabriel.
> >
> > On Fri, Dec 3, 2021 at 10:59 AM Paul Angus 
> > wrote:
> >
> > > Which version(s) of QEMU are you using Wido?
> > >
> > > We've just be upgrading CentOS 7.6 to 7.9
> > > Most 7.6 hosts had qemu-ev 2.10 on it  (the buggy one). 2.12 was on the
> > > new hosts.
> > > We were getting errors complaining that the ibpb CPU feature wasn't
> > > available when migrating to the updated OS hosts (even though identical
> > > hardware).
> > >
> > > Upgrading qemu-ev to 2.12 on the originating host, then stopping and
> > > starting the VMs, then allowed us to migrate.  We couldn't find any
> > > solution that didn't involve stopping and starting the VMs.
> > >
> > > Paul.
> > >
> > > -Original Message-
> > > From: Wido den

[GitHub] [cloudstack-terraform-provider] harikrishna-patnala opened a new pull request #27: Fix port forwarding to update state only if there are no errors

2021-12-07 Thread GitBox 


harikrishna-patnala opened a new pull request #27:
URL: https://github.com/apache/cloudstack-terraform-provider/pull/27


   This PR fixes the issue 
https://github.com/apache/cloudstack-terraform-provider/issues/21, where PF 
state is not updated properly in Terraform.
   
   Verified steps:
   1. Create VM and a new network
   2. Acquire an IP
   3. Create PF rule => successfully created
   4. Make another attempt such that PF rule creation should fail
   5. Retry with correct steps to get succeeded => successfully created
   
   4 and 5 steps are the actual steps which got failed in the issue


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

2021-12-07 Thread Gabriel Bräscher 
Wei, I agree.
This is not necessarily a bug per se.

The main point here is: the issue we are seeing is the "bug #1887490"
raised in Ubuntu's qemu package.
CPU features were added on the newer releases, which caused the
compatibility issue when (live) migrating VMs between compatible hardware
but different qemu packages.


On Tue, Dec 7, 2021 at 9:26 AM Wei ZHOU  wrote:

> Hi Gabriel,
>
> In my opinion, migration should work from lower version to higher version,
> but no guarantee from higher version to lower version, like we upgrade
> cloudstack.
> Therefore, migrate should work from ubuntu 18.04 to ubuntu 20.04. But it is
> not a bug if migration fails from ubuntu 20.04 to ubuntu 18.04.
>
> As Paul said, migration fails from qemu-ev 2.10 to qemu-ev 2.12, this is
> definitely a bug in my point of view.
>
> -Wei
>
> On Mon, 6 Dec 2021 at 16:05, Gabriel Bräscher 
> wrote:
>
> > Hi Paul (& all),
> >
> > I strongly believe that this is a bug in QEMU.
> > I was looking for bugs and found something that looks related to what we
> > are seeing. Precisely at Ubuntu's bug #*1887490*
> > :
> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490
> >
> > In the link above, there was the following comment:
> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/comments/53
> >
> > It seems one of the patches also introduced a regression:*
> > lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patchadds various
> > SVM-related flags. Specifically npt and nrip-save are now expected to be
> > present by default as shown in the updated testdata.This however breaks
> > migration from instances using *EPYC* or *EPYC-IBPB* CPU models started
> > with libvirt versions prior to this one because the instance on the
> target
> > host has these extra flags
> >
> >
> > More about #*1887490*
> >  can be
> found
> > at the mail
> >
> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5842376.html.
> > We can see that the specific bug was addressed in "linux (5.4.0-49.53)
> > focal".
> >
> > linux (5.4.0-49.53) focal; urgency=medium
> >
> >   * Add/Backport EPYC-v3 and EPYC-Rome CPU model (LP: #1887490)
> > - kvm: svm: Update svm_xsaves_supported
> >
> >
> > Regards,
> > Gabriel.
> >
> > On Fri, Dec 3, 2021 at 10:59 AM Paul Angus 
> > wrote:
> >
> > > Which version(s) of QEMU are you using Wido?
> > >
> > > We've just be upgrading CentOS 7.6 to 7.9
> > > Most 7.6 hosts had qemu-ev 2.10 on it  (the buggy one). 2.12 was on the
> > > new hosts.
> > > We were getting errors complaining that the ibpb CPU feature wasn't
> > > available when migrating to the updated OS hosts (even though identical
> > > hardware).
> > >
> > > Upgrading qemu-ev to 2.12 on the originating host, then stopping and
> > > starting the VMs, then allowed us to migrate.  We couldn't find any
> > > solution that didn't involve stopping and starting the VMs.
> > >
> > > Paul.
> > >
> > > -Original Message-
> > > From: Wido den Hollander 
> > > Sent: Monday, November 29, 2021 7:57 AM
> > > To: dev@cloudstack.apache.org; Wei ZHOU 
> > > Subject: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04
> > >
> > >
> > >
> > > On 11/24/21 10:36 PM, Wei ZHOU wrote:
> > > > Hi Wido,
> > > >
> > > > I think it is not good to run an environment with two ubuntu/qemu
> > > versions.
> > > > It always happens that some cpu features are supported in the higher
> > > > version but not supported in the older version.
> > > > From my experience, the migration from older version to higher
> version
> > > > works like a charm, but there were many issues in migration from
> > > > higher version to older version.
> > > >
> > >
> > > I understand. But with a large amount of hosts and working your way
> > > through upgrades you sometimes run into these situations. Therefor it
> > would
> > > be welcome if it works.
> > >
> > > > I do not have a solution for you. I have tried to hack
> > > > /etc/libvirt/hooks/qemu but it didn't work.
> > > > Have you tried with other cpu models like x86_Opteron_G5 ? you can
> > > > find the cpu features of each cpu model in
> /usr/share/libvirt/cpu_map/
> > > >
> > >
> > > I have not tried that yet, but I can see if that works.
> > >
> > > The EPYC-IBPB CPU model is identical on 18.04 and 20.04, but even using
> > > that model we can't seem to migrate as it complains about the 'npt'
> > feature.
> > >
> > > Wido
> > >
> > > > Anyway, even if the vm migration succeeds, you do not know if vm
> works
> > > > fine. I believe the best solution is upgrading all hosts to the same
> > > > OS version.
> > > >
> > > > -Wei
> > > >
> > > > On Tue, 23 Nov 2021 at 16:31, Wido den Hollander 
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'm trying to debug an issue with live migrations between Ubuntu
> > > >> 18.04 and 20.04 machines each with different CPUs:
> > > >>
> > > >> - Ubuntu 18.04 with AMD

Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

2021-12-07 Thread Wei ZHOU 
Hi Gabriel,

In my opinion, migration should work from lower version to higher version,
but no guarantee from higher version to lower version, like we upgrade
cloudstack.
Therefore, migrate should work from ubuntu 18.04 to ubuntu 20.04. But it is
not a bug if migration fails from ubuntu 20.04 to ubuntu 18.04.

As Paul said, migration fails from qemu-ev 2.10 to qemu-ev 2.12, this is
definitely a bug in my point of view.

-Wei

On Mon, 6 Dec 2021 at 16:05, Gabriel Bräscher  wrote:

> Hi Paul (& all),
>
> I strongly believe that this is a bug in QEMU.
> I was looking for bugs and found something that looks related to what we
> are seeing. Precisely at Ubuntu's bug #*1887490*
> :
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490
>
> In the link above, there was the following comment:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/comments/53
>
> It seems one of the patches also introduced a regression:*
> lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patchadds various
> SVM-related flags. Specifically npt and nrip-save are now expected to be
> present by default as shown in the updated testdata.This however breaks
> migration from instances using *EPYC* or *EPYC-IBPB* CPU models started
> with libvirt versions prior to this one because the instance on the target
> host has these extra flags
>
>
> More about #*1887490*
>  can be found
> at the mail
> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5842376.html.
> We can see that the specific bug was addressed in "linux (5.4.0-49.53)
> focal".
>
> linux (5.4.0-49.53) focal; urgency=medium
>
>   * Add/Backport EPYC-v3 and EPYC-Rome CPU model (LP: #1887490)
> - kvm: svm: Update svm_xsaves_supported
>
>
> Regards,
> Gabriel.
>
> On Fri, Dec 3, 2021 at 10:59 AM Paul Angus 
> wrote:
>
> > Which version(s) of QEMU are you using Wido?
> >
> > We've just be upgrading CentOS 7.6 to 7.9
> > Most 7.6 hosts had qemu-ev 2.10 on it  (the buggy one). 2.12 was on the
> > new hosts.
> > We were getting errors complaining that the ibpb CPU feature wasn't
> > available when migrating to the updated OS hosts (even though identical
> > hardware).
> >
> > Upgrading qemu-ev to 2.12 on the originating host, then stopping and
> > starting the VMs, then allowed us to migrate.  We couldn't find any
> > solution that didn't involve stopping and starting the VMs.
> >
> > Paul.
> >
> > -Original Message-
> > From: Wido den Hollander 
> > Sent: Monday, November 29, 2021 7:57 AM
> > To: dev@cloudstack.apache.org; Wei ZHOU 
> > Subject: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04
> >
> >
> >
> > On 11/24/21 10:36 PM, Wei ZHOU wrote:
> > > Hi Wido,
> > >
> > > I think it is not good to run an environment with two ubuntu/qemu
> > versions.
> > > It always happens that some cpu features are supported in the higher
> > > version but not supported in the older version.
> > > From my experience, the migration from older version to higher version
> > > works like a charm, but there were many issues in migration from
> > > higher version to older version.
> > >
> >
> > I understand. But with a large amount of hosts and working your way
> > through upgrades you sometimes run into these situations. Therefor it
> would
> > be welcome if it works.
> >
> > > I do not have a solution for you. I have tried to hack
> > > /etc/libvirt/hooks/qemu but it didn't work.
> > > Have you tried with other cpu models like x86_Opteron_G5 ? you can
> > > find the cpu features of each cpu model in /usr/share/libvirt/cpu_map/
> > >
> >
> > I have not tried that yet, but I can see if that works.
> >
> > The EPYC-IBPB CPU model is identical on 18.04 and 20.04, but even using
> > that model we can't seem to migrate as it complains about the 'npt'
> feature.
> >
> > Wido
> >
> > > Anyway, even if the vm migration succeeds, you do not know if vm works
> > > fine. I believe the best solution is upgrading all hosts to the same
> > > OS version.
> > >
> > > -Wei
> > >
> > > On Tue, 23 Nov 2021 at 16:31, Wido den Hollander 
> wrote:
> > >
> > >> Hi,
> > >>
> > >> I'm trying to debug an issue with live migrations between Ubuntu
> > >> 18.04 and 20.04 machines each with different CPUs:
> > >>
> > >> - Ubuntu 18.04 with AMD Epyc 7552 (Rome)
> > >> - Ubuntu 20.04 with AMD Epyc 7662 (Milan)
> > >>
> > >> We are currently using this setting:
> > >>
> > >> guest.cpu.mode=custom
> > >> guest.cpu.model=EPYC
> > >>
> > >> This does not allow for live migrations:
> > >>
> > >> Ubuntu 20.04 with Epyc 7662 to Ubuntu 18.04 with Epyc 7552 fails
> > >>
> > >> "ExecutionException : org.libvirt.LibvirtException: unsupported
> > >> configuration: unknown CPU feature: npt"
> > >>
> > >> So we tried to define a set of features manually:
> > >>
> > >> guest.cpu.features=3dnowprefetch abm adx aes apic arat avx avx2 bmi1
> > >> bmi2 clflush clflushopt cmov