date:20240429

Re: Guest VM connecting DC NAS

2024-04-29 Thread Jithin Raju

Hi Nixon,

In an isolated guest network you could create a guest instance and use it as a 
NAS?
In a shared network you will have more flexibility in using existing NAS in the 
cloudstack provisioned guest instances.

-Jithin

From: Nixon Varghese K S 
Date: Saturday, 27 April 2024 at 7:04 AM
To: users@cloudstack.apache.org 
Subject: Guest VM connecting DC NAS
Hi All,

The optimum way to get NFS storage on the ACS guest VM is what we're
attempting to determine.This test environment is set up for advanced
networking on ACS (4.19.1).

ACS Portal: 10.10.40.252
NFS server: 10.10.40.250
KVM host: 172.16.0.100 (Have two network interface cards, one for private
use (cloudbr0) and the other for public use (cloudbr1))

ACS Management Range: 172.16.0.10–172.16.0.50 (cloudbr0)
ACS Public Range: Public IP RANGE (cloudbr1)

I had trunked KVM Privet NIC to talk to the ACS and NFS subnets. So through
172.16.0.0, I can communicate with the 10.10.40.0 network.

When I launch a VM with an isolated network of 10.1.1.5, it creates a VR
with 3 NICs (eth0: 10.1.1.1, eth1: control, and eth2: public). I need to
mount an NFS server with this guest VM. While checking the VR route, I can
see the default route to the public NIC. Through that NIC, I won't get the
10.10.40.250 system as it passed out from KVM through cloudbr1.

It is not advised to trunk KVM host cloudbr1 NIC and allow 10.10.40.250
traffic to route through the public network. What, in this particular
situation, will be the best course of action? I'm eager to hear your
thoughts.

With Regards,
Nixon Varghese

Re: Secondary storage system VM agent state and web UI wrong password

2024-04-29 Thread Jithin Raju

For the SSVM issue this article might help you, specifically check for the 
management server IP connectivity on port 8250.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM%2C+templates%2C+Secondary+storage+troubleshooting

Regarding the login issue you mentioned I am not sure about cause, I have faced 
this as well some times.

-Jithin

From: Hanis Irfan 
Date: Tuesday, 30 April 2024 at 8:10 AM
To: users@cloudstack.apache.org 
Subject: Secondary storage system VM agent state and web UI wrong password
I’m currently learning CS and setting up a POC environment.

Two system VMs is running on the same KVM host in my 3 KVM host cluster. 
However, the secondary storage VM Agent state is shown as Connecting.
I’ve SSH into the secondary storage VM and can assure that it can reach the 
Internet and management network.
This hinders the zone to access to NFS secondary storage that I’ve added. I 
can’t add/create new ISOs and templates for VM.
I tried deleting the secondary storage VM and let it recreate automatically. 
The new VM agent state is also the same.

[cid:image002.png@01DA9AEA.AE5CE800]

Also, I’ve an issue with the web UI loading for a long time if I entered a 
wrong password. I believe it should just throw an error.
I have to reopen or remove my browser cache back in order to try login back in.
Produced the same issue on both Firefox and Opera incognito/private mode.
This happens only for default admin user. If I enter a non-existing account, 
I’ll get “Error 531: Failed to authenticate user dcerwv in domain 1; please 
provide valid credentials”.


Best Regards,

Hanis Irfan
Cloud Infrastructure Engineer | Nebula Systems Sdn Bhd
Email: hanis.ir...@nebula-sys.com
Website: https://www.nebula-sys.com

RE: Guest VM connecting DC NAS

2024-04-29 Thread Hanis Irfan

When using advanced networking, I believe there's an option to create site
to site tunnel.

 

Maybe you can establish a tunnel between the isolated network via the VR and
onsite DC firewall/router.

 

But of course, it's going through public/Internet which might hinder the
network performance based on your setup.

 

Never tried this myself, just my thought.

 

