Re: cloudstack on debian 10/11

[Embedded]

ok quick update debian 11.9 as managemnt and host both work on 192.168.xxx.xxx 
address space as aio, cant seem to connect XCP-NG 8.2.0 though
have to debug

On Monday 15 April 2024 08:55:34 PM (+07:00), Embedded wrote:

> 
> 
> 
> On Monday 15 April 2024 06:33:26 PM (+07:00), Wei ZHOU wrote:
> 
> > Is eth0 added to cloudbr0 bridge ?
> > 
> 
> further to this once you add the same machine as a host from the gui, you end 
> up with this, which is curious to me because its using inet 
> 169.254.0.1/16 scope global cloud0
> on cloud0 and my CentOs template never downloads... so something is off
> 
> 
> ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host 
>valid_lft forever preferred_lft forever
> 2: eno1:  mtu 1500 qdisc mq master cloudbr0 
> state UP group default qlen 1000
> link/ether 84:8f:69:fd:ea:1c brd ff:ff:ff:ff:ff:ff
> altname enp2s0f0
> 3: eno2:  mtu 1500 qdisc noop state DOWN group default 
> qlen 1000
> link/ether 84:8f:69:fd:ea:1d brd ff:ff:ff:ff:ff:ff
> altname enp2s0f3
> 4: cloudbr0:  mtu 1500 qdisc noqueue state 
> UP group default qlen 1000
> link/ether 4a:d3:e8:49:08:00 brd ff:ff:ff:ff:ff:ff
> inet 46.23.82.133/25 brd 46.23.82.255 scope global cloudbr0
>valid_lft forever preferred_lft forever
> inet6 fe80::48d3:e8ff:fe49:800/64 scope link 
>valid_lft forever preferred_lft forever
> 5: cloudbr1:  mtu 1500 qdisc noqueue state 
> DOWN group default qlen 1000
> link/ether 3e:63:d5:63:5d:18 brd ff:ff:ff:ff:ff:ff
> 6: cloud0:  mtu 1500 qdisc noqueue state UP 
> group default qlen 1000
> link/ether b6:67:93:f4:bd:ad brd ff:ff:ff:ff:ff:ff
> inet 169.254.0.1/16 scope global cloud0
>valid_lft forever preferred_lft forever
> inet6 fe80::b467:93ff:fef4:bdad/64 scope link 
>valid_lft forever preferred_lft forever
> 7: eno1.500@eno1:  mtu 1500 qdisc noqueue 
> master breno1-500 state UP group default qlen 1000
> link/ether 84:8f:69:fd:ea:1c brd ff:ff:ff:ff:ff:ff
> 8: breno1-500:  mtu 1500 qdisc noqueue state 
> UP group default qlen 1000
> link/ether 66:8f:69:eb:49:9e brd ff:ff:ff:ff:ff:ff
> 9: vnet0:  mtu 1500 qdisc noqueue master 
> cloud0 state UNKNOWN group default qlen 1000
> link/ether fe:00:a9:fe:7a:64 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::fc00:a9ff:fefe:7a64/64 scope link 
>valid_lft forever preferred_lft forever
> 10: vnet1:  mtu 1500 qdisc noqueue master 
> cloudbr0 state UNKNOWN group default qlen 1000
> link/ether fe:00:ae:00:00:66 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::fc00:aeff:fe00:66/64 scope link 
>valid_lft forever preferred_lft forever
> 11: vnet2:  mtu 1500 qdisc noqueue master 
> breno1-500 state UNKNOWN group default qlen 1000
> link/ether fe:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::fc00:ff:fe00:1/64 scope link 
>valid_lft forever preferred_lft forever
> 12: vnet3:  mtu 1500 qdisc noqueue master 
> cloud0 state UNKNOWN group default qlen 1000
> link/ether fe:00:a9:fe:c6:3a brd ff:ff:ff:ff:ff:ff
> inet6 fe80::fc00:a9ff:fefe:c63a/64 scope link 
>valid_lft forever preferred_lft forever
> 13: vnet4:  mtu 1500 qdisc noqueue master 
> cloudbr0 state UNKNOWN group default qlen 1000
> link/ether fe:00:9b:00:00:6b brd ff:ff:ff:ff:ff:ff
> inet6 fe80::fc00:9bff:fe00:6b/64 scope link 
>valid_lft forever preferred_lft forever
> 14: vnet5:  mtu 1500 qdisc noqueue master 
> breno1-500 state UNKNOWN group default qlen 1000
> link/ether fe:00:3e:00:00:02 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::fc00:3eff:fe00:2/64 scope link 
>valid_lft forever preferred_lft forever
> root@cs:~# brctl show
> bridge name   bridge id   STP enabled interfaces
> breno1-5008000.668f69eb499e   no  eno1.500
>   vnet2
>   vnet5
> cloud08000.b66793f4bdad   no  vnet0
>   vnet3
> cloudbr0  8000.4ad3e8490800   no  eno1
>   vnet1
>   vnet4
> cloudbr1  8000.3e63d5635d18   no  
> 
> 
> > -Wei
> > 
> > On Mon, Apr 15, 2024 at 1:14 PM lists  wrote:
> > >
> > >
> > >
> > >
> > > I did in fact get a debian 11 install up and running pretty much as a 
> > > management server and almost good as a host. Have to figure out why the 
> > > cloidbr0 is on a 169.xxx adress and why no centos template was 
> > > downloaded. Systemvms came up without a problem.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > On Apr 15, 2024 

