In KVM and cloudstack 4.1.1 VM clock speed is enforced by the service
offering set to the Guest VM.

For example, if I were to make a service offering of 1vCPU running at 3Ghz
and I only have a host running (at clock speed) of 2Ghz then cloudstack
will refuse the start of the VM.

You can see your processor statistics by running lshw -C CPU on the host,
the clock speed shown will be the actual host clock speed, regardless of
BIOS technologies which may throttle or boost the frequency at anytime
depending on load.

Marty

On Thursday, August 15, 2013, Pete Johnson wrote:

> I am planning on running a mix of service offerings, mostly small but
> their will be some pretty large database/processing servers using 2+ cores.
>  Won't know how large yet.
>
> - Pete
>
> -----Original Message----- From: Bradley Hieber
> Sent: Thursday, August 15, 2013 12:07 PM
> To: users@cloudstack.apache.org
> Subject: Re: Variable speed CPUs
>
> What is the service offering for the guest machines? The service offering
> governs the type of virtual CPU presented to the guest.
>
>
> On Thu, Aug 15, 2013 at 12:04 PM, Pete Johnson <pjohnso...@verizon.net
> >wrote:
>
>  Hi,
>> I have build a small private cloud for an R&D project for one of my
>> clients.  I have 3 hosts each with 16gb memory and 8 cores (AMD) per host.
>>    I’m using Cloudstack 4.1 and hosts are Ubuntu 12.04 w/KVM.   These CPUs
>> can vary clock speeds based on bios settings which is enabled.  The
>> Cloudstack dashboard correctly estimates the CPU clock speed at its MAX of
>> 3500 MHz.  But, when I log onto the guests and run virt-top it says
>> 1400MHz
>> which I assume is its current throttled down clock speed.  I am still
>> setting things up and have not had the chance to put the hosts under
>> enough
>> load to see of it clocks up.  My questions are:  Does Cloudstack support
>> viewable clocked CPUs in hosts? How does Cloudstack support variable
>> clocked hosts from a real-time capacity load perspective and a usage
>> perspective.
>> Thanks
>> Pete Johnson
>>
>
>
>
>
> --
> Brad
>

Reply via email to