On 2024/04/27 01:34:20 Nixon Varghese K S wrote:
> Hi All,
>
> The optimum way to get NFS storage on the ACS guest VM is what we're
> attempting to determine.This test environment is set up for advanced
> networking on ACS (4.19.1).
>
> ACS Portal: 10.10.40.252
> NFS server: 10.10.40.250
> KVM host: 172.16.0.100 (Have two network interface cards, one for private
> use (cloudbr0) and the other for public use (cloudbr1))
>
> ACS Management Range: 172.16.0.10-172.16.0.50 (cloudbr0)
> ACS Public Range: Public IP RANGE (cloudbr1)
>
> I had trunked KVM Privet NIC to talk to the ACS and NFS subnets. So
through
> 172.16.0.0, I can communicate with the 10.10.40.0 network.
>
> When I launch a VM with an isolated network of 10.1.1.5, it creates a VR
> with 3 NICs (eth0: 10.1.1.1, eth1: control, and eth2: public). I need to
> mount an NFS server with this guest VM. While checking the VR route, I can
> see the default route to the public NIC. Through that NIC, I won't get the
> 10.10.40.250 system as it passed out from KVM through cloudbr1.
>
> It is not advised to trunk KVM host cloudbr1 NIC and allow 10.10.40.250
> traffic to route through the public network. What, in this particular
> situation, will be the best course of action? I'm eager to hear your
> thoughts.
>
> With Regards,
> Nixon Varghese
>

 

Best Regards,

 

Hanis Irfan

Cloud Infrastructure Engineer | Nebula Systems Sdn Bhd

Email:   hanis.ir...@nebula-sys.com

Website:   https://www.nebula-sys.com

Secondary storage system VM agent state and web UI wrong password

2024-04-29 Thread Hanis Irfan

I'm currently learning CS and setting up a POC environment. 

 

Two system VMs is running on the same KVM host in my 3 KVM host cluster.
However, the secondary storage VM Agent state is shown as Connecting.

I've SSH into the secondary storage VM and can assure that it can reach the
Internet and management network.

This hinders the zone to access to NFS secondary storage that I've added. I
can't add/create new ISOs and templates for VM.

I tried deleting the secondary storage VM and let it recreate automatically.
The new VM agent state is also the same.

 






Also, I've an issue with the web UI loading for a long time if I entered a
wrong password. I believe it should just throw an error.

I have to reopen or remove my browser cache back in order to try login back
in.

Produced the same issue on both Firefox and Opera incognito/private mode.

This happens only for default admin user. If I enter a non-existing account,
I'll get "Error 531: Failed to authenticate user dcerwv in domain 1; please
provide valid credentials".

 

 

Best Regards,

 

Hanis Irfan

Cloud Infrastructure Engineer | Nebula Systems Sdn Bhd

Email:   hanis.ir...@nebula-sys.com

Website:   https://www.nebula-sys.com

Re: Replaced SSL now console proxy not working

2024-04-29 Thread Jimmy Huybrechts

Hi Fernando,

It’s a wildcard that is being replaced by a wildcard :) But the sslcerts table 
is empty in the database so something went wrong.

In the meantime I found my issue, the strange part is that the webgui does not 
check on if the certificate is correct, as I was missing the:
-END CERTIFICATE-

Which I did wrong a lot of the times.. and only noticed when looking in the 
database itself.
--
Jimmy

From: Fernando Alvarez 
Date: Monday, 29 April 2024 at 15:15
To: users@cloudstack.apache.org 
Subject: Re: Replaced SSL now console proxy not working
Jummy,

I understand.
Many times when you change the certificate you start using a Domain
Validation certificate (DV SSL) instead of a Wilcard certificate.  If the
global URL configuration is set to dynamic, the certificate does not work
and the console service does not work either.

---
Fernando.


El lun, 29 abr 2024 a las 9:52, Jimmy Huybrechts ()
escribió:

> Hi,
>
> It’s an existing deployment, I just tried renewing the certificate, before
> I started with the renewal it worked fine, so I think I borked something
> but what it is, I don’t know, I just followed the document I made before
> for myself.
>
> --
> Jimmy
>
> From: Fernando Alvarez 
> Date: Monday, 29 April 2024 at 14:45
> To: users@cloudstack.apache.org 
> Subject: Re: Replaced SSL now console proxy not working
> Hi Jimmy,
>
> Check these values in the global setting:
>
> consoleproxy.url.domain domain used for CPVM
> consoleproxy.sslEnabled Switches SSL configuration of the CPVMon / off
>
> And check if the URL configuration is set to Static or Dynamic.  If it is
> Dynamic remember that you need a Wildcard SSL Certificate.
>
> Maybe something here can help you:
> https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/
>
> Best Regards,
>
> Fernando.
>
>
> El lun, 29 abr 2024 a las 9:31, Jimmy Huybrechts ()
> escribió:
>
> > Hi Ruben,
> >
> > That made me being able to login :)
> >
> > I seem to be getting this:
> >
> > Apr 29 12:25:49 v-144-VM systemd[1]: cloud.service: Main process exited,
> > code=exited, status=1/FAILURE
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,272  INFO Agent:314 -
> > Stopping the agent: Reason = sig.kill
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/java.lang.Thread.run(Thread.java:829)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/java.lang.reflect.Method.invoke(Method.java:566)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:350)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:365)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:391)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: java.lang.NullPointerException
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,259 ERROR
> > ConsoleProxy:100 - null
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/java.lang.Thread.run(Thread.java:829)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstac

Re: Replaced SSL now console proxy not working

2024-04-29 Thread Fernando Alvarez

Jummy,

I understand.
Many times when you change the certificate you start using a Domain
Validation certificate (DV SSL) instead of a Wilcard certificate.  If the
global URL configuration is set to dynamic, the certificate does not work
and the console service does not work either.

---
Fernando.


El lun, 29 abr 2024 a las 9:52, Jimmy Huybrechts ()
escribió:

> Hi,
>
> It’s an existing deployment, I just tried renewing the certificate, before
> I started with the renewal it worked fine, so I think I borked something
> but what it is, I don’t know, I just followed the document I made before
> for myself.
>
> --
> Jimmy
>
> From: Fernando Alvarez 
> Date: Monday, 29 April 2024 at 14:45
> To: users@cloudstack.apache.org 
> Subject: Re: Replaced SSL now console proxy not working
> Hi Jimmy,
>
> Check these values in the global setting:
>
> consoleproxy.url.domain domain used for CPVM
> consoleproxy.sslEnabled Switches SSL configuration of the CPVMon / off
>
> And check if the URL configuration is set to Static or Dynamic.  If it is
> Dynamic remember that you need a Wildcard SSL Certificate.
>
> Maybe something here can help you:
> https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/
>
> Best Regards,
>
> Fernando.
>
>
> El lun, 29 abr 2024 a las 9:31, Jimmy Huybrechts ()
> escribió:
>
> > Hi Ruben,
> >
> > That made me being able to login :)
> >
> > I seem to be getting this:
> >
> > Apr 29 12:25:49 v-144-VM systemd[1]: cloud.service: Main process exited,
> > code=exited, status=1/FAILURE
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,272  INFO Agent:314 -
> > Stopping the agent: Reason = sig.kill
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/java.lang.Thread.run(Thread.java:829)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/java.lang.reflect.Method.invoke(Method.java:566)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:350)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:365)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:391)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: java.lang.NullPointerException
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,259 ERROR
> > ConsoleProxy:100 - null
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> > java.base/java.lang.Thread.run(Thread.java:829)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
> > Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> >
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyR

Re: Replaced SSL now console proxy not working

2024-04-29 Thread Jimmy Huybrechts

Hi,

It’s an existing deployment, I just tried renewing the certificate, before I 
started with the renewal it worked fine, so I think I borked something but what 
it is, I don’t know, I just followed the document I made before for myself.

--
Jimmy

From: Fernando Alvarez 
Date: Monday, 29 April 2024 at 14:45
To: users@cloudstack.apache.org 
Subject: Re: Replaced SSL now console proxy not working
Hi Jimmy,

Check these values in the global setting:

consoleproxy.url.domain domain used for CPVM
consoleproxy.sslEnabled Switches SSL configuration of the CPVMon / off

And check if the URL configuration is set to Static or Dynamic.  If it is
Dynamic remember that you need a Wildcard SSL Certificate.

Maybe something here can help you:
https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/

Best Regards,

Fernando.


El lun, 29 abr 2024 a las 9:31, Jimmy Huybrechts ()
escribió:

> Hi Ruben,
>
> That made me being able to login :)
>
> I seem to be getting this:
>
> Apr 29 12:25:49 v-144-VM systemd[1]: cloud.service: Main process exited,
> code=exited, status=1/FAILURE
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,272  INFO Agent:314 -
> Stopping the agent: Reason = sig.kill
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.Thread.run(Thread.java:829)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:350)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:365)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:391)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: java.lang.NullPointerException
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,259 ERROR
> ConsoleProxy:100 - null
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.Thread.run(Thread.java:829)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invok

Re: Replaced SSL now console proxy not working

2024-04-29 Thread Fernando Alvarez