Re: AW: Manual fence KVM Host

[Bryan Lima]

Hello, Murilo

NFSv3 has this behaviour, and it is a known issue, see this thread for 
reference[1]. This situation does not occur using version 4 of the 
protocol, as it changed the way lock works in this version. However, you 
mentioned you changed the storage to NFSv4, did you change the lock 
lease time of the NFS protocol? This situation should not happen with 
NFSv4, as the lock is removed if the client does not renew the lease, 
you can refer to [2] for more details upon the difference in lock 
mechanism between NFSv3 and NFSv4.


Best regards,
Bryan

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1547095#c43
[2]: 
https://community.netapp.com/t5/Tech-ONTAP-Blogs/NFSv3-and-NFSv4-What-s-the-difference/ba-p/441316#toc-hId-2029730352


On 15/04/2024 14:16, Murilo Moura wrote:
Complementing the case... I did a new test and found that the problem 
really lies in the lock generated in NFS.


When the KVM host has a virtualized instance running (with NFS primary 
storage) and this host suddenly loses power, the HA scheme only works 
if before marking the host as degraded I restart the NFS service to 
unlock the machine's file virtual. Doing it this way, I restart the 
NFS server (with this the file locks are released) and then, when I 
mark the KVM host as degraded, all failover happens automatically.


In conclusion, my problem is in fact this lock generated on the volume 
shared via NFS...


All tests were done in ACS version 4.19.0.1

image.png

image.png


regards,

Murilo Moura



On Mon, Apr 15, 2024 at 2:07 PM Murilo Moura  wrote:

Correct, the user instance and the computing offer have HA enabled.

regards,

Murilo Moura


On Mon, Apr 15, 2024 at 4:00 AM  wrote:

HI Murilo,

just checking, the user instance you are talking about are
using a service offering with HA enabled, correct?

Regards,
Swen

-Ursprüngliche Nachricht-
Von: Murilo Moura 
Gesendet: Sonntag, 14. April 2024 06:31
An: users@cloudstack.apache.org
Betreff: Re: AW: Manual fence KVM Host

Hello Guto!


I carefully checked the instructions that you and Daniel left
in this thread that I opened, but one point is not working and
I would like to see if you have experienced something similar...

By putting the host in the "Disconnected" state, I can trigger
the API to mark the host as degraded, so far everything is ok.
Right after this action I see that the system VMs are
recreated on the node that was active, but the user instances
(user vms) are not recreated.

Checking the NFS host where the image of this VM is located, I
noticed that using the "qemu-img info" command I cannot read
the volume file of this instance (error: Failed to get shared
"write" lock).

Is there any way to execute unlock or even another parameter
that makes kvm start a VM without locking the volume on the
primary storage in NFS? (I tried to put the NFS storage in
version 4, but it still had no effect)...


regards,

Murilo Moura


On Wed, Apr 10, 2024 at 2:38 PM Guto Veronezi

wrote:

> Hello Murilo,
>
> Complementing Swen's answer, if your host is still up and
you can
> manage it, then you could also put your host in maintenance
mode in
> ACS. This process will evacuate (migrate to another host)
every VM
> from the host (not only the ones that have HA enabled). Is
this your
> situation? If not, could you provide more details about your
> configurations and the environment state?
>
> Depending on what you have in your setup, the HA might not
work as
> expected. For VMware and XenServer, the process is expected
to happen
> at the hypervisor level. For KVM, ACS does not support HA;
what ACS
> supports is failover (it is named HA in ACS though) and this
process
> will work only when certain criteria are met. Furthermore,
we have two
> ways to implement the failover for ACS + KVM: the VM's
failover and
> the host's failover. In both cases, when identified that a host
> crashed or a VM suddenly stopped working, ACS will start the
VM in another host.
>
> In ACS + KVM, to work with VM's failover, it is necessary at
least one
> NFS primary storage; the KVM Agent of every host writes the
heartbeat
> in it. The VM's failover is triggered only if the VM's compute
> offering has the property "Offer HA" enabled OR the global
setting
> "force.ha" is enabled. VRs have failover triggered
independently of
> the offering of the global setting. In this approach, ACS
will check
> the 

Re: How to achieve VNF without VR

[Wei ZHOU]

You may refer to
https://www.shapeblue.com/vnf-appliance-integration-deep-dive/



On Monday, April 15, 2024, Gaurav Shrivastava
 wrote:

> Hi Team,
>
>
> Is there any way to achieve VNF without VR. If there are any steps or
> documentation that I can follow please let me know.
>
> I am using CloudStack 4.19.0.1
>
>
> Regards
> Gaurav
>
> --
> 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.
>

How to achieve VNF without VR

[Gaurav Shrivastava]

Hi Team,


Is there any way to achieve VNF without VR. If there are any steps or
documentation that I can follow please let me know.

I am using CloudStack 4.19.0.1


Regards
Gaurav

-- 
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: Null Pointer Exception on Kubernetes Deploy with CloudMonkey

[Ricardo Pertuz]

Hi Pearl,

In fact it was because the Network was created using the Cloudmonkey without 
ACL, once associated an ACL to it worked. Thanks for your prompt reply!


BR,

