RE: preventing VM Live migration between Pods

[Gary Dixon]

I have managed to workaround the issue.

I have created a new Role based on the Root Admin role but edited it to not 
allow VM migrations - I can then use the API to move all of our current IT 
admins into a new Root account based on this new role so no internal staff can 
live migrate a VM



Gary Dixon
Senior Technical Consultant
T:  +44 161 537 4990
E:  v...@quadris-support.com
W: www.quadris.co.uk
The information contained in this e-mail from Quadris may be confidential and 
privileged for the private use of the named recipient.  The contents of this 
e-mail may not necessarily represent the official views of Quadris.  If you 
have received this information in error you must not copy, distribute or take 
any action or reliance on its contents.  Please destroy any hard copies and 
delete this message.
-Original Message-
From: K B Shiv Kumar 
Sent: Wednesday, May 17, 2023 9:34 AM
To: users@cloudstack.apache.org
Subject: Re: preventing VM Live migration between Pods

Hi Gary

The other 2 settings as mentioned by Simon should do the trick. We are doing 
the same as a safeguard albeit to a different problem.

Regards,
Shiv
(Sent from mobile device. Please excuse brevity and typos.)

On Wed, 17 May 2023, 12:59 Gary Dixon, 
wrote:

> Hi Si
>
> Unfortunately, we don't seem to have the global setting "
> migrate.vm.across.clusters" on our ACS version - 4.15.2
>
>
> Gary Dixon​
> Senior Technical Consultant
> T:  +44 161 537 4990
> E:  *v* <+44%207989717661>ms@quadris‑support.com
> W:
> http://www.q/
> uadris.co.uk%2F&data=05%7C01%7CGary.Dixon%40quadris.co.uk%7Cd3fc66be2e
> 9b4299f48008db56b17ba2%7Cf1d6abf3d3b44894ae16db0fb93a96a2%7C0%7C0%7C63
> 8199092509051713%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D9uPO1Cu2Q
> 9Z58jQ55x1gjdBc9CB9331mb1uX0gjHqQ%3D&reserved=0
> The information contained in this e-mail from Quadris may be
> confidential and privileged for the private use of the named
> recipient.  The contents of this e-mail may not necessarily represent the 
> official views of Quadris.
> If you have received this information in error you must not copy,
> distribute or take any action or reliance on its contents.  Please
> destroy any hard copies and delete this message.
> -Original Message-
> From: Simon Weller 
> Sent: Tuesday, May 16, 2023 4:12 PM
> To: users@cloudstack.apache.org
> Subject: Re: preventing VM Live migration between Pods
>
> Gary,
>
> There are some global settings you can enable/disable to prevent
> certain VM (and storage) movements.
>
> migrate.vm.across.clusters - indicates whether the VM can be migrated
> to different cluster if no host is found in same cluster
> enable.storage.migration - Enable/disable storage migration across
> primary storage enable.ha.storage.migration - Enable/disable storage
> migration across primary storage during HA
>
> -Si
>
> On Tue, May 16, 2023 at 8:13 AM Gary Dixon
> 
> wrote:
>
> > Hi everyone
> >
> >
> >
> > Other than disabling a Pod – is there a way to prevent live
> > migration of VM’s between Pods in ACS ?
> >
> >
> >
> > We are on version 4.15.2 with Ubuntu 20.04 KVM hosts. Each Pod
> > contains a single cluster of Homogenous hosts – however there are
> > only slight differences between the CPU’s on the physical hosts in
> > each Cluster. We have the guest.cpu.mode set to host-passthrough but
> > have noticed serious issues when a VM is live migrated between
> > specific Pods (usually if a VM is started on a cluster with the
> > slightly better CPU’s and then live migrated to an older Pod)
> >
> >
> >
> > We have tried setting the guest.cpu.mode to host-passthrough with
> > specific CPU features using the “guest.cpu.features=” and then
> > setting all of the host’s CPU flags shown from the output of the
> > lscpu command in a space separated list as instructed from ACS
> > documentation – but we then are unable to even start a VM –
> > insufficient resources error,
> > - if we remove the guest.cpu.features from the agent.properties –
> > then we can start a VM again.
> >
> >
> >
> > It would be good if we had an option or a setting to just not allow
> > live migration of VM’s between pods and therefore can only perform a
> ‘cold’
> > migration if we wish to move a VM to another Pod.
> >
> >
> >
> > Any thoughts on this ?
> >
> >
> >
> > BR
> >
> >
> >
> > Gary
> >
> >
> >
> >
> > Gary Dixon​
> > Senior Technical Consultant
> > T: +44 161 537 4990
> > E: *v* <+44%207989717661>ms@quadris‑support.com
> > W:
> > http://www/
> > .q%2F&data=05%7C01%7CGary.Dixon%40quadris.co.uk%7Cd3fc66be2e9b4299f4
> > 8008db56b17ba2%7Cf1d6abf3d3b44894ae16db0fb93a96a2%7C0%7C0%7C63819909
> > 2509051713%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y8dHYylV%2B9
> > DNtZl8OcX7ogolxTWG%2F%2B0gJuakNmtNjI4%3D&reserved=0
> > uadris.co.uk%2F&data=05%7C01%7CGary.Dixon%40quadris.co.uk%7Cf8331db3
> > 95
> > 984949ba8d08db