Hi Jimmy,

Check these values in the global setting:

consoleproxy.url.domain domain used for CPVM
consoleproxy.sslEnabled Switches SSL configuration of the CPVMon / off

And check if the URL configuration is set to Static or Dynamic.  If it is
Dynamic remember that you need a Wildcard SSL Certificate.

Maybe something here can help you:
https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/

Best Regards,

Fernando.


El lun, 29 abr 2024 a las 9:31, Jimmy Huybrechts ()
escribió:

> Hi Ruben,
>
> That made me being able to login :)
>
> I seem to be getting this:
>
> Apr 29 12:25:49 v-144-VM systemd[1]: cloud.service: Main process exited,
> code=exited, status=1/FAILURE
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,272  INFO Agent:314 -
> Stopping the agent: Reason = sig.kill
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.Thread.run(Thread.java:829)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:350)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:365)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:391)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: java.lang.NullPointerException
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,259 ERROR
> ConsoleProxy:100 - null
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.Thread.run(Thread.java:829)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:350)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:365)
> Apr 29 12:25:48 v-144-VM _run.sh[58945]: at
> com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:39

Re: Replaced SSL now console proxy not working

2024-04-29 Thread Jimmy Huybrechts

Hi Ruben,

That made me being able to login :)

I seem to be getting this:

Apr 29 12:25:49 v-144-VM systemd[1]: cloud.service: Main process exited, 
code=exited, status=1/FAILURE
Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,272  INFO Agent:314 - 
Stopping the agent: Reason = sig.kill
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/java.lang.Thread.run(Thread.java:829)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/java.lang.reflect.Method.invoke(Method.java:566)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:350)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:365)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:391)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: java.lang.NullPointerException
Apr 29 12:25:48 v-144-VM _run.sh[58945]: 12:25:48,259 ERROR ConsoleProxy:100 - 
null
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/java.lang.Thread.run(Thread.java:829)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:45)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:48)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:346)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/java.lang.reflect.Method.invoke(Method.java:566)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:350)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:365)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:390)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl.createHttpServerInstance(ConsoleProxySecureServerFactoryImpl.java:82)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
com.cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl$1.(ConsoleProxySecureServerFactoryImpl.java:82)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: at 
jdk.httpserver/com.sun.net.httpserver.HttpsConfigurator.(HttpsConfigurator.java:81)
Apr 29 12:25:48 v-144-VM _run.sh[58945]: java.lang.NullPointerException: null 
SSLContext
Apr 29 12:25:48 v-144-VM _run.sh[5

Re: AMD Processor support in compute offering

2024-04-29 Thread Logeswaran T

Thanks for the reply Ivan. We would like to develop this feature for our
business and sponsor to the ACS community so that others can also be
benefited. Any developer help in the community to add this feature (we will
pay for it) would be greatly appreciated.

Regards
Loges

On Tue, Apr 23, 2024 at 11:52 AM Ivan Kudriavtsev 
wrote:

> Hi.
>
> Normally, you either sponsor it or develop it. This is how CloudStack
> works. Every function in CS was developed and sponsored by some individual
> or company. Also, I think that required functionality is already there. At
> least Qemu hooks probably enable it.
>
> Пн, 22 апр. 2024 г. в 08:11, Logeswaran T  .invalid
> >:
>
> > Hi Team,
> >
> > Since the AMD new release of GPU cards AMD Instinct™ MI300X GPU Data, we
> > would like to add the GPU support for these AMD M1300X cards to offer GPU
> > related services to our end customers. Any possibilities of this card
> > support in the upcoming releases? If possible any ETA is fine for our
> > roadmap.
> >
> > Regards,
> > Loges
> >
> > --
> >
> >
> >
> >
> > *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*
> >
>

-- 

*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: Replaced SSL now console proxy not working

2024-04-29 Thread Ruben Bosch

Jimmy, you can run "cloudstack-ssh 169.x.x.x" or "ssh -i
/root/.ssh/id_rsa.cloud -p 3922 root@169.x.x.x" from the hypervisor running
the system VM to SSH into the system VM.

On Mon, Apr 29, 2024 at 2:09 PM Jimmy Huybrechts 
wrote:

> Hi,
>
> So I replaced the SSL certficate today since it uses lets encrypt.
>
> My secondary storage worked fine after recreation, but it seems my
> consoleproxy doesn’t as it shows agent state disconnected, connecting,
> disconnected.
>
> Now obviously I don’t have any console now so I can’t see what is wrong
> with it. :) how to connect to it over for example SSH (as I get connection
> refused) or a different way? So I can see what is wrong with it and debug.
> I would guess it has something to do with SSL but without debugging it’s
> anyone’s guess.
>
> --
> Jimmy
>