Ricardo Pertuz


On 15 Apr 2024 at 1:16 PM -0500, users@cloudstack.apache.org, wrote:
>
> Pearl

Re: Null Pointer Exception on Kubernetes Deploy with CloudMonkey

[Pearl d'Silva]

Hi Ricardo,

Was the network tier (of the VPC network) created without associating any ACL. 
Based on the NPE, it seems like it. This issue doesn't crop up when done via 
the UI, because creation of network tiers mandates associating an ACL.

Regards,
Pearl
 



From: Ricardo Pertuz 
Sent: April 15, 2024 2:05 PM
To: Vivek Kumar via users 
Subject: Null Pointer Exception on Kubernetes Deploy with CloudMonkey

Hi Community,

When using Cloudmonkey to create a Kubernetes Cluster we are getting a 
NullPointer Exception

Env
*
ACS: 4.19.0.1
Hyp: KVM
SO: Ubuntu 20

Logs
*

2024-04-15 12:55:08,360 ERROR [c.c.a.ApiServer] (qtp931675031-20:ctx-b9ffa6f7 
ctx-f16eb6b9 ctx-d99f7c6a) (logid:5accec2e) unhandled exception executing api 
command: [Ljava.lang.String;@50546e38
java.lang.NullPointerException
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.validateVpcTier(KubernetesClusterManagerImpl.java:414)
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.validateNetwork(KubernetesClusterManagerImpl.java:438)
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.getKubernetesClusterNetworkIfMissing(KubernetesClusterManagerImpl.java:845)
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.createManagedKubernetesCluster(KubernetesClusterManagerImpl.java:1221)
at 
org.apache.cloudstack.api.command.user.kubernetes.cluster.CreateKubernetesClusterCmd.create(CreateKubernetesClusterCmd.java:317)
at 
com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47)
at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:94)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:724)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:624)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:342)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:149)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:146)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:100)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
at 
org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1450)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:554)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:772)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at 
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at 

Null Pointer Exception on Kubernetes Deploy with CloudMonkey

[Ricardo Pertuz]

Hi Community,

When using Cloudmonkey to create a Kubernetes Cluster we are getting a 
NullPointer Exception

Env
*
ACS: 4.19.0.1
Hyp: KVM
SO: Ubuntu 20

Logs
*

2024-04-15 12:55:08,360 ERROR [c.c.a.ApiServer] (qtp931675031-20:ctx-b9ffa6f7 
ctx-f16eb6b9 ctx-d99f7c6a) (logid:5accec2e) unhandled exception executing api 
command: [Ljava.lang.String;@50546e38
java.lang.NullPointerException
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.validateVpcTier(KubernetesClusterManagerImpl.java:414)
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.validateNetwork(KubernetesClusterManagerImpl.java:438)
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.getKubernetesClusterNetworkIfMissing(KubernetesClusterManagerImpl.java:845)
at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.createManagedKubernetesCluster(KubernetesClusterManagerImpl.java:1221)
at 
org.apache.cloudstack.api.command.user.kubernetes.cluster.CreateKubernetesClusterCmd.create(CreateKubernetesClusterCmd.java:317)
at 
com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47)
at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:94)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:724)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:624)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:342)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:149)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:146)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:100)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
at 
org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1450)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:554)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:772)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at 
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
at 

Re: AW: Manual fence KVM Host

[Murilo Moura]

Complementing the case... I did a new test and found that the problem
really lies in the lock generated in NFS.

When the KVM host has a virtualized instance running (with NFS primary
storage) and this host suddenly loses power, the HA scheme only works if
before marking the host as degraded I restart the NFS service to unlock the
machine's file virtual. Doing it this way, I restart the NFS server (with
this the file locks are released) and then, when I mark the KVM host as
degraded, all failover happens automatically.

In conclusion, my problem is in fact this lock generated on the volume
shared via NFS...

All tests were done in ACS version 4.19.0.1

[image: image.png]

[image: image.png]


regards,

Murilo Moura


On Mon, Apr 15, 2024 at 2:07 PM Murilo Moura  wrote:

