What's your vm provisioning time?

[tdtmusic2]

Hi everyone. I am wondering, how long does it normally take to deploy a vm via api, from the moment you hit deploy to the vm being in ready status. In my case it seems it takes quite a long time (3-4 minutes) and I am trying to see where the bottleneck is. Storage is very fast, 10G network, plenty of resources for the cs managers (3 of them deployed, in load balancing). What I noticed is it takes the most time to get the virtual router vm in ready state (1 - 1.5 minutes) and sometimes if I open the console on it I see an error about starting the apache http server, no idea if this is related to the deployment time. Deploying a vm with an existing network (so not new) takes considerably less, like 1 minute.

Thanks!

[JoaoJandre]

Hello @tdtmusic2,
The VR will only be created in the network once there is at least one VM in it. Thus, deploying a VM in a new network is always going to be slower than in a network that is already implemented, as the VR creation/boot/configuration takes time. The default system offerings for the VRs have a small number of CPU cores/speed/RAM, so the VR boot and configuration tends to take a lot of time.

If you want your VR to be faster to boot/configure, you could update the system offerings and give them more resources. However, you should be aware that for each isolated network and VPC you create, you'll have a new VR consuming your environment's resources, so you should take care when tweaking these configurations to avoid using too many resources for your system VMs.

[tdtmusic2]

I actually thought about this, if changing the default offering for the VR would make a difference. Do you have a suggestion here, in terms of cpu frequency and memory, that would really make a difference in provisioning time?

[JoaoJandre]

There are sadly no magic numbers that I could give you. I would test doubling the default values and see how it goes, and tweak it from there. Maybe put a somewhat big number for the VRs, like 2000MHz and 2048 MBs and then slowly bring those values down to see how the VR startup reacts and find your magic number.

Also, when you create network offerings, you can set the network as 'Persistent', this means that the VR will be created as soon as the network is defined, it will not wait for a VM to be created in it. Depending on your workflow, this might make your process faster. But beware that even if the network is unused (if all the VMs of the network are stopped for example), the VR will stay up.

Another point that I did not mention in my previous response is that for the VM deploy process (this includes the VR as well), if the template for that VM is not in the primary storage, it will be copied there first. So the first deploy of a VM with a new template on a primary storage that was not previously used for that template will also be slower.

[weizhouapache]

normally the first vm in a network or from a template will take longer time than usual.

to speed up

• use persistent network (isolated network), as @JoaoJandre said. so that the network will be implemented when start, it will not be shutdown even if there is no vms running.
• use "prepareTemplate" API to copy the templates to all or specific storage pools. However, if the template is not in use for a period, it will be removed from primary storage pools. It would be good to have another propertiy for template, similar as persistent network.