Re: [VOTE] Upgrade Log4j to Log4j2

[Rodrigo D. Lopez]

Thanks for the great work!

Based on discussions in PR and the discussion thread[1]. My vote is +1.

Log4j v1 (deprecated) and its current alternative reload4j in use in ACS
are not ideal for the long run. Therefore, for the future of ACS, and to
enable us to keep evolving, the upgrade is most welcome.

Regards,
Rodrigo Lopez

[1]  https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2

Em qua., 17 de mai. de 2023 às 09:41, Daan Hoogland 
escreveu:

> -0
>
> Joao, Daniel reacted negatively to my question to create a proxy with bad
> arguments and I had no time to respond yet. I think not adding a proxy at
> this time is a missed opportunity and I would full heartedly +1 if we had.
> Not creating a proxy class (with or without configurability) is a waste of
> your effort.
> All the standardisation of calls is very useful irrespective.
>
> On Tue, May 16, 2023 at 8:45 PM Daniel Salvador 
> wrote:
>
> > Hello, João
> >
> > Considering the discussion we had in the thread[1] and that the conflicts
> > will be mostly regarding loggers names (which is simple to fix), I am +1
> on
> > the proposal.
> >
> > Best regards,
> > Daniel Salvador (gutoveronezi)
> >
> > [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
> >
> > On Tue, May 16, 2023 at 1:28 PM João Jandre Paraquetti <
> > j...@scclouds.com.br>
> > wrote:
> >
> > > Hello guys,
> > >
> > > I am opening this voting thread as result of the discussion in thread
> > > "ACS upgrade to Log4J2 version 2.19"[1].
> > >
> > > The voting aims to continue the efforts and conclude the upgrade of the
> > > ACS logging library to Log4j2 through PR 7131[2]; merge the PR as soon
> > > as possible and provide ways to contributors solve the conflicts
> easily,
> > > so all the contributors have time to fix their merge conflicts before
> > > 4.19; announce that change in the release notes and provide ways to
> > > users upgrade their customization made to the default log4j
> > > configuration files.
> > >
> > > For sanity in tallying the vote, can PMC members please be sure to
> > indicate
> > > "(binding)" with their vote?
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove (and reason why)
> > >
> > > Best regards,
> > > João Jandre (JoaoJandre)
> > >
> > > [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
> > > [2] https://github.com/apache/cloudstack/pull/7131
> > >
> > >
> >
>
>
> --
> Daan
>

RE: VMWare dvSwitch - import port groups to Cloudstack

[Alex Mattioli]

That's correct, the networks need to be created in CloudStack first.

 


-Original Message-
From: Jafar Aghabalayev  
Sent: Wednesday, May 17, 2023 12:53 PM
To: users@cloudstack.apache.org
Subject: RE: VMWare dvSwitch - import port groups to Cloudstack

Hello Rohit,

Thank you for prompt response.

>From the documentation and articles I found -  " It also requires CloudStack 
>networks to be created for existing networks from vCenter. "

Am I correct understand that the only way is create networks from CloudStack UI 
and no way to import networks?

Appreciate your efforts.

Best Regards,

Jafar Aghabalayev

-Original Message-
From: Rohit Yadav 
Sent: Wednesday, May 17, 2023 3:27 PM
To: users@cloudstack.apache.org
Subject: Re: VMWare dvSwitch - import port groups to Cloudstack

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. Please report all suspicious emails to s...@pasha-technology.com.

Hi Jafar,

You can refer further here:

https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines.html#importing-and-unmanaging-virtual-machines
https://www.youtube.com/watch?v=EfAXyAF1wwM
https://www.shapeblue.com/new-feature-first-look-vm-ingestion/


Regards.


From: Jafar Aghabalayev 
Sent: Wednesday, May 17, 2023 16:31
To: users@cloudstack.apache.org 
Subject: VMWare dvSwitch - import port groups to Cloudstack

Hello Community,

I have VMWare vCenter with number of VMs and Portgroups (dvSwitch).

I want to import all portgroups to cloudstack and used them for imported 
instances. Is it possible to import networks (portgroups) from vCenter to 
cloudstack?

I couldn't find any information related to importing networks from vCenter to 
cloudstack.

Thanks.

Best regards,

Jafar Aghabalayev

Re: ACS upgrade to Log4J2 version 2.19

[Daan Hoogland]

Daniel, comparing a dependency injection framework (or any larger
framework) with a utility for something like logging is a false one. such a
framework is implying design to a large part. The most complicated aspect
of logging is its cross-cutting quality. I see this as a non-discussion and
we should always create proxies for any libraries that can be proxied in
order to reduce surface area in case we need to replace them.

As for merge criteria: testing is the only thing missing I think. Again,
this is not a missed opportunity, but then we can do that as a second step.

On Thu, May 11, 2023 at 2:14 AM Daniel Salvador 
wrote:

> Daan,
>
> IMHO, proxying libraries would bring us more disadvantages than benefits.
> If we define that the standard is to proxy libraries such as Utils, Log4J,
> and others, we would have to proxy all of them (even Spring); it would
> require a huge effort (way more than this work with Log4j) to introduce and
> maintain those proxies. Also, ACS already is a complex system to work;
> proxying libraries would add one more layer of complexity to the platform
> (and one more point of failure); thus, making it difficult for new
> contributors to join the community.
>
> The community already put a lot of effort into the Log4J2 upgrade. The PR
> being discussed in this thread is ready for merge (besides the conflicts
> that the author is resolving as soon as they appear), it has been tested
> (it could benefit from more testing though) with a variety of setups and
> use cases, and the impact on conflicts is minimal (giving its size and
> nature); therefore, along with what I pointed out, I do not think proxying
> libraries would be a good approach.
>
> Furthermore, to conclude. If the community seems to count on support of
> both users and other devs, and we have already done quite an extensive test
> round, what else are we missing to move along with that PR? Is any of the
> merging criteria missing to move on with it?
>
> Best regards,
> Daniel Salvador (gutoveronezi)
>
> On Tue, May 9, 2023 at 1:52 PM Daan Hoogland 
> wrote:
>
> > Rohit, Daniel,
> >
> > Let me weigh in a bit. I held back about this as I have discussed this in
> > the past a lot in different settings and do not want to take sides. My
> > personal motivation for either reload4j or log4j2 are slim but I can see
> > that people might want to lean to either. For this reason I want to bring
> > up another pet preference of mine:
> >
> > I think we should proxy each and every external library we use with our
> own
> > packages. This means not even using something like slf4j but implement
> our
> > own framework and let people choose either on package or on deploytime
> what
> > to use, with a reasonable default of course.
> > At the moment I would lean towards log4j2 as the default but I do not
> want
> > my clients to have to use that as I know some of them will blame me for
> > extra night shifts if we do.
> >
> > This pet preference is valid for more than logging but is very applicable
> > on the subject.
> >
> > This will require some extra effort, so feel free to push back but I
> think
> > it will be worth it.
> >
> > that all said the standardisation of the calling side of things is going
> to
> > be a pain but should be done as well. (imnsho)
> >
> > regards,
> >
> >
> > On Sat, May 6, 2023 at 3:31 AM Daniel Salvador 
> > wrote:
> >
> > > Thanks, Rohit for the reply
> > >
> > > Not only the author, but me and other colleagues from the community can
> > > build DEB and RPM packages (commands [1] and [2]). We already did, and
> > the
> > > process to build RPM and DEB works just fine.
> > >
> > > Also, basic CloudStack installation, setup and zone deployment, VM and
> > > volume lifecycles with KVM and VMware, and so on, have already been
> > tested
> > > and that was reported on the PR and this thread. The problem here is
> that
> > > blueorangutan is failing and it is a black box; therefore, the author
> > does
> > > not know what is happening inside it.
> > >
> > > The conflicts that might happen in other PRs is mostly renaming the
> > > loggers, which the fixes can be easily automated via scripts. For the
> > > efforts on the release management, I am pretty sure some colleagues
> from
> > > the community would be glad to help as well.
> > >
> > > We understand the process and everybody seems to agree on this step
> > > forward; is there any technical reason not to? Anyone else have
> thoughts
> > on
> > > this?
> > >
> > > Best regards,
> > > Daniel Salvador (gutoveronezi)
> > >
> > > [1] docker run -v /tmp:/mnt/build -v ~/.m2:/root/.m2 -e "USER_ID=$(id
> > -u)"
> > > -e "USER_GID=$(id -g)" -e "ACS_BUILD_OPTS=-Dnoredist"
> > > scclouds/cloudstack-deb-builder:ubuntu2004-jdk11-python3 --git-remote
> > > https://github.com/apache/cloudstack.git --git-ref refs/pull/7131/head
> > > [2] docker run -v /tmp:/mnt/build -v ~/.m2:/root/.m2 -e "USER_ID=$(id
> > -u)"
> > > -e "USER_GID=$(id -g)"  scclouds/cloudstack-rpm-builder