> Correct, the user instance and the computing offer have HA enabled.
>
> regards,
>
> Murilo Moura
>
>
> On Mon, Apr 15, 2024 at 4:00 AM  wrote:
>
>> HI Murilo,
>>
>> just checking, the user instance you are talking about are using a
>> service offering with HA enabled, correct?
>>
>> Regards,
>> Swen
>>
>> -Ursprüngliche Nachricht-
>> Von: Murilo Moura 
>> Gesendet: Sonntag, 14. April 2024 06:31
>> An: users@cloudstack.apache.org
>> Betreff: Re: AW: Manual fence KVM Host
>>
>> Hello Guto!
>>
>>
>> I carefully checked the instructions that you and Daniel left in this
>> thread that I opened, but one point is not working and I would like to see
>> if you have experienced something similar...
>>
>> By putting the host in the "Disconnected" state, I can trigger the API to
>> mark the host as degraded, so far everything is ok. Right after this action
>> I see that the system VMs are recreated on the node that was active, but
>> the user instances (user vms) are not recreated.
>>
>> Checking the NFS host where the image of this VM is located, I noticed
>> that using the "qemu-img info" command I cannot read the volume file of
>> this instance (error: Failed to get shared "write" lock).
>>
>> Is there any way to execute unlock or even another parameter that makes
>> kvm start a VM without locking the volume on the primary storage in NFS? (I
>> tried to put the NFS storage in version 4, but it still had no effect)...
>>
>>
>> regards,
>>
>> Murilo Moura
>>
>>
>> On Wed, Apr 10, 2024 at 2:38 PM Guto Veronezi 
>> wrote:
>>
>> > Hello Murilo,
>> >
>> > Complementing Swen's answer, if your host is still up and you can
>> > manage it, then you could also put your host in maintenance mode in
>> > ACS. This process will evacuate (migrate to another host) every VM
>> > from the host (not only the ones that have HA enabled). Is this your
>> > situation? If not, could you provide more details about your
>> > configurations and the environment state?
>> >
>> > Depending on what you have in your setup, the HA might not work as
>> > expected. For VMware and XenServer, the process is expected to happen
>> > at the hypervisor level. For KVM, ACS does not support HA; what ACS
>> > supports is failover (it is named HA in ACS though) and this process
>> > will work only when certain criteria are met. Furthermore, we have two
>> > ways to implement the failover for ACS + KVM: the VM's failover and
>> > the host's failover. In both cases, when identified that a host
>> > crashed or a VM suddenly stopped working, ACS will start the VM in
>> another host.
>> >
>> > In ACS + KVM, to work with VM's failover, it is necessary at least one
>> > NFS primary storage; the KVM Agent of every host writes the heartbeat
>> > in it. The VM's failover is triggered only if the VM's compute
>> > offering has the property "Offer HA" enabled OR the global setting
>> > "force.ha" is enabled. VRs have failover triggered independently of
>> > the offering of the global setting. In this approach, ACS will check
>> > the VM state periodically (sending commands to the KVM Agent) and it
>> > will trigger the failover if the VM meets the previously mentioned
>> > criteria AND the determined limit (defined by the global settings
>> > "ping.interval" and
>> > "ping.timeout") has been elapsed. Bear in mind that, if you lose your
>> > host, ACS will trigger the failover; however, if you gracefully
>> > shutdown the KVM Agent or the host, the Agent will send a disconnect
>> > command to the Management Server and ACS will not check the VM state
>> > anymore for that host. Therefore, if you lose your host while the
>> > service is down, the failover will not be triggered. Also, if a host
>> > loses access to the NFS primary storage used for heartbeat and the VM
>> > uses some other primary storage, ACS might trigger the failover too.
>> > As we do not have a STONITH/fencing in this scenario, it is possible
>> > for the VM to still be running in the host and ACS to try to start it
>> in another host.
>> >
>> > In ACS + KVM, to work with the host's failover, it is necessary to
>> > configure the host's OOBM (of each host desired to trigger the
>> > failover) in ACS. In this approach, ACS 

Re: AW: Manual fence KVM Host

[Murilo Moura]

Correct, the user instance and the computing offer have HA enabled.

regards,

Murilo Moura


On Mon, Apr 15, 2024 at 4:00 AM  wrote:

