[ kvm-Bugs-2055584 ] Guest hang after save restore or live migration
Bugs item #2055584, was opened at 2008-08-16 23:10 Message generated for change (Comment added) made by jiajun You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2055584group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: Guest hang after save restore or live migration Initial Comment: Against latest commit, kvm.git 37304c6f9ced347cf013bcd4bf808d6fd4fb6ce1 and userspace.git b7190d32817e01b7a7adb7a9ef69ad4b27af75d2, guest hang after save restore or live migration. The issue exists on both IA32pae and IA32e host. -- Comment By: Jiajun Xu (jiajun) Date: 2008-08-23 00:31 Message: Logged In: YES user_id=2142959 Originator: YES The issue is fixed in kvm.git 2e7c6c2408d04b19af639790d718ef9a39da8f7d. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2055584group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Weekly KVM Test report, kernel ce094fc0 ... userspace 55ff0bb ... -- One Issue Fixed
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git ce094fc0d25cb364bce6f854dffc6849876ab89 and kvm-userspace.git 55ff0bb298456450a81448200fea8f50246893b4. No new issue found this week and one issue fixed. All failed cases can pass by manual. One Issue Fixed: 1. Guest hang after save restore or live migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2055584group_id=180599 Two Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 Test environment Platform Woodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot guest with 1500M memory PASS 3. boot 4 same guest in parallel PASS 4. boot two windows xp guestPASS 5. boot linux and windows guest in parallel PASS 6. save/restore 32-bit HVM guests PASS 7. save/restore 32-bit HVM guests with 4 vcpus PASS 8. live migration 32-bit HVM guests PASS 9. live migration 32-bit HVM guests with 4 vcpus PASS 10. boot base kernel linux PASS 11. kernel build on SMP linux guestPASS 12. LTP on linux guest PASS 13. boot Windows 2000 without ACPI PASS 14. boot Windows 2000 with ACPI enabled PASS 15. boot Windows 2003 with ACPI enabled PASS 16. boot Windows xp with ACPI enabled PASS 17. boot Windows vista with ACPI enabled PASS 18. boot SMP Windows 2000 with ACPI enabled PASS 19. boot SMP Windows 2003 with ACPI enabled PASS 20. boot SMP Windows xp with ACPI enabled PASS 21. boot SMP Windows 2008 with ACPI enabled PASS IA32e: 1. boot 32-bit guest with 256M memory PASS 2. boot 64-bit guest with 256M memory PASS 3. boot 32-bit guest with 1500M memory PASS 4. boot 64-bit guest with 1500M memory PASS 5. boot 4G pae guest PASS 6. boot 4G 64-bit guest PASS 7. boot four 32-bit guest in parallel PASS 8. boot four 64-bit guest in parallel PASS 9. boot two 32-bit windows xp in parallel PASS 10. boot 32-bit linux and 32 bit windows guest in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 32-bit linux guests FAIL 13. save/restore 64-bit linux guests FAIL 14. save/restore 64-bit linux guests with 4 vcpus PASS 15. save/restore 32-bit linux guests with 4 vcpus PASS 16. live migration 64bit linux guests PASS 17. live migration 32bit linux guests PASS 18. live migration 64bit linux guests with 4 vcpus PASS 19. live migration 32bit linux guests with 4 vcpus PASS 20. boot 32-bit x-server PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on 32-bit linux guest OS PASS 24. LTP on 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit Windows 2000 without ACPIPASS 27. boot 32-bit Windows xp without ACPIPASS 28. boot 64-bit Windows xp with ACPI enabledPASS 29. boot 64-bit Windows vista with ACPI enabled PASS 30. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 31. boot 32-bit SMP windows 2003 with ACPI enabled PASS 32. boot 32-bit SMP Windows xp with ACPI enabledPASS 33. boot 64-bit SMP Windows vista with ACPI enabled
Re: [PATCH 2/2] KVM: Device assignemnt with VT-d
* On Friday 22 Aug 2008 23:48:42 Avi Kivity wrote:
Amit Shah wrote:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index d9ef7d3..2956e35 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -495,4 +495,6 @@ struct kvm_assigned_irq {
__u32 flags;
};
+#define KVM_DEV_ASSIGN_USE_VTD (1 1)
+
#endif
(1 0)?
I kept the 1st field reserved for no particular implementation in mind as of
now.
This is a userspace inteface, so use a generic name like iommu. We also
need a KVM_CAP so userspace can check whether an iommu is present or not.
We could have multiple hardware IOMMU implementations, like Intel's VT-d and
AMD's IOMMU.
Also, is KVM_CAP_foo needed for this? This is the only #define that'll be used
and we can simply do something like
#ifdef KVM_DEV_ASSIGN_USE_VTD
flags |= KVM_DEV_ASSIGN_USE_VTD
#endif
?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
* On Friday 22 Aug 2008 23:51:15 Avi Kivity wrote: Amit Shah wrote: The following two patches contain VT-d support for device assignment for KVM guests. The first patch contains the changes that are required to the generic VT-d code. The second patch contains the changes to KVM. I've updated the 2nd patch to use VT-d only when requested by a parameter on the command line, making it easier to support iommu with pvdma and multiple iommu types. The command line currently should be invoked as: -pcidevice dev=00:13.0,vtd=on You mean, iommu=on. I did mean vtd=on, since we'll also have AMD's iommu implementation here. So something like: -pcidevice dev=00:13.0,vtd=on,pvdma=on or -pcidevice dev=00:13.0,amd-iommu=on,pvdma=on or do you mean we should autodetect which IOMMU we have and then select the appropriate one instead of bothering the user with it? Hmm, that seems a better UI and also such startup scripts can be ported across architectures. Or rather dma=iommu dma=none (1:1 mapping, or dma-less devices, or I'm Feeling Lucky) dma=cooperative (paravirt) This looks much better! Once we have KVM_CAP_VTD, KVM_CAP_AMD_IOMMU and KVM_CAP_PVDMA, dma=iommu means use either of VTD or AMD, whichever one is available dma=none means I'm feeling lucky PVDMA will automatically get used if the guest has PVDMA support compiled in. Enabling/disabling pvdma would be a guest option rather than a host option, I think (host only exposes CAP_PVDMA). Is this ok? Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] KVM: Device assignemnt with VT-d
Amit Shah wrote:
* On Friday 22 Aug 2008 23:48:42 Avi Kivity wrote:
Amit Shah wrote:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index d9ef7d3..2956e35 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -495,4 +495,6 @@ struct kvm_assigned_irq {
__u32 flags;
};
+#define KVM_DEV_ASSIGN_USE_VTD (1 1)
+
#endif
(1 0)?
I kept the 1st field reserved for no particular implementation in mind as of
now.
Why?
This is a userspace inteface, so use a generic name like iommu. We also
need a KVM_CAP so userspace can check whether an iommu is present or not.
We could have multiple hardware IOMMU implementations, like Intel's VT-d and
AMD's IOMMU.
Not in userspace. Userspace sees either iommu or no iommu; it doesn't
care about the iommu model.
Also, is KVM_CAP_foo needed for this? This is the only #define that'll be used
and we can simply do something like
#ifdef KVM_DEV_ASSIGN_USE_VTD
flags |= KVM_DEV_ASSIGN_USE_VTD
#endif
?
That only detects if the headers have the flag, not if the kernel
actually supports it (and whether there is an iommu in the host). We
need run-time detection.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
Amit Shah wrote: * On Friday 22 Aug 2008 23:51:15 Avi Kivity wrote: Amit Shah wrote: The following two patches contain VT-d support for device assignment for KVM guests. The first patch contains the changes that are required to the generic VT-d code. The second patch contains the changes to KVM. I've updated the 2nd patch to use VT-d only when requested by a parameter on the command line, making it easier to support iommu with pvdma and multiple iommu types. The command line currently should be invoked as: -pcidevice dev=00:13.0,vtd=on You mean, iommu=on. I did mean vtd=on, since we'll also have AMD's iommu implementation here. So something like: -pcidevice dev=00:13.0,vtd=on,pvdma=on or -pcidevice dev=00:13.0,amd-iommu=on,pvdma=on or do you mean we should autodetect which IOMMU we have and then select the appropriate one instead of bothering the user with it? Hmm, that seems a better UI and also such startup scripts can be ported across architectures. Yes of course. Note there's no need for kvm to autodetect the iommu either; I won't let the amd iommu in without a proper abstraction via an iommu api. Or rather dma=iommu dma=none (1:1 mapping, or dma-less devices, or I'm Feeling Lucky) dma=cooperative (paravirt) This looks much better! Once we have KVM_CAP_VTD, KVM_CAP_AMD_IOMMU and KVM_CAP_PVDMA, Why KVM_CAP_VTD and KVM_CAP_AMD_IOMMU? Do they actually have differences? if so, the capabilities should report the differences as features, not as vendor identifiers. dma=iommu means use either of VTD or AMD, whichever one is available dma=none means I'm feeling lucky PVDMA will automatically get used if the guest has PVDMA support compiled in. Enabling/disabling pvdma would be a guest option rather than a host option, I think (host only exposes CAP_PVDMA). Is this ok? So long as there is no potential for performance or security impact, having pvdma turned on automatically is better. We could still have dma=noparavirt to disable it. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] KVM: Device assignemnt with VT-d
* On Saturday 23 Aug 2008 14:58:50 Avi Kivity wrote: Amit Shah wrote: Also, is KVM_CAP_foo needed for this? This is the only #define that'll be used and we can simply do something like #ifdef KVM_DEV_ASSIGN_USE_VTD flags |= KVM_DEV_ASSIGN_USE_VTD #endif ? That only detects if the headers have the flag, not if the kernel actually supports it (and whether there is an iommu in the host). We need run-time detection. Which means we expose KVM_CAP_IOMMU only if one was detected? How to do this correctly? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
* On Saturday 23 Aug 2008 15:03:46 Avi Kivity wrote: Amit Shah wrote: * On Friday 22 Aug 2008 23:51:15 Avi Kivity wrote: Amit Shah wrote: The following two patches contain VT-d support for device assignment for KVM guests. The first patch contains the changes that are required to the generic VT-d code. The second patch contains the changes to KVM. I've updated the 2nd patch to use VT-d only when requested by a parameter on the command line, making it easier to support iommu with pvdma and multiple iommu types. The command line currently should be invoked as: -pcidevice dev=00:13.0,vtd=on You mean, iommu=on. I did mean vtd=on, since we'll also have AMD's iommu implementation here. So something like: -pcidevice dev=00:13.0,vtd=on,pvdma=on or -pcidevice dev=00:13.0,amd-iommu=on,pvdma=on or do you mean we should autodetect which IOMMU we have and then select the appropriate one instead of bothering the user with it? Hmm, that seems a better UI and also such startup scripts can be ported across architectures. Yes of course. Note there's no need for kvm to autodetect the iommu either; I won't let the amd iommu in without a proper abstraction via an iommu api. Yes; we're going to have an API once the Intel IOMMU support goes in. Or rather dma=iommu dma=none (1:1 mapping, or dma-less devices, or I'm Feeling Lucky) dma=cooperative (paravirt) This looks much better! Once we have KVM_CAP_VTD, KVM_CAP_AMD_IOMMU and KVM_CAP_PVDMA, Why KVM_CAP_VTD and KVM_CAP_AMD_IOMMU? Do they actually have differences? if so, the capabilities should report the differences as features, not as vendor identifiers. Agreed. dma=iommu means use either of VTD or AMD, whichever one is available dma=none means I'm feeling lucky PVDMA will automatically get used if the guest has PVDMA support compiled in. Enabling/disabling pvdma would be a guest option rather than a host option, I think (host only exposes CAP_PVDMA). Is this ok? So long as there is no potential for performance or security impact, having pvdma turned on automatically is better. We could still have dma=noparavirt to disable it. So we fail the hypercalls once the guest tries to contact us? Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
On Fri, Aug 22, 2008 at 10:10:52AM +0300, Amit Shah wrote: The second patch contains the changes to KVM. I've updated the 2nd patch to use VT-d only when requested by a parameter on the command line, making it easier to support iommu with pvdma and multiple iommu types. The command line currently should be invoked as: -pcidevice dev=00:13.0,vtd=on Could you please send your changes as a seperate, follow-on patch? The original patch is complicated enough, and that way the authorship information does not get muddled further, and it's much easier to see what you changed. Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
* On Saturday 23 Aug 2008 15:27:47 Muli Ben-Yehuda wrote: On Fri, Aug 22, 2008 at 10:10:52AM +0300, Amit Shah wrote: The second patch contains the changes to KVM. I've updated the 2nd patch to use VT-d only when requested by a parameter on the command line, making it easier to support iommu with pvdma and multiple iommu types. The command line currently should be invoked as: -pcidevice dev=00:13.0,vtd=on Could you please send your changes as a seperate, follow-on patch? The original patch is complicated enough, and that way the authorship information does not get muddled further, and it's much easier to see what you changed. I already sent my patch in a separate mail. The authorship info and the commit log stays the same; just contains my signoff. A new patch based on our current discussion will have to be spun anyway. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote: The authorship info and the commit log stays the same; just contains my signoff. Actually, unless you add an explicit 'From:' header, the email From header is used by git as the author of the patch. Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
* On Saturday 23 Aug 2008 16:10:54 Muli Ben-Yehuda wrote: On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote: The authorship info and the commit log stays the same; just contains my signoff. Actually, unless you add an explicit 'From:' header, the email From header is used by git as the author of the patch. If you notice, Patch 1/2, VT-d one has the From: line set to Allen's name (as Ben had sent). The patch 2/2 was modified by me, so it gets my 'From'. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
On Sat, Aug 23, 2008 at 04:41:02PM +0530, Amit Shah wrote: * On Saturday 23 Aug 2008 16:10:54 Muli Ben-Yehuda wrote: On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote: The authorship info and the commit log stays the same; just contains my signoff. Actually, unless you add an explicit 'From:' header, the email From header is used by git as the author of the patch. If you notice, Patch 1/2, VT-d one has the From: line set to Allen's name (as Ben had sent). The patch 2/2 was modified by me, so it gets my 'From'. Hence my comment about muddled authorship information and why it was better to keep your changes as a separate patch. Anyway, moving this thread to more constructive avenues: I think you said you are planning to implement and submit Avi's dma=xxx suggestion, and also had an outstanding userspace patch? Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
* On Saturday 23 Aug 2008 17:41:32 Muli Ben-Yehuda wrote: On Sat, Aug 23, 2008 at 04:41:02PM +0530, Amit Shah wrote: * On Saturday 23 Aug 2008 16:10:54 Muli Ben-Yehuda wrote: On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote: The authorship info and the commit log stays the same; just contains my signoff. Actually, unless you add an explicit 'From:' header, the email From header is used by git as the author of the patch. If you notice, Patch 1/2, VT-d one has the From: line set to Allen's name (as Ben had sent). The patch 2/2 was modified by me, so it gets my 'From'. Hence my comment about muddled authorship information and why it was better to keep your changes as a separate patch. I don't know what you mean; isn't that the way patches flow? This is how collaboration is shown. Anyway, moving this thread to more constructive avenues: I think you said you are planning to implement and submit Avi's dma=xxx suggestion, and also had an outstanding userspace patch? Yes; both are in the baking oven. Amit. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] VT-d: changes to support KVM
On Friday, August 22, 2008 12:10 am Amit Shah wrote: From: Kay, Allen M [EMAIL PROTECTED] This patch extends the VT-d driver to support KVM [Ben: fixed memory pinning] Signed-off-by: Kay, Allen M [EMAIL PROTECTED] Signed-off-by: Weidong Han [EMAIL PROTECTED] Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED] Signed-off-by: Amit Shah [EMAIL PROTECTED] --- drivers/pci/dmar.c |4 +- drivers/pci/intel-iommu.c | 117 ++- drivers/pci/intel-iommu.h | 344 - drivers/pci/iova.c | 2 +- drivers/pci/iova.h | 52 --- include/linux/intel-iommu.h | 355 +++ include/linux/iova.h| 52 +++ 7 files changed, 523 insertions(+), 403 deletions(-) delete mode 100644 drivers/pci/intel-iommu.h delete mode 100644 drivers/pci/iova.h create mode 100644 include/linux/intel-iommu.h create mode 100644 include/linux/iova.h Assuming Mark is ok with this, I can put this part into linux-next... But you'll have to re-send to my personal account ([EMAIL PROTECTED]) since this one got whitespace mangled by Outlook/Exchange. Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
vmport: unknown command 13
After movong from KVM-72 to KVM-73 I do get the Notice vmport: unknown command 13 The Message appears on starting emulation. In an Netboot environment it does appear before booting from Network is asked. What might go wrong here? Elmar -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vmport: unknown command 13
Elmar Haneke wrote: After movong from KVM-72 to KVM-73 I do get the Notice vmport: unknown command 13 The Message appears on starting emulation. In an Netboot environment it does appear before booting from Network is asked. What might go wrong here? It's actually harmless; it's the Bochs BIOS trying to access the vmport function 13, which means give me your UUID. However, upstream Qemu (and hence, KVM) doesn't support this function, so that's where the error message comes from. If I understand it correctly, upstream Qemu now has suppressed this warning message, so the next time KVM syncs up, the message will disappear. Chris Lalancette -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Booting ESXi from within KVM
Having given up getting normal ESX booting from within KVM, I thought i'd give ESXi a go. PXE booting the hypervisor image outside of KVM I have working fine. When trying within KVM i had a few issues: The 'vmport' breaks ESXi, so for now I commented out vmport_init(); Then it complains about the CPU model_id, so I copy pasted it from my host. Now it gives an error that I don't quite understand: No pages allocated to Node 0 -- big mismatch between BIOS and SRAT memory maps, or MTRR error, or user removed all memory from a Node. Try checking memory or upgrading BIOS. I've tried removing some of the reported CPU capabilities (e.g. MTRR) from qemu/target-i386/helper.c, but unsure if that makes any difference. Command line: qemu-system-x86_64 -m 512 -std-vga -boot n -net nic -net tap -curses -k en-gb -localtime (Have tried a few including with/without ACPI) I've hardcoded the model_id to be AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (the host). Using an (almost) up to date kvm-userspace.git and its kvm kernel. How can I try to debug what ESXi is trying to ask for? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reserving CPU resources for a KVM guest
Yuksel Gunal wrote: Hi, I have been playing with KVM and was wondering about the following question: is there a resource configuration setting that would enforce a fraction of CPU to be guaranteed for a KVM guest? What I have on mind is something similar to the reservation setting on VMware (used to be called minimum CPU), which guarantees a number of CPU cycles to a VM. Also, any configuration setting similar to CPU/Memory Shares setting in VMware, which will kick in under contention for resources? VM is like any other process in Linux, you can use cpu controller, cgroups or any other scheduling option for your VMs. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
