Re: Tracking KVM development
Dne 21.3.2010 12:21, Thomas Løcke napsal(a):
> Any and all suggestions to keeping a healthy and stable KVM setup
> running is more than welcome.
Hi, I compile stable qemu-kvm releases from source and install under
/opt/qemu-kvm-${version}. With this setup I can run/test multiple
versions without messing up "any" distro..
HTH, Z.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reserve CPU cores for specific guests?
Neil Aggarwal napsal(a): > Hello: > > I don't think there is a way to do this with KVM, but > I figured I would ask: > > I want to be able to offer virtual private servers (VPSs) > to clients. I am going to use KVM for it. > > I would like to offer clients the option to buy either: > 1. A VPS which allows CPUs to be overcommitted. > 2. A VPS with a dedicated CPU core. > > So, for example, if I have a six core opteron, I might > sell: > 2 VPSs with a dedicated CPU core > 6 VPSs which allow overcommitted CPUs > > Since I need one core for the hypervisor, there would > need to be a way to say that it gets a dedicated core > plus the other 2 VPSs get a dedicated core. That > leaves 3 pooled cores to serve the 6 VPSs that > are allowed to overcommit. > > Is there a way to set up a pooled set of cores > for a given list of VPSs? > > I think I may have to use separate physical machine > for the VPSs with dedicated cores and the ones with > overcommitted ones. > > Thanks, > Neil > > -- > Neil Aggarwal, (281)846-8957, http://www.JAMMConsulting.com > CentOS 5.4 KVM VPS $55/mo, no setup fee, no contract, dedicated 64bit CPU > 1GB dedicated RAM, 40GB RAID storage, 500GB/mo premium BW, Zero downtime > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I think you can achieve that on some simple level DIY with taskset from util-linux(-ng). HTH, Z. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows guest CPU socket/core recognition
Brian Jackson napsal(a): > On Monday 17 August 2009 22:28:35 Zdenek Kaspar wrote: >> Hello everyone, >> >> I guess I'm not the first one who hit the problem with Microsoft's >> licensing model.. >> >> Nowadays the common single or dual quad-core workstation can't be fully >> used because it's limited by example: license up to 2 physical >> processors. Such VM acts like 4-way or 8-way machine. > > > Nine times out of ten, a single cpu guest is going to be a better option than > a smp/multie core guest. I've seen idle windows guests go from using nearly > 200% cpu for -smp 2 to ~5-10% for -smp 1. Unless your guest is actually using > all that cpu all the time, you're going to be wasting a decent amount of > cycles. Yes, without proper use it's waste. My guest is 64bit and represents node in computing cluster working on assigned jobs (not MPI etc..) >> Is there any way howto expose CPUs differently for this kind of problem? > > > There have been patches (from Andre Pryzwara and maybe others) to support > multi-core vs mult-socket smp. I will check these patches, thank you (and Dor Laor) for the hint! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Windows guest CPU socket/core recognition
Hello everyone, I guess I'm not the first one who hit the problem with Microsoft's licensing model.. Nowadays the common single or dual quad-core workstation can't be fully used because it's limited by example: license up to 2 physical processors. Such VM acts like 4-way or 8-way machine. Is there any way howto expose CPUs differently for this kind of problem? TIA, Z. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
