Hi,
Between ACS & System VMs 8250 is port used by default.
On ACS machine, simple commands like
netstat -plant or ss -nt gives you idea about ports and concerned IPs.
--
Makrand
On Thu, Aug 23, 2018 at 3:00 PM, Netlynker wrote:
> Hi,
>
> Where can I find information of network
Hi,
I seem to hit a limit while listing all volumes from the API with
cloudmonkey as it only lists the first 500 with the listall=true flag.
Does anyone know if there's a limit setting in either Cloudstack og
Cloudmonkey that i could be hitting? I had a quick search for both but
couldn't seem to
Thank you, Makrand.
On 8/27/2018 11:11 AM, Makrand wrote:
Hi Asai,
The Server offering with HA enabled will do trick. While launching the VM
just choose this SO. In case your previous SO was not ha enabled (and thus
VM) you can actually change the SO and relaunch VM. Just test it before on
one
CloudStack has a parameter for that. However, I think that you might be
able to set the page size via API as well during your command calls.
On Mon, Aug 27, 2018 at 5:04 AM, Jan-Arve Nygård
wrote:
> Hi,
>
> I seem to hit a limit while listing all volumes from the API with
> cloudmonkey as it
Hi Asai,
In the context of CloudStack your metadata is effectively in the CloudStack DB.
If you want to capture the point-in-time settings for the VMs in question you
would simply do a "virsh dumpxml " against the VM and capture this data
somehow. Keep in mind though it's not going to be
Both ways work Makrand - but I suggest you use the "restart with cleanup"
option. In 4.11 you will also find this option does a parallel startup /
shutdown of old/new VR, leading to less VR downtime.
Regards,
Dag Sonstebo
On 27/08/2018, 18:38, "Makrand" wrote:
Hi Dag,
For VRs
Hi Dag,
For VRs do destroy works in same fashion as of system VMs or just doing
clean network restart is only option for spinning new VR?
--
Makrand
On Mon, Aug 27, 2018 at 7:32 PM, Swen - swen.io wrote:
> Hi Alessandro,
>
> I can confirm Dag's way. We did this a few weeks ago and it worked
Hi Asai,
The Server offering with HA enabled will do trick. While launching the VM
just choose this SO. In case your previous SO was not ha enabled (and thus
VM) you can actually change the SO and relaunch VM. Just test it before on
one of the VMs.
The VMs with HA enabled will come back on its
OK, thanks, Dag.
I think I finally get it.
On 8/27/2018 2:47 AM, Dag Sonstebo wrote:
Hi Asai,
In the context of CloudStack your metadata is effectively in the CloudStack DB. If you want to
capture the point-in-time settings for the VMs in question you would simply do a "virsh
dumpxml "
Hi guys,
is there a way to migrate System VM and VR to another cluster?
I'm using XenServer with ACS4.9
I know that the only way is to put the cluster in maintenance mode but I
don't want to migrate existing instance, just VR and SVM.
Thank yuo
Hi Alessandro,
I can confirm Dag's way. We did this a few weeks ago and it worked perfectly.
You do have a short downtime, because the VR will be recreated.
Cu Swen
-Ursprüngliche Nachricht-
Von: Dag Sonstebo
Gesendet: Montag, 27. August 2018 15:41
An: users@cloudstack.apache.org
Hi Allessandro,
You can just *disable (as oppose to maintenance mode)* the hosts in the current
cluster, then destroy the system VMs - CloudStack will recreate them where it
can - i.e. on the other cluster where hosts are enabled. Please note disabling
a host just prevents VMs from starting on
12 matches
Mail list logo