Replaced SSL now console proxy not working

2024-04-29 Thread Jimmy Huybrechts

Hi,

So I replaced the SSL certficate today since it uses lets encrypt.

My secondary storage worked fine after recreation, but it seems my consoleproxy 
doesn’t as it shows agent state disconnected, connecting, disconnected.

Now obviously I don’t have any console now so I can’t see what is wrong with 
it. :) how to connect to it over for example SSH (as I get connection refused) 
or a different way? So I can see what is wrong with it and debug.
I would guess it has something to do with SSL but without debugging it’s 
anyone’s guess.

--
Jimmy

Re: SSL Medium Strength Cipher Suites Supported | port 8250 on Management servers

2024-04-29 Thread Rohit Yadav

Hi Vivek,

I think you can tune the following global settings to regenerate CloudStack's 
root-ca certificates with chosen cipher/algorithm and key size: (depending on 
the ACS version if it has CA framework)

ca.framework.cert.signature.algorithm
ca.framework.cert.keysize

(for an already deployed cloudstack env, after changing this you may need to 
delete old root-ca keypair for this to regenerate new server certificates and 
CA certificate, by removing the configurations found out by: `select * from 
configuration where name like 'ca.plugin.root%' and category='Hidden'\G;`; and 
then restarting management servers one by one).

Alternatively, you can also test and disable cipher algorithm via 
/etc/cloudstack/management/java.security.ciphers that you don't want. And of 
course, you want to test and validate these in a test environment before 
applying in production (and take db backups just in case).


Regards.

 



From: Vivek Kumar 
Sent: Monday, April 29, 2024 15:27
To: CloudStack Users Mailing list 
Subject: SSL Medium Strength Cipher Suites Supported | port 8250 on Management 
servers

Hello Folks,

Our security team has highlighted that services running on port 8250 supports 
the use of SSL ciphers that offer medium strength encryption. Nessus regards 
medium strength as any encryption  that uses key lengths at least 64 bits and 
less than 112 bits,

It is considerably easier to circumvent medium strength encryption if the 
attacker is on the same physical network.


Our security team has recommended to reconfigure the affected application if 
possible to avoid use of medium strength ciphers, so we do something about it 
or not ?




Vivek Kumar
Sr. Manager - Cloud & DevOps
TechOps | Indiqus Technologies

vivek.ku...@indiqus.com 
www.indiqus.com 





--
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.

SSL Medium Strength Cipher Suites Supported | port 8250 on Management servers

2024-04-29 Thread Vivek Kumar

Hello Folks,

Our security team has highlighted that services running on port 8250 supports 
the use of SSL ciphers that offer medium strength encryption. Nessus regards 
medium strength as any encryption  that uses key lengths at least 64 bits and 
less than 112 bits,

It is considerably easier to circumvent medium strength encryption if the 
attacker is on the same physical network.


Our security team has recommended to reconfigure the affected application if 
possible to avoid use of medium strength ciphers, so we do something about it 
or not ?




Vivek Kumar
Sr. Manager - Cloud & DevOps
TechOps | Indiqus Technologies

vivek.ku...@indiqus.com 
www.indiqus.com 





-- 
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: [D] Same network for VMs as KVM hosts? [cloudstack]

2024-04-29 Thread via GitHub



GitHub user dR3b edited a comment on the discussion: Same network for VMs as 
KVM hosts?

@weizhouapache Thanks! This works, but deletes all the IPtable rules on the 
host. I have not created any rules myself. These rules must be from Cloudstack 
or UFW.

GitHub link: 
https://github.com/apache/cloudstack/discussions/8998#discussioncomment-9260365


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

2024-04-29 Thread via GitHub



GitHub user dR3b added a comment to the discussion: Same network for VMs as KVM 
hosts?

@weizhouapache Thanks! This works, but deletes all Iptables rules on the host. 
I have not created any rules myself. These rules must be from Cloudstack or UFW.

GitHub link: 
https://github.com/apache/cloudstack/discussions/8998#discussioncomment-9260365


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