Re: [VOTE] Upgrade Log4j to Log4j2

[Daan Hoogland]

-0

Joao, Daniel reacted negatively to my question to create a proxy with bad
arguments and I had no time to respond yet. I think not adding a proxy at
this time is a missed opportunity and I would full heartedly +1 if we had.
Not creating a proxy class (with or without configurability) is a waste of
your effort.
All the standardisation of calls is very useful irrespective.

On Tue, May 16, 2023 at 8:45 PM Daniel Salvador 
wrote:

> Hello, João
>
> Considering the discussion we had in the thread[1] and that the conflicts
> will be mostly regarding loggers names (which is simple to fix), I am +1 on
> the proposal.
>
> Best regards,
> Daniel Salvador (gutoveronezi)
>
> [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
>
> On Tue, May 16, 2023 at 1:28 PM João Jandre Paraquetti <
> j...@scclouds.com.br>
> wrote:
>
> > Hello guys,
> >
> > I am opening this voting thread as result of the discussion in thread
> > "ACS upgrade to Log4J2 version 2.19"[1].
> >
> > The voting aims to continue the efforts and conclude the upgrade of the
> > ACS logging library to Log4j2 through PR 7131[2]; merge the PR as soon
> > as possible and provide ways to contributors solve the conflicts easily,
> > so all the contributors have time to fix their merge conflicts before
> > 4.19; announce that change in the release notes and provide ways to
> > users upgrade their customization made to the default log4j
> > configuration files.
> >
> > For sanity in tallying the vote, can PMC members please be sure to
> indicate
> > "(binding)" with their vote?
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Best regards,
> > João Jandre (JoaoJandre)
> >
> > [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
> > [2] https://github.com/apache/cloudstack/pull/7131
> >
> >
>


-- 
Daan

RE: VMWare dvSwitch - import port groups to Cloudstack

[Jafar Aghabalayev]

Hello Rohit,

Thank you for prompt response.

>From the documentation and articles I found -  " It also requires CloudStack 
>networks to be created for existing networks from vCenter. "

Am I correct understand that the only way is create networks from CloudStack UI 
and no way to import networks?

Appreciate your efforts.

Best Regards,

Jafar Aghabalayev

-Original Message-
From: Rohit Yadav 
Sent: Wednesday, May 17, 2023 3:27 PM
To: users@cloudstack.apache.org
Subject: Re: VMWare dvSwitch - import port groups to Cloudstack

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. Please report all suspicious emails to s...@pasha-technology.com.

Hi Jafar,

You can refer further here:

https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines.html#importing-and-unmanaging-virtual-machines
https://www.youtube.com/watch?v=EfAXyAF1wwM
https://www.shapeblue.com/new-feature-first-look-vm-ingestion/


Regards.


From: Jafar Aghabalayev 
Sent: Wednesday, May 17, 2023 16:31
To: users@cloudstack.apache.org 
Subject: VMWare dvSwitch - import port groups to Cloudstack

Hello Community,

I have VMWare vCenter with number of VMs and Portgroups (dvSwitch).

I want to import all portgroups to cloudstack and used them for imported 
instances. Is it possible to import networks (portgroups) from vCenter to 
cloudstack?

I couldn't find any information related to importing networks from vCenter to 
cloudstack.

Thanks.

Best regards,

Jafar Aghabalayev

Re: VMWare dvSwitch - import port groups to Cloudstack

[Rohit Yadav]

Hi Jafar,

You can refer further here:

https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines.html#importing-and-unmanaging-virtual-machines
https://www.youtube.com/watch?v=EfAXyAF1wwM
https://www.shapeblue.com/new-feature-first-look-vm-ingestion/


Regards.


From: Jafar Aghabalayev 
Sent: Wednesday, May 17, 2023 16:31
To: users@cloudstack.apache.org 
Subject: VMWare dvSwitch - import port groups to Cloudstack

Hello Community,

I have VMWare vCenter with number of VMs and Portgroups (dvSwitch).

I want to import all portgroups to cloudstack and used them for imported 
instances. Is it possible to import networks (portgroups) from vCenter to 
cloudstack?

I couldn't find any information related to importing networks from vCenter to 
cloudstack.

Thanks.

Best regards,

Jafar Aghabalayev

 

Re: [VOTE] CloudStack Project Blog Migration

[Ivet Petrova]

+1 from me

Sent from my iPhone


 

> On 17 May 2023, at 9:58, Rohit Yadav  wrote:
> 
> All,
> 
> The ASF-infra had announced a hard deadline [0][1] to decommission our
> project’s Roller based blog [3] on the 31st May 2023.
> 
> For the blog migration, ASF-infra has exported CloudStack blog posts
> from the current Roller’s database-backed infra to markdown files.
> These were put together in cloudstack-www repository’s
> docusauras-staging branch [2] with Docusauras used as a
> static-site-generator and a GitHub Actions workflow to automate
> publishing a staging site for your testing and review [4].
> 
> The staging site that migrates both the website and blog isn’t
> completely ready to meet the hard deadline, so this vote is proposed
> for only migrating the blog before the deadline and continue efforts
> to migrate to a new website [2][4] when we're ready in the near
> future.
> 
> The following is put for voting:
> 
> 1. By the end of 31st May ’23, ASF-infra will decommission the project
> blog at https://blogs.apache.org/cloudstack and for now we proceed
> with only the blog migration before this deadline.
> 
> 2. The old blog URL/pages from
> https://blogs.apache.org/cloudstack/ will be
> redirected to https://cloudstack.apache.org/blog/.
> This will be done by the ASF-infra.
> 
> 3. The blog content is copied to the "content/blog" directory of the
> asf-site branch in the https://github.com/apache/cloudstack-www
> repository [6], published at https://cloudstack.apache.org/blog/.
> 
> The vote will be open until we reach a lazy consensus.
> 
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and the reason why)
> 
> [0] https://markmail.org/message/o5pse33cgriebsrg
> [1] https://lists.apache.org/thread/hfhzochhmqhd32tclgc47d5nk90jxmb2
> [2] https://github.com/apache/cloudstack-www/tree/docusaurus-staging/blog
> [3] https://blogs.apache.org/cloudstack/
> [4] https://cloudstack.staged.apache.org/
> [5] https://cloudstack.apache.org/bylaws.html
> [6] 
> https://github.com/apache/cloudstack-www/commit/651ec3ad9a3f524a5ce1bb9d6943856f57e638e3
> 
> Regards.

Re: [VOTE] Upgrade Log4j to Log4j2

[Felipe Rossi]

+1 approve


Att / Regards

Felipe Rossi | BRASCLOUD
*CEO - Founder*
*Email:* fel...@brascloud.com.br | www.brascloud.com.br
Contact + 55 45 99116-0094 / +55 45 3326-4568

[image: Mailtrack]

Sender
notified by
Mailtrack

05/17/23,
08:02:14 AM

On Tue, May 16, 2023 at 3:45 PM Daniel Salvador 
wrote:

> Hello, João
>
> Considering the discussion we had in the thread[1] and that the conflicts
> will be mostly regarding loggers names (which is simple to fix), I am +1 on
> the proposal.
>
> Best regards,
> Daniel Salvador (gutoveronezi)
>
> [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
>
> On Tue, May 16, 2023 at 1:28 PM João Jandre Paraquetti <
> j...@scclouds.com.br>
> wrote:
>
> > Hello guys,
> >
> > I am opening this voting thread as result of the discussion in thread
> > "ACS upgrade to Log4J2 version 2.19"[1].
> >
> > The voting aims to continue the efforts and conclude the upgrade of the
> > ACS logging library to Log4j2 through PR 7131[2]; merge the PR as soon
> > as possible and provide ways to contributors solve the conflicts easily,
> > so all the contributors have time to fix their merge conflicts before
> > 4.19; announce that change in the release notes and provide ways to
> > users upgrade their customization made to the default log4j
> > configuration files.
> >
> > For sanity in tallying the vote, can PMC members please be sure to
> indicate
> > "(binding)" with their vote?
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Best regards,
> > João Jandre (JoaoJandre)
> >
> > [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
> > [2] https://github.com/apache/cloudstack/pull/7131
> >
> >
>

VMWare dvSwitch - import port groups to Cloudstack

[Jafar Aghabalayev]

Hello Community,

I have VMWare vCenter with number of VMs and Portgroups (dvSwitch).

I want to import all portgroups to cloudstack and used them for imported 
instances. Is it possible to import networks (portgroups) from vCenter to 
cloudstack?

I couldn't find any information related to importing networks from vCenter to 
cloudstack.

Thanks.

Best regards,

Jafar Aghabalayev

[VOTE] CloudStack Project Blog Migration

[Rohit Yadav]

All,

The ASF-infra had announced a hard deadline [0][1] to decommission our
project’s Roller based blog [3] on the 31st May 2023.

For the blog migration, ASF-infra has exported CloudStack blog posts
from the current Roller’s database-backed infra to markdown files.
These were put together in cloudstack-www repository’s
docusauras-staging branch [2] with Docusauras used as a
static-site-generator and a GitHub Actions workflow to automate
publishing a staging site for your testing and review [4].

The staging site that migrates both the website and blog isn’t
completely ready to meet the hard deadline, so this vote is proposed
for only migrating the blog before the deadline and continue efforts
to migrate to a new website [2][4] when we're ready in the near
future.

The following is put for voting:

1. By the end of 31st May ’23, ASF-infra will decommission the project
blog at https://blogs.apache.org/cloudstack and for now we proceed
with only the blog migration before this deadline.

2. The old blog URL/pages from
https://blogs.apache.org/cloudstack/ will be
redirected to https://cloudstack.apache.org/blog/.
This will be done by the ASF-infra.

3. The blog content is copied to the "content/blog" directory of the
asf-site branch in the https://github.com/apache/cloudstack-www
repository [6], published at https://cloudstack.apache.org/blog/.

The vote will be open until we reach a lazy consensus.

For sanity in tallying the vote, can PMC members please be sure to
indicate "(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and the reason why)

[0] https://markmail.org/message/o5pse33cgriebsrg
[1] https://lists.apache.org/thread/hfhzochhmqhd32tclgc47d5nk90jxmb2
[2] https://github.com/apache/cloudstack-www/tree/docusaurus-staging/blog
[3] https://blogs.apache.org/cloudstack/
[4] https://cloudstack.staged.apache.org/
[5] https://cloudstack.apache.org/bylaws.html
[6] 
https://github.com/apache/cloudstack-www/commit/651ec3ad9a3f524a5ce1bb9d6943856f57e638e3

Regards.

Re: preventing VM Live migration between Pods

[K B Shiv Kumar]

Hi Gary

The other 2 settings as mentioned by Simon should do the trick. We are
doing the same as a safeguard albeit to a different problem.

Regards,
Shiv
(Sent from mobile device. Please excuse brevity and typos.)

On Wed, 17 May 2023, 12:59 Gary Dixon, 
wrote:

> Hi Si
>
> Unfortunately, we don't seem to have the global setting "
> migrate.vm.across.clusters" on our ACS version - 4.15.2
>
>
> Gary Dixon​
> Senior Technical Consultant
> T:  +44 161 537 4990
> E:  *v* <+44%207989717661>ms@quadris‑support.com
> W: www.quadris.co.uk
> The information contained in this e-mail from Quadris may be confidential
> and privileged for the private use of the named recipient.  The contents of
> this e-mail may not necessarily represent the official views of Quadris.
> If you have received this information in error you must not copy,
> distribute or take any action or reliance on its contents.  Please destroy
> any hard copies and delete this message.
> -Original Message-
> From: Simon Weller 
> Sent: Tuesday, May 16, 2023 4:12 PM
> To: users@cloudstack.apache.org
> Subject: Re: preventing VM Live migration between Pods
>
> Gary,
>
> There are some global settings you can enable/disable to prevent certain
> VM (and storage) movements.
>
> migrate.vm.across.clusters - indicates whether the VM can be migrated to
> different cluster if no host is found in same cluster
> enable.storage.migration - Enable/disable storage migration across primary
> storage enable.ha.storage.migration - Enable/disable storage migration
> across primary storage during HA
>
> -Si
>
> On Tue, May 16, 2023 at 8:13 AM Gary Dixon
> 
> wrote:
>
> > Hi everyone
> >
> >
> >
> > Other than disabling a Pod – is there a way to prevent live migration
> > of VM’s between Pods in ACS ?
> >
> >
> >
> > We are on version 4.15.2 with Ubuntu 20.04 KVM hosts. Each Pod
> > contains a single cluster of Homogenous hosts – however there are only
> > slight differences between the CPU’s on the physical hosts in each
> > Cluster. We have the guest.cpu.mode set to host-passthrough but have
> > noticed serious issues when a VM is live migrated between specific
> > Pods (usually if a VM is started on a cluster with the slightly better
> > CPU’s and then live migrated to an older Pod)
> >
> >
> >
> > We have tried setting the guest.cpu.mode to host-passthrough with
> > specific CPU features using the “guest.cpu.features=” and then setting
> > all of the host’s CPU flags shown from the output of the lscpu command
> > in a space separated list as instructed from ACS documentation – but
> > we then are unable to even start a VM – insufficient resources error,
> > - if we remove the guest.cpu.features from the agent.properties – then
> > we can start a VM again.
> >
> >
> >
> > It would be good if we had an option or a setting to just not allow
> > live migration of VM’s between pods and therefore can only perform a
> ‘cold’
> > migration if we wish to move a VM to another Pod.
> >
> >
> >
> > Any thoughts on this ?
> >
> >
> >
> > BR
> >
> >
> >
> > Gary
> >
> >
> >
> >
> > Gary Dixon​
> > Senior Technical Consultant
> > T: +44 161 537 4990
> > E: *v* <+44%207989717661>ms@quadris‑support.com
> > W:
> > http://www.q/
> > uadris.co.uk%2F&data=05%7C01%7CGary.Dixon%40quadris.co.uk%7Cf8331db395
> > 984949ba8d08db562012bb%7Cf1d6abf3d3b44894ae16db0fb93a96a2%7C0%7C0%7C63
> > 8198467982509544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h%2BigV6hV
> > qgBCI9uXH9E6WkaOmeN9Ks%2BLZ6d4Fga9ekM%3D&reserved=0
> > The information contained in this e-mail from Quadris may be
> > confidential and privileged for the private use of the named
> > recipient. The contents of this e-mail may not necessarily represent the
> official views of Quadris.
> > If you have received this information in error you must not copy,
> > distribute or take any action or reliance on its contents. Please
> > destroy any hard copies and delete this message.
> >
>

-- 
This message is intended only for the use of the individual or entity to 
which it is addressed and may contain confidential and/or privileged 
information. If you are not the intended recipient, please delete the 
original message and any copy of it from your computer system. You are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited unless proper authorization has been 
obtained for such action. If you have received this communication in error, 
please notify the sender immediately. Although IndiQus attempts to sweep 
e-mail and attachments for viruses, it does not guarantee that both are 
virus-free and accepts no liability for any damage sustained as a result of 
viruses.

Re: Managing Security bewteen account in Advanced Zone without SG

[Pratik Chandrakar]

Hi  Loges,
Thanks for the update.

On Wed, May 17, 2023 at 12:59 PM Logeswaran T
 wrote:

> Hi Pratik,
>
> We now have a request open in cloudstack github for a VPC ACL issue.
>
> https://github.com/apache/cloudstack/issues/7483
>
> The changes are tracked in this thread.
>
> Regards,
> Loges
> www.stackbill.com
>
> On Wed, May 17, 2023 at 11:28 AM Pratik Chandrakar <
> chandrakarpra...@gmail.com> wrote:
>
> > Hi all,
> > Curious to know how others are managing isolation between VMs of
> different
> > accounts in the Advanced Zone without SG deployment, as most users opt
> for
> > default_allow policy for their VPC. Because of default_allow policy all
> > ports are opened between public ip (static nat) irrespective of VLAN used
> > in VPC. Is there any option to remove default_allow policy for VPC so
> that
> > it can't be selected or any other method available?
> > Please advise
> >
> > --
> > *Regards,*
> > *Pratik Chandrakar*
> >
>
> --
>
>
>
>
> *This E-mail is confidential. It may also be legally privileged. If you
> are not the addressee you may not copy, forward, disclose or use any part
> of
> it. If you have received this message in error, please delete it and all
> copies
> from your system and notify the sender immediately by return E-mail.
> Internet
> communications cannot be guaranteed to be timely, secure, error or
> virus-free.
> The sender does not accept liability for any errors or
> omissions*
>


-- 
*Regards,*
*Pratik Chandrakar*

Re: Managing Security bewteen account in Advanced Zone without SG

[Logeswaran T]

Hi Pratik,

We now have a request open in cloudstack github for a VPC ACL issue.

https://github.com/apache/cloudstack/issues/7483

The changes are tracked in this thread.

Regards,
Loges
www.stackbill.com

On Wed, May 17, 2023 at 11:28 AM Pratik Chandrakar <
chandrakarpra...@gmail.com> wrote:

> Hi all,
> Curious to know how others are managing isolation between VMs of different
> accounts in the Advanced Zone without SG deployment, as most users opt for
> default_allow policy for their VPC. Because of default_allow policy all
> ports are opened between public ip (static nat) irrespective of VLAN used
> in VPC. Is there any option to remove default_allow policy for VPC so that
> it can't be selected or any other method available?
> Please advise
>
> --
> *Regards,*
> *Pratik Chandrakar*
>

-- 




*This E-mail is confidential. It may also be legally privileged. If you
are not the addressee you may not copy, forward, disclose or use any part 
of
it. If you have received this message in error, please delete it and all 
copies
from your system and notify the sender immediately by return E-mail. 
Internet
communications cannot be guaranteed to be timely, secure, error or 
virus-free.
The sender does not accept liability for any errors or 
omissions*

RE: preventing VM Live migration between Pods

[Gary Dixon]

Hi Si

Unfortunately, we don't seem to have the global setting " 
migrate.vm.across.clusters" on our ACS version - 4.15.2



Gary Dixon
Senior Technical Consultant
T:  +44 161 537 4990
E:  v...@quadris-support.com
W: www.quadris.co.uk
The information contained in this e-mail from Quadris may be confidential and 
privileged for the private use of the named recipient.  The contents of this 
e-mail may not necessarily represent the official views of Quadris.  If you 
have received this information in error you must not copy, distribute or take 
any action or reliance on its contents.  Please destroy any hard copies and 
delete this message.
-Original Message-
From: Simon Weller 
Sent: Tuesday, May 16, 2023 4:12 PM
To: users@cloudstack.apache.org
Subject: Re: preventing VM Live migration between Pods

Gary,

There are some global settings you can enable/disable to prevent certain VM 
(and storage) movements.

migrate.vm.across.clusters - indicates whether the VM can be migrated to 
different cluster if no host is found in same cluster enable.storage.migration 
- Enable/disable storage migration across primary storage 
enable.ha.storage.migration - Enable/disable storage migration across primary 
storage during HA

-Si

On Tue, May 16, 2023 at 8:13 AM Gary Dixon 
wrote:

> Hi everyone
>
>
>
> Other than disabling a Pod – is there a way to prevent live migration
> of VM’s between Pods in ACS ?
>
>
>
> We are on version 4.15.2 with Ubuntu 20.04 KVM hosts.  Each Pod
> contains a single cluster of Homogenous hosts – however there are only
> slight differences between the CPU’s on the physical hosts in each
> Cluster. We have the guest.cpu.mode set to host-passthrough but have
> noticed serious issues when a VM is live migrated between specific
> Pods (usually if a VM is started on a cluster with the slightly better
> CPU’s and then live migrated to an older Pod)
>
>
>
> We have tried setting the guest.cpu.mode to host-passthrough with
> specific CPU features using the “guest.cpu.features=” and then setting
> all of the host’s CPU flags shown from the output of the lscpu command
> in a space separated list as instructed from ACS documentation – but
> we then are unable to even start a VM – insufficient resources error,
> - if we remove the guest.cpu.features from the agent.properties – then
> we can start a VM again.
>
>
>
> It would be good if we had an option or a setting to just not allow
> live migration of VM’s between pods and therefore can only perform a ‘cold’
> migration if we wish to move a VM to another Pod.
>
>
>
> Any thoughts on this ?
>
>
>
> BR
>
>
>
> Gary
>
>
>
>
> Gary Dixon​
> Senior Technical Consultant
> T:  +44 161 537 4990
> E:  *v* <+44%207989717661>ms@quadris‑support.com
> W:
> http://www.q/
> uadris.co.uk%2F&data=05%7C01%7CGary.Dixon%40quadris.co.uk%7Cf8331db395
> 984949ba8d08db562012bb%7Cf1d6abf3d3b44894ae16db0fb93a96a2%7C0%7C0%7C63
> 8198467982509544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h%2BigV6hV
> qgBCI9uXH9E6WkaOmeN9Ks%2BLZ6d4Fga9ekM%3D&reserved=0
> The information contained in this e-mail from Quadris may be
> confidential and privileged for the private use of the named
> recipient.  The contents of this e-mail may not necessarily represent the 
> official views of Quadris.
> If you have received this information in error you must not copy,
> distribute or take any action or reliance on its contents.  Please
> destroy any hard copies and delete this message.
>