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

2021-12-10 Thread Marcus
Just for clarity - Wido you mention that you tried using a common CPU model
across the platforms (which presumably doesn't contain npt) but migration
still fails on npt missing. That does seem like a bug of some sort, I would
expect that the the following should work:

* Update cloudstack agent configs to use 'EPYC-IBPB' common identical
model, restart agent
* Stop VM on source host (ubuntu 20.04)
* Start VM on source host (ubuntu 20.04) - at this point you should not
have a feature 'npt' in the XML of the running VM. If you do then there's
something wrong with the EPYC-IBPB or libvirt's interpretation
* Attempt to migrate to destination host (ubuntu 18.04)

Is this process failing? Just want to ensure the source VM was restarted
and does not contain npt in the XML (and also on the resulting qemu command
line), but still the migration complains about missing that feature.

I'm also making an assumption here that /proc/cpuinfo on an Epyc 7552 does
not have npt, but an Epyc 7662 does. Is that correct?

On Tue, Dec 7, 2021 at 6:46 AM Gabriel Bräscher 
wrote:

> 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 

import existing instance from vsphere to cloudstack failed

2021-12-10 Thread haven
Hi devs
  I tried to import existing instance from vsphere to 
cloudstack failed?? this instance use vsphere local storage datastore .already 
enabled localstorage vmware zone and found that localstorage in 
cloudstack, get same error again??Is there any way to import it normally??


ENV:
Version: cloudstack 4.15.2
vsphere:6.5


API:
http://x.x.x.x:8090/client/api/?clusterid=8f5efc66-17a9-4f80-925b-92722a04a501name=localstorageserviceofferingid=a9544da9-cc83-4ed0-9cf5-52e46f9e9361command=importUnmanagedInstancenicnetworklist[0].network=7b0b27c0-7827-4505-9c53-a7969406562bnicnetworklist[0].nic=%E7%BD%91%E7%BB%9C%E9%80%82%E9%85%8D%E5%99%A8%201response=json


Error:
{"queryasyncjobresultresponse":{"accountid":"623017de-4b49-11ec-b1af-52540044e80f","userid":"6232957f-4b49-11ec-b1af-52540044e80f","cmd":"org.apache.cloudstack.api.command.admin.vm.ImportUnmanagedInstanceCmd","jobstatus":2,"jobprocstatus":0,"jobresultcode":530,"jobresulttype":"object","jobresult":{"errorcode":530,"errortext":"Storage
 pool for disk  1(2-2000) with datastore: localsr1 not found in zone ID: 
db959f5f-2b65-435f-8cd7-2efb7d87c3c7"},"created":"2021-12-10T13:10:29+0800","completed":"2021-12-10T13:10:30+0800","jobid":"2ce8de02-8abc-41ef-acd5-2c205b206598"}}

RCE found in log4j library

2021-12-10 Thread Rakesh Venkatesh
Hello users/devs


Recently there was an RCE found in log4j library. Fortunately we are
running on older version and so we are good I guess. But if we plan to
upgrade in future, we need to keep the library version in mind

https://www.lunasec.io/docs/blog/log4j-zero-day/

-- 
Thanks and regards
Rakesh