2024-04-29 Thread via GitHub



GitHub user weizhouapache added a comment to the discussion: Same network for 
VMs as KVM hosts?

@dR3b 
a user has replied to to this thread in the users mailing list, no idea why it 
is not present here

![image](https://github.com/apache/cloudstack/assets/57355700/cc9f9b3e-09e9-47f7-ba23-1b8b0667872a)



GitHub link: 
https://github.com/apache/cloudstack/discussions/8998#discussioncomment-9259981


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

2024-04-29 Thread via GitHub



GitHub user dR3b edited a comment on the discussion: Same network for VMs as 
KVM hosts?

@weizhouapache Yes!
```
root@nuc1:/# cat /proc/sys/net/ipv4/ip_forward
1
```

GitHub link: 
https://github.com/apache/cloudstack/discussions/8998#discussioncomment-9258076


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: Shared guest network assigned to multiple domains

2024-04-29 Thread Ruben Bosch

Yes, in theory it sounds good, but the IPv6 overlap check seems to block
everything. I think our best way forward is to move the network to ROOT and
ensure all free IPs are allocated in the db so that other users cannot use
the network.

Thanks for thinking along Wei, Daan and Pearl!

On Fri, Apr 26, 2024 at 5:27 PM Wei ZHOU  wrote:

> Hi Pearl and Ruben,
>
> I think the main issue is that both networks (same gateway/cidr but
> under different accounts) should work. Pearl's idea is good, we can
> add some steps as below
>
> - backup the database
> - remove a Free IP from `user_ip_address` table
> - create a shared network with startip/endip = FreeIP, and same vlan,
> choose skipping the vlan check
> - get the id of the new vlan from `vlan` table, update the ip4_range
> of new vlan to same
> - get the id of network from `networks` table
> - If VR is needed, update `vlan_db_id` and `network_id` of a Free IP
> to the new network/vlan so the new network has 2 IPs (1 for VR, 1 for
> VM)
> - assign Vm to the new account by API,  the Free IP will be assigned to
> the VM
> - update `vlan_db_id` and `network_id` of the old vm IP to the new
> network/vlan
> - update vm IP to the old vm IP
> - start the VM
>
>
>
> I have not tested it yet.
>
>
> Kind regards,
> Wei
>
>
>
>
> On Fri, Apr 26, 2024 at 5:06 PM Pearl d'Silva
>  wrote:
> >
> > I did not hit the issue with overlapping IP ranges as the network in the
> destination domain / account was initially created with a different vlan
> and then they were updated (or swapped) with the VLAN in the source domain.
> However, I did not test with IPv6.
> >
> >
> >
> >
> >
> >
> > 
> > From: Ruben Bosch 
> > Sent: April 26, 2024 10:58 AM
> > To: users@cloudstack.apache.org 
> > Subject: Re: Shared guest network assigned to multiple domains
> >
> > Hi Pearl,
> >
> > Thanks for the suggestion. Yes, assignVirtualMachine is an option, but in
> > this case the used network is not accessible by the destination
> > domain/account. Creating the same network twice also doesn't seem like an
> > option due to NetUtils.ipRangesOverlap. It also seems to not be a
> > possibility to create the same network without filling in the start/end
> IPs
> > for IPv4, because then another error is triggered for the IPv6 range
> > overlapping "The IPv6 range with tag: 1000 already has IPs that overlap
> > with the new range." (tested on 4.18.1). The VXLAN ID in this case
> remains
> > the same and the VLAN ID overlap check is disabled.
> >
> > Regards,
> >
> > Ruben Bosch
> >
> > On Fri, Apr 26, 2024 at 4:21 PM Pearl d'Silva <
> pearl.dsi...@shapeblue.com>
> > wrote:
> >
> > > Hi Ruben,
> > >
> > > Have you tried the 'Assign Instance to Another Account'
> > > (assignVirtualMachine API) operation on the stopped VMs. This would
> help in
> > > moving the VM(s) from one domain/account to another. I did a small
> test to
> > > see if we could preserve the IP and it seemed to work but I may be
> wrong in
> > > my understanding. This was my setup:
> > >
> > > VM1 in domain /ROOT/dom1 deployed in shared network shdom1 with vlan:
> 700
> > > with CIDR: 10.70.70.1/24
> > >
> > > Created another domain /ROOT/dom2 and created a shared network shdom2
> in
> > > this domain with vlan, say: 701 with CIDR: 10.70.70.1/24
> > >
> > > swap the vlans via DB updated:
> > > update networks set broadcast_uri = "vlan://701" where id =
> ;
> > > update networks set broadcast_uri = "vlan://700" where id =
> ;
> > > update vlan set vlan_id = 701 where id = ;
> > > update vlan set vlan_id = 700 where id = ;
> > >
> > > Stop the VM(s) in /ROOT/dom1 domain that need to be moved, and then use
> > > the Assign Instance to another Account to move VM to the destination
> domain
> > > and account.
> > >
> > > Regards,
> > > Pearl
> > >
> > >
> > >
> > > 
> > > From: Ruben Bosch 
> > > Sent: April 26, 2024 9:26 AM
> > > To: users@cloudstack.apache.org 
> > > Subject: Re: Shared guest network assigned to multiple domains
> > >
> > > Wei, the use cases may vary. In some cases it will be moved completely
> to a
> > > different domain+account, in other cases not.
> > >
> > > On Fri, Apr 26, 2024 at 2:48 PM Wei ZHOU 
> wrote:
> > >
> > > > Hi Ruben,
> > > >
> > > > Will you move all VMs on the network to another account, or just some
> > > > of the VMs ?
> > > >
> > > > -Wei
> > > >
> > > > On Fri, Apr 26, 2024 at 2:44 PM Ruben Bosch 
> > > wrote:
> > > > >
> > > > > Thanks Daan :-) Hope there are others with some ideas as well!
> > > > >
> > > > > On Fri, Apr 26, 2024 at 2:42 PM Daan Hoogland <
> daan.hoogl...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > ok, from what I know now I have exhausted my clues. Hope you get
> your
> > > > > > migration done expediently.
> > > > > >
> > > > > > On Fri, Apr 26, 2024 at 2:29 PM Ruben Bosch <
> ruben.bo...@cldin.eu>
> > > > wrote:
> > > > > > >
> > > > > > > Hmm, that might be possible. However we would like to automate
> a

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

