Re: New PMC member: Slavka Peleva
Congratulations Slavka! From: Jithin Raju Sent: Thursday, April 11, 2024 9:44 AM To: d...@cloudstack.apache.org ; users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva Congratulations Slavka! -Jithin From: Ivet Petrova Date: Wednesday, 10 April 2024 at 4:41 PM To: users@cloudstack.apache.org , dev Subject: Fwd: New PMC member: Slavka Peleva Hello all, The Project Management Committee (PMC) for Apache CloudStack has invited Slavka Peleva to become a PMC member and we are pleased to announce that they have accepted. Slavka has contributed in the past and has shown effort to make the project run smoothly Please join me in congratulating Slavka! Best regards,
Re: XenServer vs XCP-NG
Hi , Here is the list of XCP-ng supported versions for ACS 4.19 : XCP-ng 7.4.0, 7.6.0, 8.0.0, 8.1.0, 8.2.0 [1] [1] http://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes/compat.html -Jithin From: Embedded Date: Wednesday, 10 April 2024 at 6:44 AM To: users@cloudstack.apache.org Subject: XenServer vs XCP-NG Sorry I have to ask, I see XenServer is listed, but i donbt see any documentation for XCP-NG, i know it was previously supported. Is it still supported and what is the supported versions? as 3.0 is now in the wild. Thanks -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
Re: New PMC member: Slavka Peleva
Congratulations Slavka! -Jithin From: Ivet Petrova Date: Wednesday, 10 April 2024 at 4:41 PM To: users@cloudstack.apache.org , dev Subject: Fwd: New PMC member: Slavka Peleva Hello all, The Project Management Committee (PMC) for Apache CloudStack has invited Slavka Peleva to become a PMC member and we are pleased to announce that they have accepted. Slavka has contributed in the past and has shown effort to make the project run smoothly Please join me in congratulating Slavka! Best regards,
RE: CPU compatibility
I think we could also reach this by defining host tags? If so it should also be possible to mix intel & amd in one cluster. Am I right? -Original Message- From: R A Sent: Donnerstag, 11. April 2024 00:07 To: users@cloudstack.apache.org Subject: RE: CPU compatibility We have Hosts with Epyc 7763 Milan, Epyc 9654 Genoa and Epyc 9754 Genoa. So one way would be to separate Milan and Genoa CPUs in different clusters. On the other hand if there would be a option to configure the migration peers for every hosts both CPU Families could be in one cluster. So when a vm is powering up cloudstack could dispatch the vm across all hosts according on available host availability/ressources but for live migration cloudstack would use the migration peers which will then not conflict with different cpu flags -Original Message- From: Guto Veronezi Sent: Mittwoch, 10. April 2024 19:30 To: users@cloudstack.apache.org Subject: Re: CPU compatibility For processors of the same family but of different generations, we can add them all to the same cluster, leveling the instructions to the lowest common denominator (limiting the instructions to the older generation). This way, every node on the cluster has the same set of instructions. If we do not level the instructions, a migration from an older generation to a new generation will not cause problems, as the new generation contains the older generation's set of instructions; the opposite might cause problems, as the older generation might not have all the instructions the new generation have. > So you recommend to make a cluster for each CPU Type ? It is a common recommendation in the academy; I found an older paper from VMware [1] that can help you understand this topic; however, if you dig a bit more you may find other papers. > Can you define the migration peer for hosts? For example having them all one > cluster but define somehow that migration should be done between hosts of > same CPU? That would be the idea by segregating hosts in clusters. Could you give details about your use case of having hosts with different specs (CPU families) in the same cluster? Best regards, Daniel Salvador (gutoveronezi) [1] https://www.vmware.com/techpapers/2007/vmware-vmotion-and-cpu-compatibility-1022.html On 10/04/2024 12:48, R A wrote: > Hi, > > is it also problematic migrating to different CPUs of same Family? For > example from Epyc 9654 to Epyc 9754 ? > > So you recommend to make a cluster for each CPU Type ? Can you define the > migration peer for hosts? For example having them all one cluster but define > somehow that migration should be done between hosts of same CPU? > > BR > > -Original Message- > From: Guto Veronezi > Sent: Mittwoch, 10. April 2024 00:14 > To: users@cloudstack.apache.org > Subject: Re: CPU compatibility > > Hello Steve, > > For CloudStack, it does not matter if you have hosts with different > processors; however, this is a recommendation regarding how virtualization > systems work; therefore, this discussion happens aside from CloudStack. > > When we are dealing with different processors, we are dealing with different > flags, instructions, clocks, and so on. For processors of the same family, > but of different generations, we can level the instructions to the lowest > common denominator (limit the instructions to the older generation); however, > it starts to get tricky when we are dealing with different families. For > instance, if you deploy a guest VM in a host with Xeon Silver and try to > migrate it to a Xeon Gold, the OS of your guest, which already knows the Xeon > Silver instructions, might not adapt to the instructions of the new host > (Xeon Gold). Therefore, in these cases, you will face problems in the guest > VM. > > If you are aware of the differences between the processors and that mixing > different types can cause problems, then you can create a cluster mixing > them; however, it is not recommended. > > For KVM, the parameter is defined in ACS; on the other hand, for XenServer > and VMware this kind of setup is done in the cluster in XenServer or vCenter. > > It is also important to bear in mind that, even though you level the > instruction sets between the different processors in the host operating > system, you might still suffer some issues due to clock differences when you > migrate a VM from a faster CPU to a slower CPU and vice versa. > > Best regards, > Daniel Salvador (gutoveronezi) > > On 09/04/2024 18:58, Wei ZHOU wrote: >> Hi, >> >> You can use a custom cpu model which is supported by both cpu processors. >> >> Please refer to >> https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/ >> k vm.html#configure-cpu-model-for-kvm-guest-optional >> >> -Wei >> >> >> On Tuesday, April 9, 2024, S.Fuller wrote: >> >>> The Cloudstack Install Guide has the following statement - "All >>> hosts within a cluster must be homogenous. The CPUs must be of the
RE: CPU compatibility
We have Hosts with Epyc 7763 Milan, Epyc 9654 Genoa and Epyc 9754 Genoa. So one way would be to separate Milan and Genoa CPUs in different clusters. On the other hand if there would be a option to configure the migration peers for every hosts both CPU Families could be in one cluster. So when a vm is powering up cloudstack could dispatch the vm across all hosts according on available host availability/ressources but for live migration cloudstack would use the migration peers which will then not conflict with different cpu flags -Original Message- From: Guto Veronezi Sent: Mittwoch, 10. April 2024 19:30 To: users@cloudstack.apache.org Subject: Re: CPU compatibility For processors of the same family but of different generations, we can add them all to the same cluster, leveling the instructions to the lowest common denominator (limiting the instructions to the older generation). This way, every node on the cluster has the same set of instructions. If we do not level the instructions, a migration from an older generation to a new generation will not cause problems, as the new generation contains the older generation's set of instructions; the opposite might cause problems, as the older generation might not have all the instructions the new generation have. > So you recommend to make a cluster for each CPU Type ? It is a common recommendation in the academy; I found an older paper from VMware [1] that can help you understand this topic; however, if you dig a bit more you may find other papers. > Can you define the migration peer for hosts? For example having them all one > cluster but define somehow that migration should be done between hosts of > same CPU? That would be the idea by segregating hosts in clusters. Could you give details about your use case of having hosts with different specs (CPU families) in the same cluster? Best regards, Daniel Salvador (gutoveronezi) [1] https://www.vmware.com/techpapers/2007/vmware-vmotion-and-cpu-compatibility-1022.html On 10/04/2024 12:48, R A wrote: > Hi, > > is it also problematic migrating to different CPUs of same Family? For > example from Epyc 9654 to Epyc 9754 ? > > So you recommend to make a cluster for each CPU Type ? Can you define the > migration peer for hosts? For example having them all one cluster but define > somehow that migration should be done between hosts of same CPU? > > BR > > -Original Message- > From: Guto Veronezi > Sent: Mittwoch, 10. April 2024 00:14 > To: users@cloudstack.apache.org > Subject: Re: CPU compatibility > > Hello Steve, > > For CloudStack, it does not matter if you have hosts with different > processors; however, this is a recommendation regarding how virtualization > systems work; therefore, this discussion happens aside from CloudStack. > > When we are dealing with different processors, we are dealing with different > flags, instructions, clocks, and so on. For processors of the same family, > but of different generations, we can level the instructions to the lowest > common denominator (limit the instructions to the older generation); however, > it starts to get tricky when we are dealing with different families. For > instance, if you deploy a guest VM in a host with Xeon Silver and try to > migrate it to a Xeon Gold, the OS of your guest, which already knows the Xeon > Silver instructions, might not adapt to the instructions of the new host > (Xeon Gold). Therefore, in these cases, you will face problems in the guest > VM. > > If you are aware of the differences between the processors and that mixing > different types can cause problems, then you can create a cluster mixing > them; however, it is not recommended. > > For KVM, the parameter is defined in ACS; on the other hand, for XenServer > and VMware this kind of setup is done in the cluster in XenServer or vCenter. > > It is also important to bear in mind that, even though you level the > instruction sets between the different processors in the host operating > system, you might still suffer some issues due to clock differences when you > migrate a VM from a faster CPU to a slower CPU and vice versa. > > Best regards, > Daniel Salvador (gutoveronezi) > > On 09/04/2024 18:58, Wei ZHOU wrote: >> Hi, >> >> You can use a custom cpu model which is supported by both cpu processors. >> >> Please refer to >> https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/ >> k vm.html#configure-cpu-model-for-kvm-guest-optional >> >> -Wei >> >> >> On Tuesday, April 9, 2024, S.Fuller wrote: >> >>> The Cloudstack Install Guide has the following statement - "All >>> hosts within a cluster must be homogenous. The CPUs must be of the >>> same type, count, and feature flags" >>> >>> Obviously this means we can't mix Intel and AMD CPUs within the same >>> cluster. However, for a cluster with Intel CPUs, how much if any >>> leeway is there within this statement? If I have two 20 Core Xeon >>> Silver 4316
CreateBackupCmd not starting due to "Cannot find login credentials for HYPERVISOR"
Hi,
I'm trying to get VM backups of 2 node KVM cluster working (using networker).
Wwhen trying to start a backup I'm immediatly getting a error message about
missing hypervisor login credentials. Maybe I overlooked someting in the
documentation but I can't figure out where these login credentials are
configured. Can anybody give me a hint?
Here's the log of one of my CreateBackupCmd Jobs:
2024-04-10 17:41:10,476 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-30:ctx-c3bb37fe job-1549) (logid:b1913df8) Add job-1549 into
job monitoring
2024-04-10 17:41:10,482 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(qtp1278254413-402:ctx-dddc56ad ctx-33b958e5) (logid:1dda45c8) submit async
job-1549, details: AsyncJobVO: {id:1549, userId: 4, accountId: 4, instanceType:
Backup, instanceId: 81, cmd:
org.apache.cloudstack.api.command.user.backup.CreateBackupCmd, cmdInfo:
{"virtualmachineid":"e338c774-6693-485f-9746-e3d172665af5","response":"json","ctxUserId":"4","httpmethod":"GET","ctxStartEventId":"3293","id":"81","ctxDetails":"{\"interface
com.cloud.vm.VirtualMachine\":\"e338c774-6693-485f-9746-e3d172665af5\"}","ctxAccountId":"4","cmdEventType":"BACKUP.CREATE"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049358837, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null, removed: null}
2024-04-10 17:41:10,485 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-30:ctx-c3bb37fe job-1549) (logid:e4d20d53) Executing
AsyncJobVO: {id:1549, userId: 4, accountId: 4, instanceType: Backup,
instanceId: 81, cmd:
org.apache.cloudstack.api.command.user.backup.CreateBackupCmd, cmdInfo:
{"virtualmachineid":"e338c774-6693-485f-9746-e3d172665af5","response":"json","ctxUserId":"4","httpmethod":"GET","ctxStartEventId":"3293","id":"81","ctxDetails":"{\"interface
com.cloud.vm.VirtualMachine\":\"e338c774-6693-485f-9746-e3d172665af5\"}","ctxAccountId":"4","cmdEventType":"BACKUP.CREATE"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049358837, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null, removed: null}
2024-04-10 17:41:10,519 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-30:ctx-c3bb37fe job-1549) (logid:e4d20d53) Complete async
job-1549, jobStatus: FAILED, resultCode: 530, result:
org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":"530","errortext":"Cannot
find login credentials for HYPERVISOR df99ba84-7814-47b8-aa99-dd9553c56b4c"}
{...}
2024-04-10 17:41:10,528 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-30:ctx-c3bb37fe job-1549) (logid:e4d20d53) Remove job-1549
from job monitoring
(local) > list backupofferings
{
"backupoffering": [
{
"allowuserdrivenbackups": true,
"created": "2024-04-10T17:08:37+0200",
"description": "Networker Instance Backup - 30 days retention",
"externalid": "57.0.53.26.0.0.0.0.0.130.19.102.213.182.20.91",
"id": "8373b357-6b3f-41d9-8054-873914e95476",
"name": "Networker Instance Backup",
"zoneid": "c65618bc-0dcf-4f8a-b365-6b0c11750091",
"zonename": "RZKE1"
}
],
"count": 1
}
(local) > list hosts id=df99ba84-7814-47b8-aa99-dd9553c56b4c
{
"count": 1,
"host": [
{
"capabilities": "hvm,snapshot",
"clusterid": "19939e9e-7588-47e0-82f5-3cd6a634723a",
"clustername": "RZKE1_Cluster03",
"clustertype": "CloudManaged",
"cpuallocated": "4.51%",
"cpuallocatedpercentage": "4.51%",
"cpuallocatedvalue": 13000,
"cpuallocatedwithoverprovisioning": "4.51%",
"cpuloadaverage": 0.73,
"cpunumber": 96,
"cpusockets": 2,
"cpuspeed": 3000,
"cpuused": "0.6%",
"cpuwithoverprovisioning": "288000",
"created": "2024-03-05T17:16:05+0100",
"details": {
"Host.OS": "Red Hat Enterprise Linux",
"Host.OS.Kernel.Version": "5.15.0-204.147.6.3.el9uek.x86_64",
"Host.OS.Version": "9.3",
"com.cloud.network.Networks.RouterPrivateIpStrategy": "HostLocal",
"secured": "true"
},
"encryptionsupported": true,
"events": "PingTimeout; AgentDisconnected; AgentConnected; HostDown;
Ping; Remove; ShutdownRequested; ManagementServerDown; StartAgentRebalance",
"hahost": false,
"hasannotations": false,
"hostha": {
"haenable": false,
"haprovider": "kvmhaprovider",
"hastate": "Disabled"
},
"hypervisor": "KVM",
"id": "df99ba84-7814-47b8-aa99-dd9553c56b4c",
"ipaddress": "172.16.67.76",
"islocalstorageactive": false,
"lastpinged": "1970-01-20T09:36:49+0100",
"managementserverid": "56474c8f-7212-424f-8eb1-34850b751b5b",
"memoryallocated": 24165482496,
"memoryallocatedbytes": 24165482496,
"memoryallocatedpercentage": "6%",
"memorytotal": 402669568000,
"memoryused": 11093024768,
Re: AW: Manual fence KVM Host
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/declareHostAsDegraded.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 Moura Gesendet: Mittwoch, 10. April 2024 02:10 An: users@cloudstack.apache.org Betreff: Manual fence KVM Host hey guys! Is there any way to manually fence a KVM host and then automatically start the migration of VMs that have HA enabled?
Re: CPU compatibility
For processors of the same family but of different generations, we can add them all to the same cluster, leveling the instructions to the lowest common denominator (limiting the instructions to the older generation). This way, every node on the cluster has the same set of instructions. If we do not level the instructions, a migration from an older generation to a new generation will not cause problems, as the new generation contains the older generation's set of instructions; the opposite might cause problems, as the older generation might not have all the instructions the new generation have. > So you recommend to make a cluster for each CPU Type ? It is a common recommendation in the academy; I found an older paper from VMware [1] that can help you understand this topic; however, if you dig a bit more you may find other papers. > Can you define the migration peer for hosts? For example having them all one cluster but define somehow that migration should be done between hosts of same CPU? That would be the idea by segregating hosts in clusters. Could you give details about your use case of having hosts with different specs (CPU families) in the same cluster? Best regards, Daniel Salvador (gutoveronezi) [1] https://www.vmware.com/techpapers/2007/vmware-vmotion-and-cpu-compatibility-1022.html On 10/04/2024 12:48, R A wrote: Hi, is it also problematic migrating to different CPUs of same Family? For example from Epyc 9654 to Epyc 9754 ? So you recommend to make a cluster for each CPU Type ? Can you define the migration peer for hosts? For example having them all one cluster but define somehow that migration should be done between hosts of same CPU? BR -Original Message- From: Guto Veronezi Sent: Mittwoch, 10. April 2024 00:14 To: users@cloudstack.apache.org Subject: Re: CPU compatibility Hello Steve, For CloudStack, it does not matter if you have hosts with different processors; however, this is a recommendation regarding how virtualization systems work; therefore, this discussion happens aside from CloudStack. When we are dealing with different processors, we are dealing with different flags, instructions, clocks, and so on. For processors of the same family, but of different generations, we can level the instructions to the lowest common denominator (limit the instructions to the older generation); however, it starts to get tricky when we are dealing with different families. For instance, if you deploy a guest VM in a host with Xeon Silver and try to migrate it to a Xeon Gold, the OS of your guest, which already knows the Xeon Silver instructions, might not adapt to the instructions of the new host (Xeon Gold). Therefore, in these cases, you will face problems in the guest VM. If you are aware of the differences between the processors and that mixing different types can cause problems, then you can create a cluster mixing them; however, it is not recommended. For KVM, the parameter is defined in ACS; on the other hand, for XenServer and VMware this kind of setup is done in the cluster in XenServer or vCenter. It is also important to bear in mind that, even though you level the instruction sets between the different processors in the host operating system, you might still suffer some issues due to clock differences when you migrate a VM from a faster CPU to a slower CPU and vice versa. Best regards, Daniel Salvador (gutoveronezi) On 09/04/2024 18:58, Wei ZHOU wrote: Hi, You can use a custom cpu model which is supported by both cpu processors. Please refer to https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/k vm.html#configure-cpu-model-for-kvm-guest-optional -Wei On Tuesday, April 9, 2024, S.Fuller wrote: The Cloudstack Install Guide has the following statement - "All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags" Obviously this means we can't mix Intel and AMD CPUs within the same cluster. However, for a cluster with Intel CPUs, how much if any leeway is there within this statement? If I have two 20 Core Xeon Silver 4316 CPUs on one host and two 20 Core Xeon Silver 4416 CPUs in another, is that close enough? I'm looking to add capacity to an existing cluster, and am trying to figure out how "picky" Cloudstack is about this. Steve Fuller steveful...@gmail.com
Re: CPU compatibility
Hi, Wido has given a talk "How to Re-use Old Hardware with CloudStack. Saving Money and the Environment" in CCC 2023. If you are interested, please watch the video on https://www.youtube.com/watch?v=KAJCkC00tzQ (starts at 11:41) -Wei On Wed, Apr 10, 2024 at 5:49 PM R A wrote: > > Hi, > > is it also problematic migrating to different CPUs of same Family? For > example from Epyc 9654 to Epyc 9754 ? > > So you recommend to make a cluster for each CPU Type ? Can you define the > migration peer for hosts? For example having them all one cluster but define > somehow that migration should be done between hosts of same CPU? > > BR > > -Original Message- > From: Guto Veronezi > Sent: Mittwoch, 10. April 2024 00:14 > To: users@cloudstack.apache.org > Subject: Re: CPU compatibility > > Hello Steve, > > For CloudStack, it does not matter if you have hosts with different > processors; however, this is a recommendation regarding how virtualization > systems work; therefore, this discussion happens aside from CloudStack. > > When we are dealing with different processors, we are dealing with different > flags, instructions, clocks, and so on. For processors of the same family, > but of different generations, we can level the instructions to the lowest > common denominator (limit the instructions to the older generation); however, > it starts to get tricky when we are dealing with different families. For > instance, if you deploy a guest VM in a host with Xeon Silver and try to > migrate it to a Xeon Gold, the OS of your guest, which already knows the Xeon > Silver instructions, might not adapt to the instructions of the new host > (Xeon Gold). Therefore, in these cases, you will face problems in the guest > VM. > > If you are aware of the differences between the processors and that mixing > different types can cause problems, then you can create a cluster mixing > them; however, it is not recommended. > > For KVM, the parameter is defined in ACS; on the other hand, for XenServer > and VMware this kind of setup is done in the cluster in XenServer or vCenter. > > It is also important to bear in mind that, even though you level the > instruction sets between the different processors in the host operating > system, you might still suffer some issues due to clock differences when you > migrate a VM from a faster CPU to a slower CPU and vice versa. > > Best regards, > Daniel Salvador (gutoveronezi) > > On 09/04/2024 18:58, Wei ZHOU wrote: > > Hi, > > > > You can use a custom cpu model which is supported by both cpu processors. > > > > Please refer to > > https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/k > > vm.html#configure-cpu-model-for-kvm-guest-optional > > > > -Wei > > > > > > On Tuesday, April 9, 2024, S.Fuller wrote: > > > >> The Cloudstack Install Guide has the following statement - "All hosts > >> within a cluster must be homogenous. The CPUs must be of the same > >> type, count, and feature flags" > >> > >> Obviously this means we can't mix Intel and AMD CPUs within the same > >> cluster. However, for a cluster with Intel CPUs, how much if any > >> leeway is there within this statement? If I have two 20 Core Xeon > >> Silver 4316 CPUs on one host and two 20 Core Xeon Silver 4416 CPUs > >> in another, is that close enough? I'm looking to add capacity to an > >> existing cluster, and am trying to figure out how "picky" Cloudstack is > >> about this. > >> > >> > >> > >> Steve Fuller > >> steveful...@gmail.com > >>
CloudStack managing KVM Hypervisors on multiple architectures?
Can a CloudStack instance running on x86 manage deployments on both x86 and Raspberry Pi (or any other archs)? I am not sure how it will affect management SystemVMs given the different archs in the mix? Any pointers are greatly appreciated. Thanks!
RE: CPU compatibility
Hi, is it also problematic migrating to different CPUs of same Family? For example from Epyc 9654 to Epyc 9754 ? So you recommend to make a cluster for each CPU Type ? Can you define the migration peer for hosts? For example having them all one cluster but define somehow that migration should be done between hosts of same CPU? BR -Original Message- From: Guto Veronezi Sent: Mittwoch, 10. April 2024 00:14 To: users@cloudstack.apache.org Subject: Re: CPU compatibility Hello Steve, For CloudStack, it does not matter if you have hosts with different processors; however, this is a recommendation regarding how virtualization systems work; therefore, this discussion happens aside from CloudStack. When we are dealing with different processors, we are dealing with different flags, instructions, clocks, and so on. For processors of the same family, but of different generations, we can level the instructions to the lowest common denominator (limit the instructions to the older generation); however, it starts to get tricky when we are dealing with different families. For instance, if you deploy a guest VM in a host with Xeon Silver and try to migrate it to a Xeon Gold, the OS of your guest, which already knows the Xeon Silver instructions, might not adapt to the instructions of the new host (Xeon Gold). Therefore, in these cases, you will face problems in the guest VM. If you are aware of the differences between the processors and that mixing different types can cause problems, then you can create a cluster mixing them; however, it is not recommended. For KVM, the parameter is defined in ACS; on the other hand, for XenServer and VMware this kind of setup is done in the cluster in XenServer or vCenter. It is also important to bear in mind that, even though you level the instruction sets between the different processors in the host operating system, you might still suffer some issues due to clock differences when you migrate a VM from a faster CPU to a slower CPU and vice versa. Best regards, Daniel Salvador (gutoveronezi) On 09/04/2024 18:58, Wei ZHOU wrote: > Hi, > > You can use a custom cpu model which is supported by both cpu processors. > > Please refer to > https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/k > vm.html#configure-cpu-model-for-kvm-guest-optional > > -Wei > > > On Tuesday, April 9, 2024, S.Fuller wrote: > >> The Cloudstack Install Guide has the following statement - "All hosts >> within a cluster must be homogenous. The CPUs must be of the same >> type, count, and feature flags" >> >> Obviously this means we can't mix Intel and AMD CPUs within the same >> cluster. However, for a cluster with Intel CPUs, how much if any >> leeway is there within this statement? If I have two 20 Core Xeon >> Silver 4316 CPUs on one host and two 20 Core Xeon Silver 4416 CPUs >> in another, is that close enough? I'm looking to add capacity to an >> existing cluster, and am trying to figure out how "picky" Cloudstack is >> about this. >> >> >> >> Steve Fuller >> steveful...@gmail.com >>
Re: Repositories
Hi Rohit, Right, my question was mostly because of https://github.com/apache/cloudstack/issues/8727. Still trying to find as to why mine looks different, I’ve use the download.cloudstack ones for it, I know it’s not a caching issue since even on a brand-new Ubuntu desktop vm it shows the same for me. I haven’t tried building my own debs from source to see what I would see there, but I doubt it would look that different. -- Jimmy Van: Rohit Yadav Datum: woensdag, 10 april 2024 om 15:28 Aan: users@cloudstack.apache.org Onderwerp: Re: Repositories Hi Jimmy, They both are largely hosting the same upstream packages with some differences. Those on the download.cloudstack.org are built and maintained by the wider community largely comprising of the ACS PMC members (many of whom are ShapeBlue colleagues). The ShapeBlue packages are built, maintained and hosted by the sponsoring (employee-owned) company and always ships full builds of CloudStack that includes non-oss components such as support for VMware and we also ship customer patches for fixes and improvements on top of upstream releases which can't make community release fast enough as community release processes take time and due diligence, but even those make upstream releases eventually (I.e. we don't fork CloudStack). SB patch releases are published publicly here https://github.com/shapeblue/cloudstack/releases that any user can audit and use/benefit. ShapeBlue customers are notified privately when we ship those as part of our support offerings (such as SB-led proactive patches and emergency patches/hotfixes). Regards. Regards. From: Jimmy Huybrechts Sent: Wednesday, April 10, 2024 3:03:04 PM To: users@cloudstack.apache.org Subject: Repositories Hi, I’m wondering, as I know there are 2 repositories I know of, do they have the exact same packages (outside the name). http://packages.shapeblue.com/cloudstack/upstream/debian/4.19 https://download.cloudstack.org/ubuntu jammy 4.19 -- Jimmy
Re: Repositories
Hi Jimmy, They both are largely hosting the same upstream packages with some differences. Those on the download.cloudstack.org are built and maintained by the wider community largely comprising of the ACS PMC members (many of whom are ShapeBlue colleagues). The ShapeBlue packages are built, maintained and hosted by the sponsoring (employee-owned) company and always ships full builds of CloudStack that includes non-oss components such as support for VMware and we also ship customer patches for fixes and improvements on top of upstream releases which can't make community release fast enough as community release processes take time and due diligence, but even those make upstream releases eventually (I.e. we don't fork CloudStack). SB patch releases are published publicly here https://github.com/shapeblue/cloudstack/releases that any user can audit and use/benefit. ShapeBlue customers are notified privately when we ship those as part of our support offerings (such as SB-led proactive patches and emergency patches/hotfixes). Regards. Regards. From: Jimmy Huybrechts Sent: Wednesday, April 10, 2024 3:03:04 PM To: users@cloudstack.apache.org Subject: Repositories Hi, I’m wondering, as I know there are 2 repositories I know of, do they have the exact same packages (outside the name). http://packages.shapeblue.com/cloudstack/upstream/debian/4.19 https://download.cloudstack.org/ubuntu jammy 4.19 -- Jimmy
Re: New PMC member: Slavka Peleva
Welcome aboard Slavka! Regards. From: Kiran Chavala Sent: Wednesday, April 10, 2024 6:16:00 PM To: users@cloudstack.apache.org ; d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva Congratulations Slavka! Regards Kiran From: Nicolas Vazquez Date: Wednesday, 10 April 2024 at 6:01 PM To: users@cloudstack.apache.org , d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva Congratulations Slavka! Regards, Nicolas Vazquez From: Rene Peinthor Date: Wednesday, 10 April 2024 at 09:13 To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva :clap: Slavka! Cheers, Rene On Wed, Apr 10, 2024 at 2:04 PM Suresh Kumar Anaparti < sureshanapa...@apache.org> wrote: > Congratulations Slavka! > > Regards, > Suresh > > On Wed, Apr 10, 2024 at 4:41 PM Ivet Petrova > wrote: > > > Hello all, > > > > The Project Management Committee (PMC) for Apache CloudStack > > has invited Slavka Peleva to become a PMC member and we are pleased > > to announce that they have accepted. > > > > Slavka has contributed in the past and has shown effort to make the > > project run smoothly > > > > Please join me in congratulating Slavka! > > > > > > Best regards, > > > > > > > > > > >
Re: New PMC member: Slavka Peleva
Congratulations Slavka! Regards Kiran From: Nicolas Vazquez Date: Wednesday, 10 April 2024 at 6:01 PM To: users@cloudstack.apache.org , d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva Congratulations Slavka! Regards, Nicolas Vazquez From: Rene Peinthor Date: Wednesday, 10 April 2024 at 09:13 To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva :clap: Slavka! Cheers, Rene On Wed, Apr 10, 2024 at 2:04 PM Suresh Kumar Anaparti < sureshanapa...@apache.org> wrote: > Congratulations Slavka! > > Regards, > Suresh > > On Wed, Apr 10, 2024 at 4:41 PM Ivet Petrova > wrote: > > > Hello all, > > > > The Project Management Committee (PMC) for Apache CloudStack > > has invited Slavka Peleva to become a PMC member and we are pleased > > to announce that they have accepted. > > > > Slavka has contributed in the past and has shown effort to make the > > project run smoothly > > > > Please join me in congratulating Slavka! > > > > > > Best regards, > > > > > > > > > > >
Re: New PMC member: Slavka Peleva
Congratulations Slavka! Regards, Nicolas Vazquez From: Rene Peinthor Date: Wednesday, 10 April 2024 at 09:13 To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva :clap: Slavka! Cheers, Rene On Wed, Apr 10, 2024 at 2:04 PM Suresh Kumar Anaparti < sureshanapa...@apache.org> wrote: > Congratulations Slavka! > > Regards, > Suresh > > On Wed, Apr 10, 2024 at 4:41 PM Ivet Petrova > wrote: > > > Hello all, > > > > The Project Management Committee (PMC) for Apache CloudStack > > has invited Slavka Peleva to become a PMC member and we are pleased > > to announce that they have accepted. > > > > Slavka has contributed in the past and has shown effort to make the > > project run smoothly > > > > Please join me in congratulating Slavka! > > > > > > Best regards, > > > > > > > > > > >
Re: New PMC member: Slavka Peleva
:clap: Slavka! Cheers, Rene On Wed, Apr 10, 2024 at 2:04 PM Suresh Kumar Anaparti < sureshanapa...@apache.org> wrote: > Congratulations Slavka! > > Regards, > Suresh > > On Wed, Apr 10, 2024 at 4:41 PM Ivet Petrova > wrote: > > > Hello all, > > > > The Project Management Committee (PMC) for Apache CloudStack > > has invited Slavka Peleva to become a PMC member and we are pleased > > to announce that they have accepted. > > > > Slavka has contributed in the past and has shown effort to make the > > project run smoothly > > > > Please join me in congratulating Slavka! > > > > > > Best regards, > > > > > > > > > > >
Re: New Committer: Kiran Chavala
Congrats, Kiran! You deserve it! Best regards, On 9 Apr 2024, at 10:59, Nischal P wrote: Congratulations Kiran! On Tue, Apr 9, 2024 at 1:07 PM Harikrishna Patnala < harikrishna.patn...@shapeblue.com> wrote: Congratulations Kiran, well deserved. Regards, Harikrishna From: Rohit Yadav Sent: Tuesday, April 9, 2024 11:15 AM To: dev Subject: New Committer: Kiran Chavala The Project Management Committee (PMC) for Apache CloudStack has invited Kiran Chavala (kiranchavala) to become a committer and we are pleased to announce that they have accepted. Kiran has been a long time CloudStack contributor and has created over a hundred issues on Github. Being a committer enables easier contribution to the project and enable better productivity. Please join me in congratulating Kiran! Regards.
Re: New PMC member: Slavka Peleva
Congratulations Slavka! Regards, Suresh On Wed, Apr 10, 2024 at 4:41 PM Ivet Petrova wrote: > Hello all, > > The Project Management Committee (PMC) for Apache CloudStack > has invited Slavka Peleva to become a PMC member and we are pleased > to announce that they have accepted. > > Slavka has contributed in the past and has shown effort to make the > project run smoothly > > Please join me in congratulating Slavka! > > > Best regards, > > > > >
Re: New PMC member: Slavka Peleva
Congratulations Slavka! Regards, Pearl From: Daan Hoogland Sent: April 10, 2024 7:19 AM To: d...@cloudstack.apache.org ; slav...@apache.org Cc: users@cloudstack.apache.org Subject: Re: New PMC member: Slavka Peleva welcome aboard @slav...@apache.org On Wed, Apr 10, 2024 at 1:11 PM Ivet Petrova wrote: > > Hello all, > > The Project Management Committee (PMC) for Apache CloudStack > has invited Slavka Peleva to become a PMC member and we are pleased > to announce that they have accepted. > > Slavka has contributed in the past and has shown effort to make the > project run smoothly > > Please join me in congratulating Slavka! > > > Best regards, > > > > -- Daan
Re: New PMC member: Slavka Peleva
welcome aboard @slav...@apache.org On Wed, Apr 10, 2024 at 1:11 PM Ivet Petrova wrote: > > Hello all, > > The Project Management Committee (PMC) for Apache CloudStack > has invited Slavka Peleva to become a PMC member and we are pleased > to announce that they have accepted. > > Slavka has contributed in the past and has shown effort to make the > project run smoothly > > Please join me in congratulating Slavka! > > > Best regards, > > > > -- Daan
Fwd: New PMC member: Slavka Peleva
Hello all, The Project Management Committee (PMC) for Apache CloudStack has invited Slavka Peleva to become a PMC member and we are pleased to announce that they have accepted. Slavka has contributed in the past and has shown effort to make the project run smoothly Please join me in congratulating Slavka! Best regards,
Repositories
Hi, I’m wondering, as I know there are 2 repositories I know of, do they have the exact same packages (outside the name). http://packages.shapeblue.com/cloudstack/upstream/debian/4.19 https://download.cloudstack.org/ubuntu jammy 4.19 -- Jimmy
AW: Download the CSP - xcp-ng 8.2
There is no need any more to install software on XenServer or XCP-ng to get it integrated into Cloudstack. Just add the pool and Cloudstack will copy some files to all hosts. -Ursprüngliche Nachricht- Von: Embedded Gesendet: Mittwoch, 10. April 2024 09:07 An: users@cloudstack.apache.org Betreff: Re: Download the CSP - xcp-ng 8.2 Great, however do this still apply ? Download the CSP software onto the XenServer host from one of the following because the links are all dead. So does it still require this ? or a management agent installed like kvm? there is nothing clear in the documents On Wednesday 10 April 2024 01:51:24 PM (+07:00), Wei ZHOU wrote: > Hi, > > XCP-NG 8.2 is supported by CloudStack. > > Please refer to > https://docs.cloudstack.apache.org/en/4.19.0.1/releasenotes/compat.html#supported-hypervisor-versions > > > -Wei > > On Wed, Apr 10, 2024 at 7:51 AM Embedded wrote: > > > > is this still viable for XCP-NG 8.2 ? this documentation seems quite dated > > > > For XenServer 6.0.2, 6.0, 5.6 SP2: > > > > Download the CSP software onto the XenServer host from one of the following > > links: > > > > For XenServer 6.0.2: > > > > http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz > > > > For XenServer 5.6 SP2: > > > > http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz > > > > For XenServer 6.0: > > > > http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz > > > > Extract the file: > > > > # tar xf xenserver-cloud-supp.tgz > > Run the following script: > > > > # xe-install-supplemental-pack xenserver-cloud-supp.iso > > -- > > Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com > -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
Re: cloudstack 4.19 filesize mismatch
Thanks Wei, I did yum clean all + vm reboot and it worked. Alex On Tue, Apr 9, 2024 at 2:16 PM Wei ZHOU wrote: > Hi Alex, > > It works for me. > > Can you run "yum clean all" and retry ? > > -Wei > > On Tue, Apr 9, 2024 at 9:39 AM Alex Paul > wrote: > > > > Hi Community, > > > > Tried with centos 7, upgrade is failing > > > > > > cloudstack-management-4.18.1.1 FAILED > >==-] 23 MB/s | 1.8 GB 00:00:00 ETA > > > http://download.cloudstack.org/centos/7/4.18/cloudstack-management-4.18.1.1-1.el7.x86_64.rpm > : > > [Errno -1] Package does not match intended download. Suggestion: run yum > > --enablerepo=cloudstack clean metadata > > > > > > Cleaning yum metadata does not help > > > > Alex > > > > > > > > On Thu, Apr 4, 2024 at 2:52 AM Francisco Arencibia Quesada < > > arencibia.franci...@gmail.com> wrote: > > > > > Thanks a lot guys, now it works like a charm. > > > > > > > > > Kind regards > > > > > > On Wed, Apr 3, 2024 at 8:37 PM Wei ZHOU wrote: > > > > > > > Thanks a lot @Rohit Yadav > > > > > > > > I am able to upgrade from 4.18.0.0 to 4.18.1.1 then to 4.19.0.1 on > > > > both ubuntu and rocky8 hosts. > > > > > > > > -Wei > > > > > > > > > > > > > > > > On Wed, Apr 3, 2024 at 7:49 PM Rohit Yadav < > rohit.ya...@shapeblue.com> > > > > wrote: > > > > > > > > > > Thanks for checking - could you try again, I've purged the old cdn > > > > cache. It should be fixed now. > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Francisco Arencibia Quesada > > > > > Sent: Wednesday, April 3, 2024 21:55 > > > > > To: users@cloudstack.apache.org > > > > > Subject: Re: cloudstack 4.19 filesize mismatch > > > > > > > > > > now are failing both 4.18 and 4.19 > > > > > > > > > > Regards > > > > > > > > > > On Wed, Apr 3, 2024 at 6:13 PM Rohit Yadav < > rohit.ya...@shapeblue.com> > > > > > wrote: > > > > > > > > > > > Hi Francisco, > > > > > > > > > > > > The repo CDN is being updated, sometimes files are out of sync. > Can > > > you > > > > > > run apt-get update and try again and keep us posted if you still > face > > > > the > > > > > > issue. > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Francisco Arencibia Quesada > > > > > > > Sent: Wednesday, April 3, 2024 8:39:23 PM > > > > > > To: users@cloudstack.apache.org > > > > > > Subject: cloudstack 4.19 filesize mismatch > > > > > > > > > > > > Good morning guys, > > > > > > > > > > > > I want to report an issue with deb packages for 4.19 release. > > > > > > > > > > > > Please see details below: > > > > > > > > > > > > https://pastes.io/utzcxtyako-to check all output > > > > > > > > > > > > Get:1 https://download.cloudstack.org/ubuntu jammy/4.19 all > > > > > > cloudstack-common all 4.19.0.1 [117 MB] > > > > > > Err:1 https://download.cloudstack.org/ubuntu jammy/4.19 all > > > > > > cloudstack-common all 4.19.0.1 > > > > > > File has unexpected size (116922362 != 116919496). Mirror sync > in > > > > > > progress? [IP: 195.181.167.51 443] > > > > > > Hashes of expected file: > > > > > >- > > > > > > > > > > > > > > > > > > > > SHA512:00d5571a65ef8029ce668fe2f8769326253615a282e0c6b155410460e7b3d288b062b1d434962b98b26b2be764867010c42fcf39f6ebae68b1bc7e43ea523894 > > > > > >- > > > > > > > > > SHA256:1f0805bfe95351fe30b55999235fc0e398201d1e3131ad7fd1538ef1b7a144be > > > > > >- SHA1:496ff9dffbd6299d1efa0b1c788318fbb04c57fa [weak] > > > > > >- MD5Sum:f162ade7affd9f8a5b8f358e1674f25f [weak] > > > > > >- Filesize:116919496 [weak] > > > > > > Get:2 https://download.cloudstack.org/ubuntu jammy/4.19 all > > > > > > cloudstack-management all 4.19.0.1 [1441 MB] > > > > > > Err:2 https://download.cloudstack.org/ubuntu jammy/4.19 all > > > > > > cloudstack-management all 4.19.0.1 > > > > > > File has unexpected size (1440658214 != 1440655316). Mirror > sync in > > > > > > progress? [IP: 195.181.167.51 443] > > > > > > Hashes of expected file: > > > > > >- > > > > > > > > > > > > > > > > > > > > SHA512:352a5133cc06b5ca05b097b9dce9e7d670ec89b7602729a9557f69876fe9f8dba568e0008065535c7f3daed4651a97deb18be1849e8bc64459784ba0ed9e20b3 > > > > > >- > > > > > > > > > SHA256:2f2216acda05088ec39c0157c09e0169fa9b5d30dbeb15cb074e743785f5a6ab > > > > > >- SHA1:31a04c5f4b271d7bf4cb0919293b3df0fa27e4c1 [weak] > > > > > >- MD5Sum:f8ce84b0b14e6ef64d235e78ee2a8af6 [weak] > > > > > >- Filesize:1440655316 [weak] > > > > > > E: Failed to fetch > > > > > > > > > > > > > > > > > > > > https://download.cloudstack.org/ubuntu/dists/jammy/4.19/pool/cloudstack-common_4.19.0.1_all.deb > > > > > > File has unexpected size (116922362 != 116919496). Mirror sync > in > > > > > > progress? [IP: 195.181.167.51 443] > > > > > >Hashes of expected file: > > > > > > - > > > > > > > > > > > > > > > > > > > >
Re: Download the CSP - xcp-ng 8.2
Great, however do this still apply ? Download the CSP software onto the XenServer host from one of the following because the links are all dead. So does it still require this ? or a management agent installed like kvm? there is nothing clear in the documents On Wednesday 10 April 2024 01:51:24 PM (+07:00), Wei ZHOU wrote: > Hi, > > XCP-NG 8.2 is supported by CloudStack. > > Please refer to > https://docs.cloudstack.apache.org/en/4.19.0.1/releasenotes/compat.html#supported-hypervisor-versions > > > -Wei > > On Wed, Apr 10, 2024 at 7:51 AM Embedded wrote: > > > > is this still viable for XCP-NG 8.2 ? this documentation seems quite dated > > > > For XenServer 6.0.2, 6.0, 5.6 SP2: > > > > Download the CSP software onto the XenServer host from one of the following > > links: > > > > For XenServer 6.0.2: > > > > http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz > > > > For XenServer 5.6 SP2: > > > > http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz > > > > For XenServer 6.0: > > > > http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz > > > > Extract the file: > > > > # tar xf xenserver-cloud-supp.tgz > > Run the following script: > > > > # xe-install-supplemental-pack xenserver-cloud-supp.iso > > -- > > Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com > -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
AW: Manual fence KVM Host
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/declareHostAsDegraded.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 Moura Gesendet: Mittwoch, 10. April 2024 02:10 An: users@cloudstack.apache.org Betreff: Manual fence KVM Host hey guys! Is there any way to manually fence a KVM host and then automatically start the migration of VMs that have HA enabled?
Re: Download the CSP - xcp-ng 8.2
Hi, XCP-NG 8.2 is supported by CloudStack. Please refer to https://docs.cloudstack.apache.org/en/4.19.0.1/releasenotes/compat.html#supported-hypervisor-versions -Wei On Wed, Apr 10, 2024 at 7:51 AM Embedded wrote: > > is this still viable for XCP-NG 8.2 ? this documentation seems quite dated > > For XenServer 6.0.2, 6.0, 5.6 SP2: > > Download the CSP software onto the XenServer host from one of the following > links: > > For XenServer 6.0.2: > > http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz > > For XenServer 5.6 SP2: > > http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz > > For XenServer 6.0: > > http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz > > Extract the file: > > # tar xf xenserver-cloud-supp.tgz > Run the following script: > > # xe-install-supplemental-pack xenserver-cloud-supp.iso > -- > Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
