vcpu socket configuration
Hello All We found in the process of use, when the vcpu in service_offering is a multiple of 6, vm cpu socket =vcpu/6, when vcpu is a multiple of 4, vm cpu socket=vcpu/4 Excuse me, why do we design this way? In my application scenario, there are restrictions on cpu socket, so I want to lock the socket to cpu socket=vcpu/2, what are the drawbacks? (Of course, I will exclude the singular vcpu) -Jerry
VM HA is turned on and off
Hello All I started VM HA through the calculation scheme. However, at work, it is sometimes necessary to "temporarily" shut down the HA for testing. My current practice is to directly modify cloud.ha_enabled=0; Is there any hidden danger in this operation? -Jerry
Re: VM HA is turned on and off
Hi Li, if that works for you, then that's all you need. You can always revert the change back AND test that it works fine (i.e. stop VM and see if ACS will start it again) If you have a need to just occasionally stop the VM from inside the OS - then, assuming you doing some manual work (i.e not automated) - you can always do as following, without changing the DB: 1. Start the OS shutdown sequence inside the VM 2. Quickly, while OS is still being shut down, request a shutdown via CloudStack (even if you are late for 1-2 seconds, it should still be good - the whole idea is to request GUI/API shutdown while ACS still sees the VM as running, even though it might be stopped already but the hypervisor has not yet reported that back to mgmt server) Doing things like that, means ACS will send another ACPI shutdown request to VM (which OS will actually ignore since it's ALREADY being shut down) and the VM will be stopped (since you initiated shutdown from inside the VM), and ACS will see that the VM is stopped, as expected after the API call. I have used this sometimes to hack around the HA enabled VMs. Best Andrija On Sun, 24 Nov 2019 at 15:44, li jerry wrote: > Hello All > > I started VM HA through the calculation scheme. > However, at work, it is sometimes necessary to "temporarily" shut down the > HA for testing. > My current practice is to directly modify cloud.ha_enabled=0; > > Is there any hidden danger in this operation? > > > -Jerry > > -- Andrija Panić
[GitHub] [cloudstack-primate] rhtyd commented on issue #29: Implement autogenerated actions forms with key-remapping
rhtyd commented on issue #29: Implement autogenerated actions forms with
key-remapping
URL:
https://github.com/apache/cloudstack-primate/issues/29#issuecomment-557952280
Fixed in e82f401d83a6d37c44d4310b35e4ec2b6d6e8278
config: action args remapping framework
This implements actions args remapping framework which allows developers
to specify how to provide/show args to the user/admin or how to override
based on the resource by means of (a) `value(record)` function, (b)
statically defined `api` name, (c) `options` array.
For example, in the config file:
```
args: ['id', 'virtualmachineid', 'mode'],
mapping: {
id: {
api: 'listIsos'
},
virtualmachineid: {
value: (record, params) => { return record.id }
},
mode: {
options: ['http', 'nfs', 'something else']
}
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [cloudstack-primate] rhtyd closed issue #29: Implement autogenerated actions forms with key-remapping
rhtyd closed issue #29: Implement autogenerated actions forms with key-remapping URL: https://github.com/apache/cloudstack-primate/issues/29 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Reply: VM HA is turned on and off
Thank you Andrija I have another problem with VM HA. Our scenario is KVM + ACS 4.11.2; When we found that the guest OS had a blue screen during the test, the VM did not detect that the VM failed and triggered HA. Is this normal? -邮件原件- 发件人: Andrija Panic 发送时间: 2019年11月25日 2:10 收件人: dev 抄送: us...@cloudstack.apache.org 主题: Re: VM HA is turned on and off Hi Li, if that works for you, then that's all you need. You can always revert the change back AND test that it works fine (i.e. stop VM and see if ACS will start it again) If you have a need to just occasionally stop the VM from inside the OS - then, assuming you doing some manual work (i.e not automated) - you can always do as following, without changing the DB: 1. Start the OS shutdown sequence inside the VM 2. Quickly, while OS is still being shut down, request a shutdown via CloudStack (even if you are late for 1-2 seconds, it should still be good - the whole idea is to request GUI/API shutdown while ACS still sees the VM as running, even though it might be stopped already but the hypervisor has not yet reported that back to mgmt server) Doing things like that, means ACS will send another ACPI shutdown request to VM (which OS will actually ignore since it's ALREADY being shut down) and the VM will be stopped (since you initiated shutdown from inside the VM), and ACS will see that the VM is stopped, as expected after the API call. I have used this sometimes to hack around the HA enabled VMs. Best Andrija On Sun, 24 Nov 2019 at 15:44, li jerry wrote: > Hello All > > I started VM HA through the calculation scheme. > However, at work, it is sometimes necessary to "temporarily" shut down > the HA for testing. > My current practice is to directly modify cloud.ha_enabled=0; > > Is there any hidden danger in this operation? > > > -Jerry > > -- Andrija Panić