2024-04-29 Thread Embedded



i noticed similar issue on 4.19 ... iptables -F on the host resolved it... 
seems somthing wasnt being setup right with rules

On Monday 29 April 2024 02:18:03 AM (-04:00), dR3b (via GitHub) wrote:

> 
> GitHub user dR3b edited a comment on the discussion: Same network for VMs as 
> KVM hosts?
> 
> @weizhouapache 
> 
> Thanks! After several pages in the documentation[1], I was able to complete 
> the installation.
> 
> - [x] System-VM consoleproxy, Up and running
> - [x] System-VM secondarystoragevm, Up and running
> - [x] Virtual-Router, defaultGuestNetwork, Up and running
> - [x] Compute-Instance, arch1-1, Running (192.168.1.196)
> 
> But now I have another question: I cannot ping the IP of “arch1-1” via a PC 
> in the same network (192.168.1.53). From my Cloudstack Management/KVM host, 
> however, it's possible. What have I forgotten?
> 
> [1] 
> https://docs.cloudstack.apache.org/en/latest/adminguide/networking_and_traffic.html#configuring-a-shared-guest-network
> 
> GitHub link: 
> https://github.com/apache/cloudstack/discussions/8998#discussioncomment-9255081
> 
> 
> This is an automatically sent email for users@cloudstack.apache.org.
> To unsubscribe, please send an email to: 
> users-unsubscr...@cloudstack.apache.org
> 
> 

-- 
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

Re: Guest VM connecting DC NAS

Re: Secondary storage system VM agent state and web UI wrong password

RE: Guest VM connecting DC NAS

Secondary storage system VM agent state and web UI wrong password

Re: Replaced SSL now console proxy not working

Re: Replaced SSL now console proxy not working

Re: Replaced SSL now console proxy not working

Re: Replaced SSL now console proxy not working

Re: Replaced SSL now console proxy not working

Re: AMD Processor support in compute offering

Re: Replaced SSL now console proxy not working

Replaced SSL now console proxy not working

Re: SSL Medium Strength Cipher Suites Supported | port 8250 on Management servers

SSL Medium Strength Cipher Suites Supported | port 8250 on Management servers

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

Re: Shared guest network assigned to multiple domains

Re: [D] Same network for VMs as KVM hosts? [cloudstack]

20 matches

Site Navigation

Mail list logo

Footer information