> HI Murilo,
>
> just checking, the user instance you are talking about are using a service
> offering with HA enabled, correct?
>
> Regards,
> Swen
>
> -Ursprüngliche Nachricht-
> Von: Murilo Moura 
> Gesendet: Sonntag, 14. April 2024 06:31
> An: users@cloudstack.apache.org
> Betreff: Re: AW: Manual fence KVM Host
>
> Hello Guto!
>
>
> I carefully checked the instructions that you and Daniel left in this
> thread that I opened, but one point is not working and I would like to see
> if you have experienced something similar...
>
> By putting the host in the "Disconnected" state, I can trigger the API to
> mark the host as degraded, so far everything is ok. Right after this action
> I see that the system VMs are recreated on the node that was active, but
> the user instances (user vms) are not recreated.
>
> Checking the NFS host where the image of this VM is located, I noticed
> that using the "qemu-img info" command I cannot read the volume file of
> this instance (error: Failed to get shared "write" lock).
>
> Is there any way to execute unlock or even another parameter that makes
> kvm start a VM without locking the volume on the primary storage in NFS? (I
> tried to put the NFS storage in version 4, but it still had no effect)...
>
>
> regards,
>
> Murilo Moura
>
>
> On Wed, Apr 10, 2024 at 2:38 PM Guto Veronezi 
> wrote:
>
> > Hello Murilo,
> >
> > Complementing Swen's answer, if your host is still up and you can
> > manage it, then you could also put your host in maintenance mode in
> > ACS. This process will evacuate (migrate to another host) every VM
> > from the host (not only the ones that have HA enabled). Is this your
> > situation? If not, could you provide more details about your
> > configurations and the environment state?
> >
> > Depending on what you have in your setup, the HA might not work as
> > expected. For VMware and XenServer, the process is expected to happen
> > at the hypervisor level. For KVM, ACS does not support HA; what ACS
> > supports is failover (it is named HA in ACS though) and this process
> > will work only when certain criteria are met. Furthermore, we have two
> > ways to implement the failover for ACS + KVM: the VM's failover and
> > the host's failover. In both cases, when identified that a host
> > crashed or a VM suddenly stopped working, ACS will start the VM in
> another host.
> >
> > In ACS + KVM, to work with VM's failover, it is necessary at least one
> > NFS primary storage; the KVM Agent of every host writes the heartbeat
> > in it. The VM's failover is triggered only if the VM's compute
> > offering has the property "Offer HA" enabled OR the global setting
> > "force.ha" is enabled. VRs have failover triggered independently of
> > the offering of the global setting. In this approach, ACS will check
> > the VM state periodically (sending commands to the KVM Agent) and it
> > will trigger the failover if the VM meets the previously mentioned
> > criteria AND the determined limit (defined by the global settings
> > "ping.interval" and
> > "ping.timeout") has been elapsed. Bear in mind that, if you lose your
> > host, ACS will trigger the failover; however, if you gracefully
> > shutdown the KVM Agent or the host, the Agent will send a disconnect
> > command to the Management Server and ACS will not check the VM state
> > anymore for that host. Therefore, if you lose your host while the
> > service is down, the failover will not be triggered. Also, if a host
> > loses access to the NFS primary storage used for heartbeat and the VM
> > uses some other primary storage, ACS might trigger the failover too.
> > As we do not have a STONITH/fencing in this scenario, it is possible
> > for the VM to still be running in the host and ACS to try to start it in
> another host.
> >
> > In ACS + KVM, to work with the host's failover, it is necessary to
> > configure the host's OOBM (of each host desired to trigger the
> > failover) in ACS. In this approach, ACS monitors the Agent's state and
> > triggers the failover in case it cannot establish the connection
> > again. In this scenario, ACS will shut down the host via OOBM and will
> > start the VMs in another host; therefore, it is not dependent on an NFS
> primary storage.
> > This behavior is driven by the "kvm.ha.*" global settings.
> > Furthermore, one has to be aware that stopping the Agent might trigger
> > the failover; therefore, it is recommended to disable the failover
> > feature while doing operations in the host (like upgrading the
> > packages or some other maintenance processes).
> >
> > Best regards,
> > Daniel Salvador (gutoveronezi)
> >
> > On 10/04/2024 03:52, m...@swen.io wrote:
> > > What exactly do you mean? In which state is the host?
> > > If a host is in state "Disconnected" or "Alert" you can declare a
> > > host
> > as degraded via api (
> > 

Re: cloudstack on debian 10/11

[Embedded]

On Monday 15 April 2024 06:33:26 PM (+07:00), Wei ZHOU wrote:

> Is eth0 added to cloudbr0 bridge ?
> 

further to this once you add the same machine as a host from the gui, you end 
up with this, which is curious to me because its using inet 169.254.0.1/16 
scope global cloud0
on cloud0 and my CentOs template never downloads... so something is off


ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc mq master cloudbr0 
state UP group default qlen 1000
link/ether 84:8f:69:fd:ea:1c brd ff:ff:ff:ff:ff:ff
altname enp2s0f0
3: eno2:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether 84:8f:69:fd:ea:1d brd ff:ff:ff:ff:ff:ff
altname enp2s0f3
4: cloudbr0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
link/ether 4a:d3:e8:49:08:00 brd ff:ff:ff:ff:ff:ff
inet 46.23.82.133/25 brd 46.23.82.255 scope global cloudbr0
   valid_lft forever preferred_lft forever
inet6 fe80::48d3:e8ff:fe49:800/64 scope link 
   valid_lft forever preferred_lft forever
5: cloudbr1:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 3e:63:d5:63:5d:18 brd ff:ff:ff:ff:ff:ff
6: cloud0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
link/ether b6:67:93:f4:bd:ad brd ff:ff:ff:ff:ff:ff
inet 169.254.0.1/16 scope global cloud0
   valid_lft forever preferred_lft forever
inet6 fe80::b467:93ff:fef4:bdad/64 scope link 
   valid_lft forever preferred_lft forever
7: eno1.500@eno1:  mtu 1500 qdisc noqueue 
master breno1-500 state UP group default qlen 1000
link/ether 84:8f:69:fd:ea:1c brd ff:ff:ff:ff:ff:ff
8: breno1-500:  mtu 1500 qdisc noqueue state 
UP group default qlen 1000
link/ether 66:8f:69:eb:49:9e brd ff:ff:ff:ff:ff:ff
9: vnet0:  mtu 1500 qdisc noqueue master 
cloud0 state UNKNOWN group default qlen 1000
link/ether fe:00:a9:fe:7a:64 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:a9ff:fefe:7a64/64 scope link 
   valid_lft forever preferred_lft forever
10: vnet1:  mtu 1500 qdisc noqueue master 
cloudbr0 state UNKNOWN group default qlen 1000
link/ether fe:00:ae:00:00:66 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:aeff:fe00:66/64 scope link 
   valid_lft forever preferred_lft forever
11: vnet2:  mtu 1500 qdisc noqueue master 
breno1-500 state UNKNOWN group default qlen 1000
link/ether fe:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:ff:fe00:1/64 scope link 
   valid_lft forever preferred_lft forever
12: vnet3:  mtu 1500 qdisc noqueue master 
cloud0 state UNKNOWN group default qlen 1000
link/ether fe:00:a9:fe:c6:3a brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:a9ff:fefe:c63a/64 scope link 
   valid_lft forever preferred_lft forever
13: vnet4:  mtu 1500 qdisc noqueue master 
cloudbr0 state UNKNOWN group default qlen 1000
link/ether fe:00:9b:00:00:6b brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:9bff:fe00:6b/64 scope link 
   valid_lft forever preferred_lft forever
14: vnet5:  mtu 1500 qdisc noqueue master 
breno1-500 state UNKNOWN group default qlen 1000
link/ether fe:00:3e:00:00:02 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:3eff:fe00:2/64 scope link 
   valid_lft forever preferred_lft forever
root@cs:~# brctl show
bridge name bridge id   STP enabled interfaces
breno1-500  8000.668f69eb499e   no  eno1.500
vnet2
vnet5
cloud0  8000.b66793f4bdad   no  vnet0
vnet3
cloudbr08000.4ad3e8490800   no  eno1
vnet1
vnet4
cloudbr18000.3e63d5635d18   no  


> -Wei
> 
> On Mon, Apr 15, 2024 at 1:14 PM lists  wrote:
> >
> >
> >
> >
> > I did in fact get a debian 11 install up and running pretty much as a 
> > management server and almost good as a host. Have to figure out why the 
> > cloidbr0 is on a 169.xxx adress and why no centos template was downloaded. 
> > Systemvms came up without a problem.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > On Apr 15, 2024 at 3:58 PM, Nuxwrote:
> > >
> > >
> > >  Found some notes on Debian here, there could be others..
> > > https://gist.github.com/rohityadavcloud/fc401a0fe8e8ea16b4b3a4e3d149ce0c
> > >
> > > On 2024-04-15 09:54, Nux wrote:
> > > >  Not as yet, no formal support for Debian.
> > > >  That said, this could change in the future..
> > > >  If you're a keen Debianista then it might be worth having a go
> > > >  nevertheless, it might just work or with 

Re: cloudstack on debian 10/11

[Embedded]

 ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc mq master cloudbr0 
state UP group default qlen 1000
link/ether 84:8f:69:fd:ea:1c brd ff:ff:ff:ff:ff:ff
altname enp2s0f0
3: eno2:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether 84:8f:69:fd:ea:1d brd ff:ff:ff:ff:ff:ff
altname enp2s0f3
4: cloudbr0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
link/ether 4a:d3:e8:49:08:00 brd ff:ff:ff:ff:ff:ff
inet 46.23.82.133/25 brd 46.23.82.255 scope global cloudbr0
   valid_lft forever preferred_lft forever
inet6 fe80::48d3:e8ff:fe49:800/64 scope link 
   valid_lft forever preferred_lft forever
5: cloudbr1:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 3e:63:d5:63:5d:18 brd ff:ff:ff:ff:ff:ff
dingo@cs:~$ brctl show
bridge name bridge id   STP enabled interfaces
cloudbr08000.4ad3e8490800   no  eno1
cloudbr18000.3e63d5635d18   no  
dingo@cs:~$ cat /etc/network/interfaces
source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eno1

auto cloudbr0
iface cloudbr0 inet static
bridge_ports eno1
bridge_fd 0
bridge_stp off
bridge_maxwait 1
address 46.23.82.133
netmask 255.255.255.128
gateway 46.23.82.129
dns-nameservers 8.8.8.8 8.8.4.4
dns-domain optimcloud.com

# guest network
auto cloudbr1
iface cloudbr1 inet manual
bridge_ports eth0.500
bridge_fd 0
bridge_stp off
bridge_maxwait 1


On Monday 15 April 2024 06:33:26 PM (+07:00), Wei ZHOU wrote:

> Is eth0 added to cloudbr0 bridge ?
> 
> -Wei
> 
> On Mon, Apr 15, 2024 at 1:14 PM lists  wrote:
> >
> >
> >
> >
> > I did in fact get a debian 11 install up and running pretty much as a 
> > management server and almost good as a host. Have to figure out why the 
> > cloidbr0 is on a 169.xxx adress and why no centos template was downloaded. 
> > Systemvms came up without a problem.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > On Apr 15, 2024 at 3:58 PM, Nuxwrote:
> > >
> > >
> > >  Found some notes on Debian here, there could be others..
> > > https://gist.github.com/rohityadavcloud/fc401a0fe8e8ea16b4b3a4e3d149ce0c
> > >
> > > On 2024-04-15 09:54, Nux wrote:
> > > >  Not as yet, no formal support for Debian.
> > > >  That said, this could change in the future..
> > > >  If you're a keen Debianista then it might be worth having a go
> > > >  nevertheless, it might just work or with minimum changes.
> > > >
> > > >
> > > >  On 2024-04-13 10:49, Embedded wrote:
> > > >>  the install guide states Preferred: CentOS/RHEL 7.2+ or Ubuntu
> > > >>  16.04(.2) or higher
> > > >>
> > > >>
> > > >>  would this include say debian 10/11 as a manager / and host/kvm
> > > >>  hypervisor ???
> > >
> >
> 

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

Re: cloudstack on debian 10/11

[Wei ZHOU]

Is eth0 added to cloudbr0 bridge ?

-Wei

On Mon, Apr 15, 2024 at 1:14 PM lists  wrote:
>
>
>
>
> I did in fact get a debian 11 install up and running pretty much as a 
> management server and almost good as a host. Have to figure out why the 
> cloidbr0 is on a 169.xxx adress and why no centos template was downloaded. 
> Systemvms came up without a problem.
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
> > On Apr 15, 2024 at 3:58 PM, Nuxwrote:
> >
> >
> >  Found some notes on Debian here, there could be others..
> > https://gist.github.com/rohityadavcloud/fc401a0fe8e8ea16b4b3a4e3d149ce0c
> >
> > On 2024-04-15 09:54, Nux wrote:
> > >  Not as yet, no formal support for Debian.
> > >  That said, this could change in the future..
> > >  If you're a keen Debianista then it might be worth having a go
> > >  nevertheless, it might just work or with minimum changes.
> > >
> > >
> > >  On 2024-04-13 10:49, Embedded wrote:
> > >>  the install guide states Preferred: CentOS/RHEL 7.2+ or Ubuntu
> > >>  16.04(.2) or higher
> > >>
> > >>
> > >>  would this include say debian 10/11 as a manager / and host/kvm
> > >>  hypervisor ???
> >
>

Re: cloudstack on debian 10/11

[lists]

 
 
 
I did in fact get a debian 11 install up and running pretty much as a 
management server and almost good as a host. Have to figure out why the 
cloidbr0 is on a 169.xxx adress and why no centos template was downloaded. 
Systemvms came up without a problem.
 

 

 

 

 
 
 
 
 
>  
> On Apr 15, 2024 at 3:58 PM, Nuxwrote:
>  
>  
>  Found some notes on Debian here, there could be others..
> https://gist.github.com/rohityadavcloud/fc401a0fe8e8ea16b4b3a4e3d149ce0c
>
> On 2024-04-15 09:54, Nux wrote:
> >  Not as yet, no formal support for Debian.
> >  That said, this could change in the future..
> >  If you're a keen Debianista then it might be worth having a go 
> >  nevertheless, it might just work or with minimum changes.
> >  
> >  
> >  On 2024-04-13 10:49, Embedded wrote:
> >>  the install guide states Preferred: CentOS/RHEL 7.2+ or Ubuntu 
> >>  16.04(.2) or higher
> >>  
> >>  
> >>  would this include say debian 10/11 as a manager / and host/kvm 
> >>  hypervisor ???
>
 

Re: cloudstack on debian 10/11

[Nux]

Found some notes on Debian here, there could be others..
https://gist.github.com/rohityadavcloud/fc401a0fe8e8ea16b4b3a4e3d149ce0c

On 2024-04-15 09:54, Nux wrote:

Not as yet, no formal support for Debian.
That said, this could change in the future..
If you're a keen Debianista then it might be worth having a go 
nevertheless, it might just work or with minimum changes.



On 2024-04-13 10:49, Embedded wrote:
the install guide states Preferred: CentOS/RHEL 7.2+ or Ubuntu 
16.04(.2) or higher



would this include say debian 10/11 as a manager / and host/kvm 
hypervisor ???

Re: cloudstack on debian 10/11

[Nux]

Not as yet, no formal support for Debian.
That said, this could change in the future..
If you're a keen Debianista then it might be worth having a go 
nevertheless, it might just work or with minimum changes.



On 2024-04-13 10:49, Embedded wrote:
the install guide states Preferred: CentOS/RHEL 7.2+ or Ubuntu 
16.04(.2) or higher



would this include say debian 10/11 as a manager / and host/kvm 
hypervisor ???

Re: CentOS 5.5(64-bit) no GUI (KVM) Not Ready

[Jithin Raju]

You can restart the SSVM or the ‘cloud’ agent in SSVM to trigger downloading.

-Jithin

From: Embedded 
Date: Monday, 15 April 2024 at 10:16 AM
To: users@cloudstack.apache.org 
Subject: Re: CentOS 5.5(64-bit) no GUI (KVM) Not Ready



On Monday 15 April 2024 11:28:11 AM (+07:00), Jithin Raju wrote:

> Hi,
>
> Can you check the progress it must be still downloading.
>

nope, dont see where its doing anything, is it possible to trigger somehow 
manually from cli  ???

> -Jithin
>
> From: Embedded 
> Date: Monday, 15 April 2024 at 9:00 AM
> To: users@cloudstack.apache.org 
> Subject: CentOS 5.5(64-bit) no GUI (KVM) Not Ready
> just deployed a fresh cs 4.19 got the host up, system vms are running, but
> template vm says
>
> CentOS 5.5(64-bit) no GUI (KVM) Not Ready
>
>
> ideas? did i miss something?
>
> --
> Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
>
>
>
>

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

 

Re: How to kcs cluster name with supplied name?

[Kiran Chavala]

Hi Jaejong

The kuberneres/cks cluster created in Cloudstack are created via Kubeadm tool 
which always creates with the default name as kubernetes

You can rename the cluster  as per your requirement by following this article


https://medium.com/@manumv1/how-to-rename-a-kubernetes-cluster-c10db35d92aa


From kubectl perspective your kubernetes cluster can be named totally 
differently than in kubeadm-config ConfigMap. They are configured 
independently. Actually in .kube/config file you can refer to your cluster by 
any name you want, but you need to make the change both in clusters as well as 
in contexts sections.


Also you can reach out to the kubeadm community to cross check if they can 
support specifying a name during k8s cluster creation

https://github.com/kubernetes/kubeadm/issues/416



Regards
Kiran

From: jaejong 
Date: Monday, 15 April 2024 at 5:53 AM
To: users@cloudstack.apache.org 
Subject: How to kcs cluster name with supplied name?
I create kcs community iso 1.28.4 on acs 4.19.0.1.

I create two clusters. The cluster name is not populated to Config.
In cluster kubeconfig, cluster name is kubernetes  and user is kubernetes-admin.
So I can not merge two into one.

I remember it is possible in previous version.

kubeconfig is created with the name I supplied when  create kubernetes cluster 
such as:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: ...
server: https://x.x.x.x:6443
  name: supplied-name
contexts:
- context:
cluster: supplied-name
user: supplied-name-admin
  name: supplied-name-admin@kubernetes
kind: Config
preferences: {}
users:
- name: supplied-name-admin
  user:
So I can distingush two clusters.

Is there any way I can change cluster name in  kubeconfig?

 

AW: AW: Manual fence KVM Host

[me]

HI Murilo,

just checking, the user instance you are talking about are using a service 
offering with HA enabled, correct?

Regards,
Swen

-Ursprüngliche Nachricht-
Von: Murilo Moura  
Gesendet: Sonntag, 14. April 2024 06:31
An: users@cloudstack.apache.org
Betreff: Re: AW: Manual fence KVM Host

Hello Guto!


I carefully checked the instructions that you and Daniel left in this thread 
that I opened, but one point is not working and I would like to see if you have 
experienced something similar...

By putting the host in the "Disconnected" state, I can trigger the API to mark 
the host as degraded, so far everything is ok. Right after this action I see 
that the system VMs are recreated on the node that was active, but the user 
instances (user vms) are not recreated.

Checking the NFS host where the image of this VM is located, I noticed that 
using the "qemu-img info" command I cannot read the volume file of this 
instance (error: Failed to get shared "write" lock).

Is there any way to execute unlock or even another parameter that makes kvm 
start a VM without locking the volume on the primary storage in NFS? (I tried 
to put the NFS storage in version 4, but it still had no effect)...


regards,

Murilo Moura


On Wed, Apr 10, 2024 at 2:38 PM Guto Veronezi 
wrote:

> Hello Murilo,
>
> Complementing Swen's answer, if your host is still up and you can 
> manage it, then you could also put your host in maintenance mode in 
> ACS. This process will evacuate (migrate to another host) every VM 
> from the host (not only the ones that have HA enabled). Is this your 
> situation? If not, could you provide more details about your 
> configurations and the environment state?
>
> Depending on what you have in your setup, the HA might not work as 
> expected. For VMware and XenServer, the process is expected to happen 
> at the hypervisor level. For KVM, ACS does not support HA; what ACS 
> supports is failover (it is named HA in ACS though) and this process 
> will work only when certain criteria are met. Furthermore, we have two 
> ways to implement the failover for ACS + KVM: the VM's failover and 
> the host's failover. In both cases, when identified that a host 
> crashed or a VM suddenly stopped working, ACS will start the VM in another 
> host.
>
> In ACS + KVM, to work with VM's failover, it is necessary at least one 
> NFS primary storage; the KVM Agent of every host writes the heartbeat 
> in it. The VM's failover is triggered only if the VM's compute 
> offering has the property "Offer HA" enabled OR the global setting 
> "force.ha" is enabled. VRs have failover triggered independently of 
> the offering of the global setting. In this approach, ACS will check 
> the VM state periodically (sending commands to the KVM Agent) and it 
> will trigger the failover if the VM meets the previously mentioned 
> criteria AND the determined limit (defined by the global settings 
> "ping.interval" and
> "ping.timeout") has been elapsed. Bear in mind that, if you lose your 
> host, ACS will trigger the failover; however, if you gracefully 
> shutdown the KVM Agent or the host, the Agent will send a disconnect 
> command to the Management Server and ACS will not check the VM state 
> anymore for that host. Therefore, if you lose your host while the 
> service is down, the failover will not be triggered. Also, if a host 
> loses access to the NFS primary storage used for heartbeat and the VM 
> uses some other primary storage, ACS might trigger the failover too. 
> As we do not have a STONITH/fencing in this scenario, it is possible 
> for the VM to still be running in the host and ACS to try to start it in 
> another host.
>
> In ACS + KVM, to work with the host's failover, it is necessary to 
> configure the host's OOBM (of each host desired to trigger the 
> failover) in ACS. In this approach, ACS monitors the Agent's state and 
> triggers the failover in case it cannot establish the connection 
> again. In this scenario, ACS will shut down the host via OOBM and will 
> start the VMs in another host; therefore, it is not dependent on an NFS 
> primary storage.
> This behavior is driven by the "kvm.ha.*" global settings. 
> Furthermore, one has to be aware that stopping the Agent might trigger 
> the failover; therefore, it is recommended to disable the failover 
> feature while doing operations in the host (like upgrading the 
> packages or some other maintenance processes).
>
> Best regards,
> Daniel Salvador (gutoveronezi)
>
> On 10/04/2024 03:52, m...@swen.io wrote:
> > What exactly do you mean? In which state is the host?
> > If a host is in state "Disconnected" or "Alert" you can declare a 
> > host
> as degraded via api (
> https://cloudstack.apache.org/api/apidocs-4.19/apis/declareHostAsDegra
> ded.html)
> or UI (icon).
> > Cloudstack will then start all VM with HA enabled on other hosts, if
> storage is accessible.
> >
> > Regards,
> > Swen
> >
> > -Ursprüngliche Nachricht-
> > Von: Murilo