[libvirt] [RFC] Memory controller exploitation in libvirt
Subject: [RFC] Memory controller exploitation in libvirt Memory CGroup is a kernel feature that can be exploited effectively in the current libvirt/qemu driver. Here is a shot at that. At present, QEmu uses memory ballooning feature, where the memory can be inflated/deflated as and when needed, co-operatively between the host and the guest. There should be some mechanism where the host can have more control over the guests memory usage. Memory CGroup provides features such as hard-limit and soft-limit for memory, and hard-limit for swap area. Design 1: Provide new API and XML changes for resource management = All the memory controller tunables are not supported with the current abstractions provided by the libvirt API. libvirt works on various OS. This new API will support GNU/Linux initially and as and when other platforms starts supporting memory tunables, the interface could be enabled for them. Adding following two function pointer to the virDriver interface. 1) domainSetMemoryParameters: which would take one or more name-value pairs. This makes the API extensible, and agnostic to the kind of parameters supported by various Hypervisors. 2) domainGetMemoryParameters: For getting current memory parameters Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Parameter list supported: MemoryHardLimits (memory.limits_in_bytes) - Maximum memory MemorySoftLimits (memory.softlimit_in_bytes) - Desired memory MemoryMinimumGaurantee - Minimum memory required (without this amount of memory, VM should not be started) SwapHardLimits (memory.memsw_limit_in_bytes) - Maximum swap SwapSoftLimits (Currently not supported by kernel) - Desired swap space Tunables memory.limit_in_bytes, memory.softlimit_in_bytes and memory.memsw_limit_in_bytes are provided by the memory controller in the Linux kernel. I am not an expert here, so just listing what new elements need to be added to the XML schema: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define Pros: * Support all the tunables exported by the kernel * More tunables can be added as and when required Cons: * Code changes would touch various levels * Might need to redefine(changing the scope) of existing memory API. Currently, domainSetMemory is used to set limit_in_bytes in LXC and memory ballooning in QEmu. While the domainSetMaxMemory is not defined in QEmu and in case of LXC it is setting the internal object's maxmem variable. Future: * Later on, CPU/IO/Network controllers related tunables can be added/enhanced along with the APIs/XML elements: CPUHardLimit CPUSoftLimit CPUShare CPUPercentage IO_BW_Softlimit IO_BW_Hardlimit IO_BW_percentage * libvirt-cim support for resource management Design 2: Reuse the current memory APIs in libvirt == Use memory.limit_in_bytes to tweak memory hard limits Init - Set the memory.limit_in_bytes to maximum mem. Claiming memory from guest: a) Reduce balloon size b) If the guest does not co-operate(How do we know?), reduce memory.limit_in_bytes. Allocating memory more than max memory: How to solve this? As we have already set the max balloon size. We can only play within this! Pros: * Few changes * Is not intrusive Cons: * SetMemory and SetMaxMemory usage is confusing. * SetMemory is too generic a name, it does not cover all the tunables. * Does not support memory softlimit * Does not have support to reserve the memory swap region * This solution is not extensible IMO, Design 1 is more generic and extensible for various memory tuneables. Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
* Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 11:53:27]: Subject: [RFC] Memory controller exploitation in libvirt Memory CGroup is a kernel feature that can be exploited effectively in the current libvirt/qemu driver. Here is a shot at that. At present, QEmu uses memory ballooning feature, where the memory can be inflated/deflated as and when needed, co-operatively between the host and the guest. There should be some mechanism where the host can have more control over the guests memory usage. Memory CGroup provides features such as hard-limit and soft-limit for memory, and hard-limit for swap area. Design 1: Provide new API and XML changes for resource management = All the memory controller tunables are not supported with the current abstractions provided by the libvirt API. libvirt works on various OS. This new API will support GNU/Linux initially and as and when other platforms starts supporting memory tunables, the interface could be enabled for them. Adding following two function pointer to the virDriver interface. 1) domainSetMemoryParameters: which would take one or more name-value pairs. This makes the API extensible, and agnostic to the kind of parameters supported by various Hypervisors. 2) domainGetMemoryParameters: For getting current memory parameters Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Does nparams imply setting several parameters together? Does bulk loading help? I would prefer splitting out the API if possible into virCgroupSetMemory() - already present in src/util/cgroup.c virCgroupGetMemory() - already present in src/util/cgroup.c virCgroupSetMemorySoftLimit() virCgroupSetMemoryHardLimit() virCgroupSetMemorySwapHardLimit() virCgroupGetStats() Parameter list supported: MemoryHardLimits (memory.limits_in_bytes) - Maximum memory MemorySoftLimits (memory.softlimit_in_bytes) - Desired memory Soft limits allows you to set memory limit on contention. MemoryMinimumGaurantee - Minimum memory required (without this amount of memory, VM should not be started) SwapHardLimits (memory.memsw_limit_in_bytes) - Maximum swap SwapSoftLimits (Currently not supported by kernel) - Desired swap space We *dont* support SwapSoftLimits in the memory cgroup controller with no plans to support it in the future either at this point. The semantics are just too hard to get right at the moment. Tunables memory.limit_in_bytes, memory.softlimit_in_bytes and memory.memsw_limit_in_bytes are provided by the memory controller in the Linux kernel. I am not an expert here, so just listing what new elements need to be added to the XML schema: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define I'd prefer a syntax that integrates well with what we currently have cgroup path.../path controller name../name soft limit.../ hard limit.../ /controller ... /cgroup But I am not an XML expert or an export in designing XML configurations. Pros: * Support all the tunables exported by the kernel * More tunables can be added as and when required Cons: * Code changes would touch various levels * Might need to redefine(changing the scope) of existing memory API. Currently, domainSetMemory is used to set limit_in_bytes in LXC and memory ballooning in QEmu. While the domainSetMaxMemory is not defined in QEmu and in case of LXC it is setting the internal object's maxmem variable. Future: * Later on, CPU/IO/Network controllers related tunables can be added/enhanced along with the APIs/XML elements: CPUHardLimit CPUSoftLimit CPUShare CPUPercentage IO_BW_Softlimit IO_BW_Hardlimit IO_BW_percentage * libvirt-cim support for resource management Design 2: Reuse the current memory APIs in libvirt == Use memory.limit_in_bytes to tweak memory hard limits Init - Set the memory.limit_in_bytes to maximum mem. Claiming memory from guest: a) Reduce balloon size b) If the guest does not co-operate(How do we know?), reduce memory.limit_in_bytes. This is a policy
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
On Tue, 24 Aug 2010 13:05:26 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 11:53:27]: Subject: [RFC] Memory controller exploitation in libvirt Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Does nparams imply setting several parameters together? Does bulk loading help? I would prefer splitting out the API if possible into Yes it helps, when parsing the parameters from the domain xml file, we can call this API and set them at once. BTW, it can also be called with one parameter if desired. virCgroupSetMemory() - already present in src/util/cgroup.c virCgroupGetMemory() - already present in src/util/cgroup.c virCgroupSetMemorySoftLimit() virCgroupSetMemoryHardLimit() virCgroupSetMemorySwapHardLimit() virCgroupGetStats() This is at the cgroup level(internal API) and will be implemented in the way that is suggested. The RFC should not be specific to cgroups. libvirt is supported on multiple OS and the above described APIs in the RFC are public API. SwapHardLimits (memory.memsw_limit_in_bytes) - Maximum swap SwapSoftLimits (Currently not supported by kernel) - Desired swap space We *dont* support SwapSoftLimits in the memory cgroup controller with no plans to support it in the future either at this point. The Ok. Tunables memory.limit_in_bytes, memory.softlimit_in_bytes and memory.memsw_limit_in_bytes are provided by the memory controller in the Linux kernel. I am not an expert here, so just listing what new elements need to be added to the XML schema: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define I'd prefer a syntax that integrates well with what we currently have cgroup path.../path controller name../name soft limit.../ hard limit.../ /controller ... /cgroup Again this is a libvirt domain xml file, IMO, it should not be cgroup specific. Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] Fix make check failures with RHEL-5 xen
When libvirt is configured using --with-rhel5-api, make check fails on a bunch of tests for xen driver. All check now pass regardless on rhel5-api. Jiri Denemark (3): xen tests: Fix missing type ioemu with rhel5-api xml2sexprtest: Remove graphics from unrelated tests xen tests: Fix PV-VFB tests with RHEL-5 API Thanks for the review, I pushed these patches. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] nodeinfotest: Print libvirt error on failure
If linuxNodeInfoCPUPopulate() fails, the test would just print FAILED which is not very informative. It's better to print the real error. --- tests/nodeinfotest.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) ACK. And I pushed this one too. Thanks. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
* Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 13:35:10]: On Tue, 24 Aug 2010 13:05:26 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 11:53:27]: Subject: [RFC] Memory controller exploitation in libvirt Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Does nparams imply setting several parameters together? Does bulk loading help? I would prefer splitting out the API if possible into Yes it helps, when parsing the parameters from the domain xml file, we can call this API and set them at once. BTW, it can also be called with one parameter if desired. virCgroupSetMemory() - already present in src/util/cgroup.c virCgroupGetMemory() - already present in src/util/cgroup.c virCgroupSetMemorySoftLimit() virCgroupSetMemoryHardLimit() virCgroupSetMemorySwapHardLimit() virCgroupGetStats() This is at the cgroup level(internal API) and will be implemented in the way that is suggested. The RFC should not be specific to cgroups. libvirt is supported on multiple OS and the above described APIs in the RFC are public API. I thought we were talking of cgroups in the QEMU driver for Linux. IMHO the generalization is too big. ESX for example, already abstracts their WLM/RM needs in their driver. SwapHardLimits (memory.memsw_limit_in_bytes) - Maximum swap SwapSoftLimits (Currently not supported by kernel) - Desired swap space We *dont* support SwapSoftLimits in the memory cgroup controller with no plans to support it in the future either at this point. The Ok. Tunables memory.limit_in_bytes, memory.softlimit_in_bytes and memory.memsw_limit_in_bytes are provided by the memory controller in the Linux kernel. I am not an expert here, so just listing what new elements need to be added to the XML schema: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define I'd prefer a syntax that integrates well with what we currently have cgroup path.../path controller name../name soft limit.../ hard limit.../ /controller ... /cgroup Again this is a libvirt domain xml file, IMO, it should not be cgroup specific. See the comment above. -- Three Cheers, Balbir -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
2010/8/24 Balbir Singh bal...@linux.vnet.ibm.com: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 13:35:10]: On Tue, 24 Aug 2010 13:05:26 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 11:53:27]: Subject: [RFC] Memory controller exploitation in libvirt Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Does nparams imply setting several parameters together? Does bulk loading help? I would prefer splitting out the API if possible into Yes it helps, when parsing the parameters from the domain xml file, we can call this API and set them at once. BTW, it can also be called with one parameter if desired. virCgroupSetMemory() - already present in src/util/cgroup.c virCgroupGetMemory() - already present in src/util/cgroup.c virCgroupSetMemorySoftLimit() virCgroupSetMemoryHardLimit() virCgroupSetMemorySwapHardLimit() virCgroupGetStats() This is at the cgroup level(internal API) and will be implemented in the way that is suggested. The RFC should not be specific to cgroups. libvirt is supported on multiple OS and the above described APIs in the RFC are public API. I thought we were talking of cgroups in the QEMU driver for Linux. IMHO the generalization is too big. ESX for example, already abstracts their WLM/RM needs in their driver. Yes the ESX driver allows to control ballooning through virDomainSetMemory and virDomainSetMaxMemory. ESX itself also allows to set what's called memoryMinGaurantee in the thread, but this is not exposed in libvirt. So you can control how much virtual memory a guest has (virDomainSetMaxMemory) and define and upper (virDomainSetMemory) and a lower (not exposed via libvirt) bound for the physical memory that the hypervisor should use to satisfy the virtual memory of a guest. ESX also allows to defines shares, a relative value that defines a priority between guests in case there is not enough physical memory to satisfy all guests, the remaining virtual memory is then satisfied by swapping at the hypervisor level. The same pattern applies to the virtual CPUs. There is an upper and a lower limit for the CPU allocation of a guest and a shares value to define priority in case of contention. All three are exposed using the virDomainSetSchedulerParameters API for ESX. Regarding the new elements proposed here: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define memoryHardLimit is already there and called memory, memorySoftLimit is also there and called currentMemory, memoryMinGaurantee is new. I'm not sure where swapHardLimit and swapSoftLimit apply, is that for swapping that the hypervisor level? Also keep in mind that there was a recent discussion about how to express ballooning and memory configuration in the domain XML config: https://www.redhat.com/archives/libvir-list/2010-August/msg00118.html Regarding future additions: CPUHardLimit CPUSoftLimit CPUShare CPUPercentage IO_BW_Softlimit IO_BW_Hardlimit IO_BW_percentage The CPU part of this is already possible via the virDomainSetSchedulerParameters API. But they aren't expressed in the domain XML config, maybe your suggesting to do this? The I/O part is in fact new, I think. In general when you want to extend the domain XML config make sure that you don't model it to closely based on a specific implementation like CGroup. Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] esx: Improve object-by-type lookup performance
2010/8/23 Daniel P. Berrange berra...@redhat.com: On Sat, Aug 21, 2010 at 07:02:03PM +0200, Matthias Bolte wrote: Instead of using one big traversal spec for lookup use a set of more fine grained traversal specs that are selected based on the actual needs of the lookup. This gives up to 20% speedup for certain operations like domain listing due to less HTTP(S) traffic. --- src/esx/esx_driver.c | 1 - src/esx/esx_vi.c | 223 +- src/esx/esx_vi.h | 16 ++-- 3 files changed, 121 insertions(+), 119 deletions(-) ACK Thanks, pushed. Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Allow chardev of type 'file' for UML domains.
2010/8/23 Daniel P. Berrange berra...@redhat.com: On Mon, Aug 23, 2010 at 01:25:50PM +0200, Soren Hansen wrote: Like the comment suggested, we just open the file and pass the file descriptor to uml. The input stream is set to null, since I couldn't find any useful way to actually use a file for input for a chardev and this also mimics what e.g. QEmu does internally. Signed-off-by: Soren Hansen so...@linux2go.dk --- src/uml/uml_conf.c | 31 ++- src/uml/uml_conf.h | 1 + src/uml/uml_driver.c | 10 +- 3 files changed, 36 insertions(+), 6 deletions(-) ACK, looks good now. I applied and pushed this patch. Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
On Tue, 24 Aug 2010 11:02:49 +0200, Matthias Bolte matthias.bo...@googlemail.com wrote: snip Yes the ESX driver allows to control ballooning through virDomainSetMemory and virDomainSetMaxMemory. ESX itself also allows to set what's called memoryMinGaurantee in the thread, but this is not exposed in libvirt. LXC driver is using virDomainSetMemory to set the memory hard limit while QEmu/ESX use them to change the ballooning. And as you said, ESX does support memoryMinGaurantee, we can get this exported in libvirt using this new API. Here I am trying to group all the memory related parameters into one single public API as we have in virDomainSetSchedulerParameters. Currently, the names are not conveying what they modify in the below layer and are confusing. So you can control how much virtual memory a guest has (virDomainSetMaxMemory) and define and upper (virDomainSetMemory) and a lower (not exposed via libvirt) bound for the physical memory that the hypervisor should use to satisfy the virtual memory of a guest. ESX also allows to defines shares, a relative value that defines a priority between guests in case there is not enough physical memory to satisfy all guests, the remaining virtual memory is then satisfied by swapping at the hypervisor level. The same pattern applies to the virtual CPUs. There is an upper and a lower limit for the CPU allocation of a guest and a shares value to define priority in case of contention. All three are exposed using the virDomainSetSchedulerParameters API for ESX. Regarding the new elements proposed here: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define memoryHardLimit is already there and called memory, memorySoftLimit is also there and called currentMemory, memoryMinGaurantee is new. Thats correct, I am aware of this. The names are misleading. Also, we can have all these under the memory element. Later we can add something like this: define name=resource element memory !-- All memory related tunables -- /element element cpu !-- All CPU related tunables -- /element element blkio !-- All Block IO related tunables -- /element element network !-- All network related tunables -- /element /define I'm not sure where swapHardLimit and swapSoftLimit apply, is that for swapping that the hypervisor level? Memory Cgroup provides the maximum swap a group of task can use. swapSoftLimit is not supported as Balbir said and they do not have plans to support it. We can drop this. Also keep in mind that there was a recent discussion about how to express ballooning and memory configuration in the domain XML config: https://www.redhat.com/archives/libvir-list/2010-August/msg00118.html I will have a look at this. Regarding future additions: CPUHardLimit CPUSoftLimit CPUShare CPUPercentage IO_BW_Softlimit IO_BW_Hardlimit IO_BW_percentage The CPU part of this is already possible via the virDomainSetSchedulerParameters API. But they aren't expressed in the domain XML config, maybe your suggesting to do this? Yes, thats correct for CPU. IO would need API as well as XML config changes. Does ESX also support Block IO bandwidth control? The I/O part is in fact new, I think. In general when you want to extend the domain XML config make sure that you don't model it to closely based on a specific implementation like CGroup. Sure Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
On Tue, Aug 24, 2010 at 11:53:27AM +0530, Nikunj A. Dadhania wrote: Subject: [RFC] Memory controller exploitation in libvirt Memory CGroup is a kernel feature that can be exploited effectively in the current libvirt/qemu driver. Here is a shot at that. At present, QEmu uses memory ballooning feature, where the memory can be inflated/deflated as and when needed, co-operatively between the host and the guest. There should be some mechanism where the host can have more control over the guests memory usage. Memory CGroup provides features such as hard-limit and soft-limit for memory, and hard-limit for swap area. Exposing the tunables is nice, but there is another related problem. We don't provide apps enough information to effectively use them. eg, they configure a guest with 500 MB of RAM. How much RAM does QEMU actually use. 500 MB + X MB more. We need to give apps an indication of what the 'X' overhead is. Some of it comes from the video RAM. Some is pure QEMU emulation overhead. Design 1: Provide new API and XML changes for resource management = All the memory controller tunables are not supported with the current abstractions provided by the libvirt API. libvirt works on various OS. This new API will support GNU/Linux initially and as and when other platforms starts supporting memory tunables, the interface could be enabled for them. Adding following two function pointer to the virDriver interface. 1) domainSetMemoryParameters: which would take one or more name-value pairs. This makes the API extensible, and agnostic to the kind of parameters supported by various Hypervisors. 2) domainGetMemoryParameters: For getting current memory parameters Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Parameter list supported: MemoryHardLimits (memory.limits_in_bytes) - Maximum memory MemorySoftLimits (memory.softlimit_in_bytes) - Desired memory MemoryMinimumGaurantee - Minimum memory required (without this amount of memory, VM should not be started) SwapHardLimits (memory.memsw_limit_in_bytes) - Maximum swap SwapSoftLimits (Currently not supported by kernel) - Desired swap space Tunables memory.limit_in_bytes, memory.softlimit_in_bytes and memory.memsw_limit_in_bytes are provided by the memory controller in the Linux kernel. I am not an expert here, so just listing what new elements need to be added to the XML schema: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define Pros: * Support all the tunables exported by the kernel * More tunables can be added as and when required Cons: * Code changes would touch various levels Not a problem. * Might need to redefine(changing the scope) of existing memory API. Currently, domainSetMemory is used to set limit_in_bytes in LXC and memory ballooning in QEmu. While the domainSetMaxMemory is not defined in QEmu and in case of LXC it is setting the internal object's maxmem variable. Yep, might need to clarify LXC a little bit. Future: * Later on, CPU/IO/Network controllers related tunables can be added/enhanced along with the APIs/XML elements: CPUHardLimit CPUSoftLimit CPUShare CPUPercentage IO_BW_Softlimit IO_BW_Hardlimit IO_BW_percentage We have APIs to cope with CPU tunables, but no persistent XML representation. We have nothing for IO * libvirt-cim support for resource management Design 2: Reuse the current memory APIs in libvirt == Use memory.limit_in_bytes to tweak memory hard limits Init - Set the memory.limit_in_bytes to maximum mem. Claiming memory from guest: a) Reduce balloon size b) If the guest does not co-operate(How do we know?), reduce memory.limit_in_bytes. Allocating memory more than max memory: How to solve this? As we have already set the max balloon size. We can only play within this! Pros: * Few changes * Is not intrusive Cons: * SetMemory and SetMaxMemory usage is confusing. * SetMemory is too generic a name, it does not cover all the tunables. * Does not support memory softlimit * Does not have support to reserve the memory swap region * This solution is not extensible IMO, Design 1 is more generic and extensible for
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
On Tue, Aug 24, 2010 at 01:05:26PM +0530, Balbir Singh wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 11:53:27]: Subject: [RFC] Memory controller exploitation in libvirt Memory CGroup is a kernel feature that can be exploited effectively in the current libvirt/qemu driver. Here is a shot at that. At present, QEmu uses memory ballooning feature, where the memory can be inflated/deflated as and when needed, co-operatively between the host and the guest. There should be some mechanism where the host can have more control over the guests memory usage. Memory CGroup provides features such as hard-limit and soft-limit for memory, and hard-limit for swap area. Design 1: Provide new API and XML changes for resource management = All the memory controller tunables are not supported with the current abstractions provided by the libvirt API. libvirt works on various OS. This new API will support GNU/Linux initially and as and when other platforms starts supporting memory tunables, the interface could be enabled for them. Adding following two function pointer to the virDriver interface. 1) domainSetMemoryParameters: which would take one or more name-value pairs. This makes the API extensible, and agnostic to the kind of parameters supported by various Hypervisors. 2) domainGetMemoryParameters: For getting current memory parameters Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Does nparams imply setting several parameters together? Does bulk loading help? I would prefer splitting out the API if possible into virCgroupSetMemory() - already present in src/util/cgroup.c virCgroupGetMemory() - already present in src/util/cgroup.c virCgroupSetMemorySoftLimit() virCgroupSetMemoryHardLimit() virCgroupSetMemorySwapHardLimit() virCgroupGetStats() Nope, we don't want cgroups exposed in the public API, since this has to be applicable to the VMWare and OpenVZ drivers too. Parameter list supported: MemoryHardLimits (memory.limits_in_bytes) - Maximum memory MemorySoftLimits (memory.softlimit_in_bytes) - Desired memory Soft limits allows you to set memory limit on contention. MemoryMinimumGaurantee - Minimum memory required (without this amount of memory, VM should not be started) SwapHardLimits (memory.memsw_limit_in_bytes) - Maximum swap SwapSoftLimits (Currently not supported by kernel) - Desired swap space We *dont* support SwapSoftLimits in the memory cgroup controller with no plans to support it in the future either at this point. The semantics are just too hard to get right at the moment. That's not a huge problem. Since we have many hypervisors to support in libvirt, I expect the set of tunables will expand over time, and not every hypervisor driver in libvirt will support every tunable. They'll just pick the tunables that apply to them. We can leave SwapSoftLimits out of the public API until we find a HV that needs it Tunables memory.limit_in_bytes, memory.softlimit_in_bytes and memory.memsw_limit_in_bytes are provided by the memory controller in the Linux kernel. I am not an expert here, so just listing what new elements need to be added to the XML schema: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define I'd prefer a syntax that integrates well with what we currently have cgroup path.../path controller name../name soft limit.../ hard limit.../ /controller ... /cgroup That is exposing far too much info about the cgroups implementation details. The XML representation needs to be decouple from the implementation. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
On Tue, Aug 24, 2010 at 03:17:44PM +0530, Nikunj A. Dadhania wrote: On Tue, 24 Aug 2010 11:02:49 +0200, Matthias Bolte matthias.bo...@googlemail.com wrote: snip Yes the ESX driver allows to control ballooning through virDomainSetMemory and virDomainSetMaxMemory. ESX itself also allows to set what's called memoryMinGaurantee in the thread, but this is not exposed in libvirt. LXC driver is using virDomainSetMemory to set the memory hard limit while QEmu/ESX use them to change the ballooning. And as you said, ESX does support memoryMinGaurantee, we can get this exported in libvirt using this new API. Here I am trying to group all the memory related parameters into one single public API as we have in virDomainSetSchedulerParameters. Currently, the names are not conveying what they modify in the below layer and are confusing. For historical design record, I think it would be good to write a short description of what memory tunables are available for each hypervisor, covering VMWare, OpenVZ, Xen, KVM and LXC (the latter both cgroups based). I do recall that OpenVZ in particular had a huge number of memory tunables. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
On Tue, 24 Aug 2010 10:59:52 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Aug 24, 2010 at 11:53:27AM +0530, Nikunj A. Dadhania wrote: Subject: [RFC] Memory controller exploitation in libvirt Memory CGroup is a kernel feature that can be exploited effectively in the current libvirt/qemu driver. Here is a shot at that. At present, QEmu uses memory ballooning feature, where the memory can be inflated/deflated as and when needed, co-operatively between the host and the guest. There should be some mechanism where the host can have more control over the guests memory usage. Memory CGroup provides features such as hard-limit and soft-limit for memory, and hard-limit for swap area. Exposing the tunables is nice, but there is another related problem. We don't provide apps enough information to effectively use them. eg, they configure a guest with 500 MB of RAM. How much RAM does QEMU actually use. 500 MB + X MB more. We need to give apps an indication of what the 'X' overhead is. Some of it comes from the video RAM. Some is pure QEMU emulation overhead. Can we cover them in memory statistics API, ie, domainGetMemoryParameters with parameter type MemoryUsage, MemoryOverhead? * Might need to redefine(changing the scope) of existing memory API. Currently, domainSetMemory is used to set limit_in_bytes in LXC and memory ballooning in QEmu. While the domainSetMaxMemory is not defined in QEmu and in case of LXC it is setting the internal object's maxmem variable. Yep, might need to clarify LXC a little bit. Sure, when domainSetMaxMemory is called in case of LXC, sets vm-def-maxmem (vm is of type virDomainObjPtr and def is of type virDomainDefPtr) if the newmaxmem is greater than current memory. domainSetMemory for LXC: Sets the memory cgroup file memory.limit_in_bytes if newmem being set is less than the maximum permissible VM memory(vm-def-maxmem) Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix off-by-1 in QEMU boot arg array handling
A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries
defined. When building the QEMU arg, each entry takes a
single byte. This means the array must be declared to be
VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the
trailing null
* src/qemu/qemu_conf.c: Fix off-by-1 boot arg array size
---
src/qemu/qemu_conf.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index aa34d63..7a37c70 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -3662,7 +3662,7 @@ int qemudBuildCommandLine(virConnectPtr conn,
{
int i;
char memory[50];
-char boot[VIR_DOMAIN_BOOT_LAST];
+char boot[VIR_DOMAIN_BOOT_LAST+1];
struct utsname ut;
int disableKQEMU = 0;
int enableKQEMU = 0;
--
1.7.2.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
On Tue, 24 Aug 2010 11:07:29 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Aug 24, 2010 at 03:17:44PM +0530, Nikunj A. Dadhania wrote: On Tue, 24 Aug 2010 11:02:49 +0200, Matthias Bolte matthias.bo...@googlemail.com wrote: snip Yes the ESX driver allows to control ballooning through virDomainSetMemory and virDomainSetMaxMemory. ESX itself also allows to set what's called memoryMinGaurantee in the thread, but this is not exposed in libvirt. LXC driver is using virDomainSetMemory to set the memory hard limit while QEmu/ESX use them to change the ballooning. And as you said, ESX does support memoryMinGaurantee, we can get this exported in libvirt using this new API. Here I am trying to group all the memory related parameters into one single public API as we have in virDomainSetSchedulerParameters. Currently, the names are not conveying what they modify in the below layer and are confusing. For historical design record, I think it would be good to write a short description of what memory tunables are available for each hypervisor, covering VMWare, OpenVZ, Xen, KVM and LXC (the latter both cgroups based). I do recall that OpenVZ in particular had a huge number of memory tunables. I will collect the info and update. Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix off-by-1 in QEMU boot arg array handling
On Tue, Aug 24, 2010 at 12:02:38PM +0100, Daniel P. Berrange wrote: A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries defined. When building the QEMU arg, each entry takes a single byte. This means the array must be declared to be VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the trailing null FYI, This bug was introduced by me 2 years ago during the conversion to common domain APIs. In 6385fe3edebf4593b6dc08eee086f73dcc71b43d. We already have a test case that covers this precise boundary condition, but it has never exhibited a problem, even under valgrind. In Fedora 15 rawhide though, there is more advanced GCC array bounds checking present and this causes a runtime abort in the test suite. Nice example of why running 'make check' in the RPM spec is good :-) Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Memory controller exploitation in libvirt
* Daniel P. Berrange berra...@redhat.com [2010-08-24 11:02:44]: On Tue, Aug 24, 2010 at 01:05:26PM +0530, Balbir Singh wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-08-24 11:53:27]: Subject: [RFC] Memory controller exploitation in libvirt Memory CGroup is a kernel feature that can be exploited effectively in the current libvirt/qemu driver. Here is a shot at that. At present, QEmu uses memory ballooning feature, where the memory can be inflated/deflated as and when needed, co-operatively between the host and the guest. There should be some mechanism where the host can have more control over the guests memory usage. Memory CGroup provides features such as hard-limit and soft-limit for memory, and hard-limit for swap area. Design 1: Provide new API and XML changes for resource management = All the memory controller tunables are not supported with the current abstractions provided by the libvirt API. libvirt works on various OS. This new API will support GNU/Linux initially and as and when other platforms starts supporting memory tunables, the interface could be enabled for them. Adding following two function pointer to the virDriver interface. 1) domainSetMemoryParameters: which would take one or more name-value pairs. This makes the API extensible, and agnostic to the kind of parameters supported by various Hypervisors. 2) domainGetMemoryParameters: For getting current memory parameters Corresponding libvirt public API: int virDomainSetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); int virDomainGetMemoryParamters (virDomainPtr domain, virMemoryParamterPtr params, unsigned int nparams); Does nparams imply setting several parameters together? Does bulk loading help? I would prefer splitting out the API if possible into virCgroupSetMemory() - already present in src/util/cgroup.c virCgroupGetMemory() - already present in src/util/cgroup.c virCgroupSetMemorySoftLimit() virCgroupSetMemoryHardLimit() virCgroupSetMemorySwapHardLimit() virCgroupGetStats() Nope, we don't want cgroups exposed in the public API, since this has to be applicable to the VMWare and OpenVZ drivers too. I am not talking about exposing these as public API, but be a part of src/util/cgroup.c and utilized by the qemu driver. It is good to abstract out the OS independent parts, but my concern was double exposure through API like driver-setMemory() that is currently used and the newer API. Parameter list supported: MemoryHardLimits (memory.limits_in_bytes) - Maximum memory MemorySoftLimits (memory.softlimit_in_bytes) - Desired memory Soft limits allows you to set memory limit on contention. MemoryMinimumGaurantee - Minimum memory required (without this amount of memory, VM should not be started) SwapHardLimits (memory.memsw_limit_in_bytes) - Maximum swap SwapSoftLimits (Currently not supported by kernel) - Desired swap space We *dont* support SwapSoftLimits in the memory cgroup controller with no plans to support it in the future either at this point. The semantics are just too hard to get right at the moment. That's not a huge problem. Since we have many hypervisors to support in libvirt, I expect the set of tunables will expand over time, and not every hypervisor driver in libvirt will support every tunable. They'll just pick the tunables that apply to them. We can leave SwapSoftLimits out of the public API until we find a HV that needs it Tunables memory.limit_in_bytes, memory.softlimit_in_bytes and memory.memsw_limit_in_bytes are provided by the memory controller in the Linux kernel. I am not an expert here, so just listing what new elements need to be added to the XML schema: define name=resource element memory element memoryHardLimit/ element memorySoftLimit/ element memoryMinGaurantee/ element swapHardLimit/ element swapSoftLimit/ /element /define I'd prefer a syntax that integrates well with what we currently have cgroup path.../path controller name../name soft limit.../ hard limit.../ /controller ... /cgroup That is exposing far too much info about the cgroups implementation details. The XML representation needs to be decouple from the implementation.
Re: [libvirt] [PATCH] Fix off-by-1 in QEMU boot arg array handling
On Tue, Aug 24, 2010 at 12:18:48PM +0100, Daniel P. Berrange wrote: On Tue, Aug 24, 2010 at 12:02:38PM +0100, Daniel P. Berrange wrote: A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries defined. When building the QEMU arg, each entry takes a single byte. This means the array must be declared to be VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the trailing null FYI, This bug was introduced by me 2 years ago during the conversion to common domain APIs. In 6385fe3edebf4593b6dc08eee086f73dcc71b43d. We already have a test case that covers this precise boundary condition, but it has never exhibited a problem, even under valgrind. In Fedora 15 rawhide though, there is more advanced GCC array bounds checking present and this causes a runtime abort in the test suite. Nice example of why running 'make check' in the RPM spec is good :-) There used to be a 'checker' version of gcc with specific patches for bound-checking a decade or so ago, good to see this coming to the main stream :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [BUG] Xen x86_64 needs PAE?
On Mon, Aug 09, 2010 at 02:20:42PM +0200, Philipp Hahn wrote: Hello, I tried to install Microsoft Windows 2008 Server R2 on an Amd64 host using Xen-3.4.3. The installation aborted with the following error message: Windows Boot Mager ... File: \windows\system32\boot\winload.exe Status: 0xc35a Info: Attempting to load a 64-bit application, however this CPU is not compatible with 64-bit mode. For testing I converted the libvirt-XML file to an Xen-Xm file using virsh domxml-to-native and started that file with xm create, which worked. Comparing the output of xm list -a of the broken libvirt- and the working xm-configuration I found several differences, especially with pae: Using xm create pae is set to 1, while with libvirt pae is set to 0. After adding the /domain/featues/pae node to libvirts XML domain file, Windows installed fine. If you can provide the 'xm' config file, the libvirt XML and the output of 'xm list --list $GUESTNAME' when the guest is succesfully running we can add a test case to validate this PAE setup fix the xen driver. Looking at virsh capabilities I get the following (abbreviated) output: capabilities guest os_typehvm/os_type arch name='i686' wordsize32/wordsize ... /arch features pae/ nonpae/ acpi default='on' toggle='yes'/ apic default='on' toggle='yes'/ /features /guest guest os_typehvm/os_type arch name='x86_64' wordsize64/wordsize ... /arch features acpi default='on' toggle='yes'/ apic default='on' toggle='yes'/ /features /guest /capabilities As you can see, neither pae/ nor nopae/ is listed for for the 64 bit Xen-Fv domain type, which makes it hard to automatically create a correct _and_ _working_ XML file for Xen-Fv-64 bit domains Looking at /sys/hypervisor/properties/capabilities I find the following capabilities reported by Xen xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 There's also no hvm-3.0-x86_64p which makes me wonder, if pae/ is the default for Xen-64 bit domains. If that is true, should libvirt add pae/ by default to the capabilities report, or should libvirt silently pass (pae 1) when pushing the XML domain description to Xend? Lookign at In 32-bit Xen, the pae flag indicates whether this is a 32bit PAE or non-PAE guest. In 64-bit Xen, the pae flag indicates whether the CPU exposed supports long mode. So if you don't set the PAE flag on 64-bit Xen, you get a 32-bit PAE guest. If you do set the PAE flag, you get a 64-bit guest. Yes, you read that right, not setting PAE, gets you a PAE enabled guest just with 32 instead of 64 bits :-) In terms of the domain XML design, the choice between 32 and 64 bits is intended to be done based on the arch field: os type arch='x86_64'... ... /os The pae flag in domain XML should be reflecting whether pae is enabled in the guest. The capabilities XML should be reporting whether the guest ABI includes the PAE flag or not. So I think the 32bit capabilities shouldn't have included nonpae/ there, and perhaps 64-bit should have had pae/. Ultimately though I think our mistake is in passing the pae flag from the domain XML, straight through to the hypervisor. I'm rather wary of changing this, because of the risk of regressions, but if you can supply the 3 files I asked for above, we can investigate whether its feasible Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix dependancies for remote generated files
Very occasionally during a parallel make, dispatch.c would be compiled before the generated remote headers had been fully written. This would cause it to compile an empty union, and result in really wierd runtime bugs that are near impossible to diagnose. * daemon/Makefile.am: Fix remote build deps --- daemon/Makefile.am | 19 +++ 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index dbf0ac3..035c149 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -189,14 +189,17 @@ uninstall-data-polkit:: endif -remote.c: remote_dispatch_prototypes.h \ - remote_dispatch_table.h \ - remote_dispatch_args.h \ - remote_dispatch_ret.h \ - qemu_dispatch_prototypes.h \ - qemu_dispatch_table.h \ - qemu_dispatch_args.h \ - qemu_dispatch_ret.h +remote.c: \ + remote_dispatch_prototypes.h \ + remote_dispatch_table.h \ + qemu_dispatch_prototypes.h \ + qemu_dispatch_table.h + +remote.h: \ + remote_dispatch_args.h \ + remote_dispatch_ret.h \ + qemu_dispatch_args.h \ + qemu_dispatch_ret.h REMOTE_PROTOCOL = $(top_srcdir)/src/remote/remote_protocol.x QEMU_PROTOCOL = $(top_srcdir)/src/remote/qemu_protocol.x -- 1.7.2.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Ensure remote daemon unions are always non-zero length
If the remote daemon args/ret unions ever become zero length
(due to a build / Makefile bug) then bad stuff happens at
runtime. Add a compile time assertion to check for this kind
of problem
* daemon/remote.h: Ensure non-zero length unions
---
daemon/remote.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/daemon/remote.h b/daemon/remote.h
index fd8d381..1eb8386 100644
--- a/daemon/remote.h
+++ b/daemon/remote.h
@@ -30,18 +30,22 @@
typedef union {
# include remote_dispatch_args.h
} dispatch_args;
+verify(sizeof(dispatch_args) 0);
typedef union {
# include remote_dispatch_ret.h
} dispatch_ret;
+verify(sizeof(dispatch_ret) 0);
typedef union {
# include qemu_dispatch_args.h
} qemu_dispatch_args;
+verify(sizeof(qemu_dispatch_args) 0);
typedef union {
# include qemu_dispatch_ret.h
} qemu_dispatch_ret;
+verify(sizeof(qemu_dispatch_ret) 0);
--
1.7.2.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix off-by-1 in QEMU boot arg array handling
On 08/24/2010 05:02 AM, Daniel P. Berrange wrote: A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries defined. When building the QEMU arg, each entry takes a single byte. This means the array must be declared to be VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the trailing null * src/qemu/qemu_conf.c: Fix off-by-1 boot arg array size ACK. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Ensure remote daemon unions are always non-zero length
On 08/24/2010 07:21 AM, Daniel P. Berrange wrote: If the remote daemon args/ret unions ever become zero length (due to a build / Makefile bug) then bad stuff happens at runtime. Add a compile time assertion to check for this kind of problem * daemon/remote.h: Ensure non-zero length unions --- daemon/remote.h |4 1 files changed, 4 insertions(+), 0 deletions(-) ACK. It doesn't solve the parallel makefile race, but at least prevents us from proceeding to a broken executable. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [BUG] Xen x86_64 needs PAE?
Hello,
Am Dienstag 24 August 2010 14:12:24 schrieb Daniel P. Berrange:
If you can provide the 'xm' config file, the libvirt XML and the output
of 'xm list --list $GUESTNAME' when the guest is succesfully running we
can add a test case to validate this PAE setup fix the xen driver.
I attached 8 files:
1. xen-fv-w2k8.broken.xml is my initial file, which was used with 'virsh
define' + 'virsh start'.
2. xen-fv-w2k8.broken.xm was created using virsh domxml-to-native xen-xm
3. xen-fv-w2k8.broken.dump was created using xm list --long Windows2008r2_64
4. xen-fv-w2k8.fixed.xml with just 'pae/' added, 'virsh define' + 'virsh
start'.
5.-6. xen-fv-w2k8.fixed.{xm,dump} analog to above.
7. xen-fv-w2k8.clean.xm is without the pae=[01] line, so 'xm create' uses it's
default.
8. xen-fv-w2k8.clean.dump of 'xm list --long' after 'xm create'
501 r...@xen1=xen64:~ 0# xm info
host : xen1
release: 2.6.32-ucs11-xen-amd64
version: #1 SMP Sat Jul 31 07:49:13 UTC 2010
machine: x86_64
hw_caps:
078bf3ff:ebd3fbff::0010:2001:001d:001d:
virt_caps : hvm
xen_major : 3
xen_minor : 4
xen_extra : .3
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
In 64-bit Xen, the pae flag indicates whether the CPU exposed supports
long mode. So if you don't set the PAE flag on 64-bit Xen, you get a
32-bit PAE guest. If you do set the PAE flag, you get a 64-bit guest.
Yes, you read that right, not setting PAE, gets you a PAE enabled guest
just with 32 instead of 64 bits :-)
In terms of the domain XML design, the choice between 32 and 64 bits is
intended to be done based on the arch field:
os
type arch='x86_64'...
...
/os
That is what I expected as well: neither for Windows 2k8 nor for Linux would I
get a 64 bit guest. Only after adding the pae/ feature it worked.
Perhaps related: Setting arch=x86_64 for Xen domains never made a difference
for me: On the next virsh dumpxml that attribute was gone again making it
impossible to distinguish between 32 and 64 bit Xen domains.
The pae flag in domain XML should be reflecting whether pae is enabled
in the guest.
If I understand pae right, x86_64 used a page-table-layout very similar to
x86_32+pae, which makes doing the Virtual Memory mapping between host and
guests easy. For x86_32 without pae you'd need to do some heavy reshuffling,
because the page tables would be totally different.
I noticed the pae problem during my testing: guests started via xm
create/start ran fast, while guestss started via virsh start were very
slow. As soon as one non-pae-guest was running, the whole system got
unresponsive. It seemed to be related to the memory size, since running a
guest with 128M or 512M made a huge difference.
The capabilities XML should be reporting whether the guest ABI includes
the PAE flag or not. So I think the 32bit capabilities shouldn't have
included nonpae/ there, and perhaps 64-bit should have had pae/.
Ultimately though I think our mistake is in passing the pae flag from
the domain XML, straight through to the hypervisor. I'm rather wary of
changing this, because of the risk of regressions, but if you can supply
the 3 files I asked for above, we can investigate whether its feasible
The missing pae/ is translated to pae=0, which overwrites Xens default.
Because of that my code currently tests for xen on x86_64 and than always
adds pae/ to make it work. My expectation would be that the capabilities
XML should thus report pae/, if an application is supposed to add the
pae/ feature to get an 64 bit xen-fv domain.
Sincerely
Philipp
--
Philipp Hahn Open Source Software Engineer h...@univention.de
Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0
Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99
http://www.univention.de
Besuchen Sie unsere Praxis-Vorträge zu u...@school auf der FIT-ÖV
am 23.09.2010 im Haus der Wissenschaft in Bremen
(domain
(domid 7)
(on_crash destroy)
(uuid 23b87d01-7ba3-91f3-bf7b-d87b57a2893e)
(bootloader_args )
(vcpus 1)
(name Windows2008r2_64)
(on_poweroff destroy)
(on_reboot restart)
(cpus (()))
(bootloader )
(maxmem 512)
(memory 512)
(shadow_memory 5)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1282658955.15)
(cpu_time 47.385983162)
(online_vcpus 1)
(image
(hvm
(kernel )
(hpet 0)
(loader /usr/lib/xen/boot/hvmloader)
(serial none)
(xen_platform_pci 1)
(boot d)
(rtc_timeoffset 0)
(vpt_align 1)
(viridian 0)
(acpi 1)
(timer_mode 1)
Re: [libvirt] [PATCH] Fix dependancies for remote generated files
On 08/24/2010 07:21 AM, Daniel P. Berrange wrote:
Very occasionally during a parallel make, dispatch.c would
be compiled before the generated remote headers had been
fully written. This would cause it to compile an empty
union, and result in really wierd runtime bugs that are
s/wierd/weird/
near impossible to diagnose.
* daemon/Makefile.am: Fix remote build deps
---
daemon/Makefile.am | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index dbf0ac3..035c149 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -189,14 +189,17 @@ uninstall-data-polkit::
endif
-remote.c: remote_dispatch_prototypes.h \
- remote_dispatch_table.h \
- remote_dispatch_args.h \
- remote_dispatch_ret.h \
- qemu_dispatch_prototypes.h \
- qemu_dispatch_table.h \
- qemu_dispatch_args.h \
- qemu_dispatch_ret.h
+remote.c: \
+ remote_dispatch_prototypes.h \
+ remote_dispatch_table.h \
+ qemu_dispatch_prototypes.h \
+ qemu_dispatch_table.h
+
+remote.h: \
+ remote_dispatch_args.h \
+ remote_dispatch_ret.h \
+ qemu_dispatch_args.h \
+ qemu_dispatch_ret.h
I agree that the explicit remote.h dependencies are needed, since
remote.h is in turn included by dispatch.c.
I wonder if you're still missing something. Since both dispatch.c and
remote.c do #include's remote.h, shouldn't they both also list remote.h
(or remote.h's generated headers) as dependencies? On the other hand,
maybe you already get this for free from automake (which uses gcc's -M
options to pick up automatic dependency tracking based on #include
contents) - I do see remote.h listed in both
daemon/.deps/libvirtd-{remote,dispatch}.Po.
On the other hand, where is the action that updates the timestamp of
remote.[ch] to be newer than their generated .h counterparts? Without
that rule, then every run of make will see the generated files with a
newer timestamp than the version-controlled files, and insist on
regenerating the headers; whereas if you touched remote.[ch] after all
the generated headers are up-to-date, then successive make runs will see
that there is nothing left to do.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virsh: remove driver check from attach-disk command
Virsh shouldn't check for driver support but rather let the backend handled
this.
After removing the check, I can successfully attach file-based images to a qemu
VM with attach-disk.
% virsh attach-disk vm2 /images/test02.img vdc --driver qemu --type disk
--subdriver raw
Disk attached successfully
This command generates the following XML:
disk type='block' device='disk'
driver name='qemu' type='raw'/
source dev='/images/test02.img'/
target dev='vdc' bus='virtio'/
alias name='virtio-disk2'/
address type='pci' domain='0x' bus='0x00' slot='0x09'
function='0x0'/
/disk
Signed-off-by: Ryan Harper ry...@us.ibm.com
diff --git a/tools/virsh.c b/tools/virsh.c
index c0ee3ee..7bc33d8 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -8146,13 +8146,8 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
mode = vshCommandOptString(cmd, mode, NULL);
if (driver) {
-if (STREQ(driver, file) || STREQ(driver, tap)) {
+if (STREQ(driver, file) || STREQ(driver, tap))
isFile = 1;
-} else if (STRNEQ(driver, phy)) {
-vshError(ctl, _(No support for %s in command 'attach-disk'),
- driver);
-goto cleanup;
-}
}
if (mode) {
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] PHYP: Checking for NULL values when building new guest
memory and maxmem might be 0 when the user sets the to 0 in the domain XML. IMHO comparing 0 is cleaner here. I already submitted the patch v2 with this fix and I didn't understand exactly this comparison 0. Memory should be greater than zero, right? Hence, if memory 0, then ERROR. Right? If not, could you explain the reasons? Thanks, -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems Technology Group Mobile: +55 19 8135 0885 eot...@linux.vnet.ibm.com -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] docs: fix lxc examples
From: Serge Hallyn serge.hal...@canonical.com * docs/drvlxc.html.in: Use correct VM name, and mention that libvirt_lxc might be in an alternate location. --- [Reviving an old thread] On 06/16/2010 12:02 PM, Serge E. Hallyn wrote: Quoting Eric Blake (ebl...@redhat.com): On 06/07/2010 08:55 AM, Serge Hallyn wrote: Here is a new drvlxc.html.in file to make the first example work. I'll play with the second example next. Thanks for the sample text; it looked good to me on a first read. So when I get the second part of drvlxc.html.in updated, I'll send a git diff for the whole thing. I never saw a followup to this, but see no reason why it should not stop applying the fixes we do have. ACK to your original patch, and I'm pushing this: AUTHORS |1 + docs/drvlxc.html.in | 14 +++--- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/AUTHORS b/AUTHORS index 8b037a1..0521b3d 100644 --- a/AUTHORS +++ b/AUTHORS diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index cfcfdab..35058c4 100644 --- a/docs/drvlxc.html.in +++ b/docs/drvlxc.html.in @@ -35,6 +35,11 @@ start it using /pre p +In the lt;emulatorgt; element, be sure you specify the correct path +to libvirt_lxc, if it does not live in /usr/libexec on your system. +/p + +p The next example assumes there is a private root filesystem (perhaps hand-crafted using busybox, or installed from media, debootstrap, whatever) under /opt/vm-1-root: @@ -71,14 +76,17 @@ debootstrap, whatever) under /opt/vm-1-root: In both cases, you can define and start a container using:/p pre virsh --connect lxc:/// define v1.xml -virsh --connect lxc:/// start v1.xml +virsh --connect lxc:/// start vm1 /pre and then get a console using: pre -virsh --connect lxc:/// console v1 +virsh --connect lxc:/// console vm1 /pre pNow doing 'ps -ef' will only show processes in the container, for -instance. +instance. You can undefine it using /p +pre +virsh --connect lxc:/// undefine vm1 +/pre /body /html -- 1.7.2.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh create and virsh dumpxml certain code location
benian wrote:
Hi Jim,
Thanks for your reply!
I use xm create to create a tap2 disk and it works well
disk = [ 'tap2:vhd:/root/tapdisk/vhd-f12,hda,w']
but virsh dumpxml can't get anything about the disk
After i apply the patch, i can catch disk information by virsh dumpxml
but it seems that it only recognize tap only but not tap2
disk type='file' device='disk'
driver name='tap' type='vhd'/
source file='/root/tapdisk/vhd-f12'/
target dev='hda' bus='ide'/
/disk
Afterwards i try to use this xml file to virsh create VM and no
active disk is found.
Opps, I forgot to account for tap2 in functions that generate sexpr. V2
attached.
Regards,
Jim
From 6320c63d7c5077cf27050a567ca9d7ab7c17b189 Mon Sep 17 00:00:00 2001
From: Jim Fehlig jfeh...@novell.com
Date: Tue, 24 Aug 2010 11:26:15 -0600
Subject: [PATCH] Add blktap2 support to xend driver
Xen4.0 includes a new blktap2 implementation, which is specified
with 'tap2' prefix. AFAICT it's configuration syntax is identical
to blktap, with exception of 'tap2' vs 'tap' prefix. This patch
takes the simple approach of accepting and generating sexp
containing 'tap2' prefix.
V2: Also generate sexp containing tap2 device type
---
src/xen/xend_internal.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index d47c625..1870d5b 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -1386,7 +1386,8 @@ xenDaemonParseSxprDisks(virDomainDefPtr def,
but blktap disks ended up in a differently named
(device (tap )) block */
if (sexpr_lookup(node, device/vbd) ||
-sexpr_lookup(node, device/tap)) {
+sexpr_lookup(node, device/tap) ||
+sexpr_lookup(node, device/tap2)) {
char *offset;
const char *src = NULL;
const char *dst = NULL;
@@ -1397,6 +1398,10 @@ xenDaemonParseSxprDisks(virDomainDefPtr def,
src = sexpr_node(node, device/vbd/uname);
dst = sexpr_node(node, device/vbd/dev);
mode = sexpr_node(node, device/vbd/mode);
+} else if (sexpr_lookup(node, device/tap2)) {
+src = sexpr_node(node, device/tap2/uname);
+dst = sexpr_node(node, device/tap2/dev);
+mode = sexpr_node(node, device/tap2/mode);
} else {
src = sexpr_node(node, device/tap/uname);
dst = sexpr_node(node, device/tap/dev);
@@ -1444,7 +1449,8 @@ xenDaemonParseSxprDisks(virDomainDefPtr def,
src = offset + 1;
-if (STREQ (disk-driverName, tap)) {
+if (STREQ (disk-driverName, tap) ||
+STREQ (disk-driverName, tap2)) {
offset = strchr(src, ':');
if (!offset) {
virXendError(VIR_ERR_INTERNAL_ERROR,
@@ -5306,9 +5312,10 @@ xenDaemonFormatSxprDisk(virConnectPtr conn ATTRIBUTE_UNUSED,
/* Normally disks are in a (device (vbd ...)) block
* but blktap disks ended up in a differently named
* (device (tap )) block */
-if (def-driverName
-STREQ(def-driverName, tap)) {
+if (def-driverName STREQ(def-driverName, tap)) {
virBufferAddLit(buf, (tap );
+} else if (def-driverName STREQ(def-driverName, tap2)) {
+virBufferAddLit(buf, (tap2 );
} else {
virBufferAddLit(buf, (vbd );
}
@@ -5329,7 +5336,8 @@ xenDaemonFormatSxprDisk(virConnectPtr conn ATTRIBUTE_UNUSED,
if (def-src) {
if (def-driverName) {
-if (STREQ(def-driverName, tap)) {
+if (STREQ(def-driverName, tap) ||
+STREQ(def-driverName, tap2)) {
virBufferVSprintf(buf, (uname '%s:%s:%s'),
def-driverName,
def-driverType ? def-driverType : aio,
@@ -5928,6 +5936,9 @@ virDomainXMLDevID(virDomainPtr domain,
if (dev-data.disk-driverName
STREQ(dev-data.disk-driverName, tap))
strcpy(class, tap);
+else if (dev-data.disk-driverName
+STREQ(dev-data.disk-driverName, tap2))
+strcpy(class, tap2);
else
strcpy(class, vbd);
--
1.6.0.2
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Support virDomainAttachDevice and virDomainDetachDevice for disks in UML
2010/8/23 so...@linux2go.dk:
From: Soren Hansen so...@linux2go.dk
UML supports hot plugging and unplugging of various devices. This patch
exposes this functionality for disks.
Signed-off-by: Soren Hansen so...@linux2go.dk
---
src/uml/uml_driver.c | 239
+-
1 files changed, 235 insertions(+), 4 deletions(-)
diff --git a/src/uml/uml_driver.c b/src/uml/uml_driver.c
index 9cad7f1..a5c5d6a 100644
--- a/src/uml/uml_driver.c
+++ b/src/uml/uml_driver.c
@@ -1683,6 +1683,237 @@ cleanup:
}
+static int umlDomainAttachUmlDisk(struct uml_driver *driver,
+ virDomainObjPtr vm,
+ virDomainDiskDefPtr disk)
+{
+ int i, ret;
+ char *cmd = NULL;
+ char *reply = NULL;
+
+ for (i = 0 ; i vm-def-ndisks ; i++) {
+ if (STREQ(vm-def-disks[i]-dst, disk-dst)) {
+ umlReportError(VIR_ERR_OPERATION_FAILED,
+ _(target %s already exists), disk-dst);
+ return -1;
+ }
+ }
+
+ if (!disk-src) {
+ umlReportError(VIR_ERR_INTERNAL_ERROR,
+ %s, _(disk source path is missing));
+ goto error;
+ }
+
+ if (virAsprintf(cmd, config %s=%s, disk-dst, disk-src) 0) {
+ virReportOOMError();
+ return -1;
+ }
+
+ if (umlMonitorCommand(driver, vm, cmd, reply) 0)
+ goto error;
+
+ if (VIR_REALLOC_N(vm-def-disks, vm-def-ndisks+1) 0) {
+ virReportOOMError();
+ goto error;
+ }
+
+ if (ret 0)
+ goto error;
I was about to push this patch, but compile testing gave this error:
uml/uml_driver.c: In function 'umlDomainAttachUmlDisk':
uml/uml_driver.c:1729: error: 'ret' may be used uninitialized in this
function [-Wuninitialized]
I think if (ret 0) goto error; and int ret; can just be removed
completely from this function, but I would like have your ACK on this
before doing so.
Matthias
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Support virDomainAttachDevice and virDomainDetachDevice for disks in UML
On 08/24/2010 02:20 PM, Matthias Bolte wrote:
+static int umlDomainAttachUmlDisk(struct uml_driver *driver,
+ virDomainObjPtr vm,
+ virDomainDiskDefPtr disk)
+{
+int i, ret;
+char *cmd = NULL;
+char *reply = NULL;
+
+for (i = 0 ; i vm-def-ndisks ; i++) {
+if (STREQ(vm-def-disks[i]-dst, disk-dst)) {
+umlReportError(VIR_ERR_OPERATION_FAILED,
+ _(target %s already exists), disk-dst);
+return -1;
+}
+}
+
+if (!disk-src) {
+umlReportError(VIR_ERR_INTERNAL_ERROR,
+ %s, _(disk source path is missing));
+goto error;
+}
+
+if (virAsprintf(cmd, config %s=%s, disk-dst, disk-src) 0) {
+virReportOOMError();
+return -1;
+}
+
+if (umlMonitorCommand(driver, vm, cmd,reply) 0)
+goto error;
+
+if (VIR_REALLOC_N(vm-def-disks, vm-def-ndisks+1) 0) {
+virReportOOMError();
+goto error;
+}
+
+if (ret 0)
+goto error;
I was about to push this patch, but compile testing gave this error:
uml/uml_driver.c: In function 'umlDomainAttachUmlDisk':
uml/uml_driver.c:1729: error: 'ret' may be used uninitialized in this
function [-Wuninitialized]
I think if (ret 0) goto error; and int ret; can just be removed
completely from this function, but I would like have your ACK on this
before doing so.
ACK to that modification - I don't see any real use of ret in this function.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] Rename qemudShrinkDisks to virDomainDiskRemove and move to domain_conf.c
2010/8/23 Daniel P. Berrange berra...@redhat.com: On Mon, Aug 23, 2010 at 11:31:26AM +0200, so...@linux2go.dk wrote: From: Soren Hansen so...@linux2go.dk Other drivers will need this same functionality, so move it to up to conf/domain_conf.c and give it a more general name. Signed-off-by: Soren Hansen so...@linux2go.dk --- src/conf/domain_conf.c | 18 ++ src/conf/domain_conf.h | 2 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 20 ++-- 4 files changed, 23 insertions(+), 18 deletions(-) ACK, looks good. I applied and pushed this patch. Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Support virDomainAttachDevice and virDomainDetachDevice for disks in UML
On 24-08-2010 22:20, Matthias Bolte wrote: +if (ret 0) +goto error; I was about to push this patch, but compile testing gave this error: uml/uml_driver.c: In function 'umlDomainAttachUmlDisk': uml/uml_driver.c:1729: error: 'ret' may be used uninitialized in this function [-Wuninitialized] I think if (ret 0) goto error; and int ret; can just be removed completely from this function, but I would like have your ACK on this before doing so. Please do so. I haven't a clue where that came from, and due to the magic of having git rebased every time, I'll never know. :) -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Support virDomainAttachDevice and virDomainDetachDevice for disks in UML
2010/8/24 Soren Hansen so...@ubuntu.com: On 24-08-2010 22:20, Matthias Bolte wrote: + if (ret 0) + goto error; I was about to push this patch, but compile testing gave this error: uml/uml_driver.c: In function 'umlDomainAttachUmlDisk': uml/uml_driver.c:1729: error: 'ret' may be used uninitialized in this function [-Wuninitialized] I think if (ret 0) goto error; and int ret; can just be removed completely from this function, but I would like have your ACK on this before doing so. Please do so. I haven't a clue where that came from, and due to the magic of having git rebased every time, I'll never know. :) Okay, removed the offending code and pushed the result. Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Tests for Xen 4.0 blktap2
Tests for blktap2, pending ACK of blktap2 patch for xend driver discussed here https://www.redhat.com/archives/libvir-list/2010-August/msg00636.html Regards, Jim From c190013be39bf28da3e14225dacf777c75f4175a Mon Sep 17 00:00:00 2001 From: Jim Fehlig jfeh...@novell.com Date: Tue, 24 Aug 2010 15:39:29 -0600 Subject: [PATCH] Add tests for Xen's blktap2 implementation xml2sexpr and sexpr2xml tests for blktap2 --- .../sexpr2xml-disk-drv-blktap2-raw.sexpr |1 + .../sexpr2xml-disk-drv-blktap2-raw.xml | 27 tests/sexpr2xmltest.c |1 + .../xml2sexpr-disk-drv-blktap2-raw.sexpr |1 + .../xml2sexpr-disk-drv-blktap2-raw.xml | 23 + .../xml2sexprdata/xml2sexpr-disk-drv-blktap2.sexpr |1 + tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2.xml | 23 + tests/xml2sexprtest.c |2 + 8 files changed, 79 insertions(+), 0 deletions(-) create mode 100644 tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2.xml diff --git a/tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.sexpr b/tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.sexpr new file mode 100644 index 000..79bc9b1 --- /dev/null +++ b/tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.sexpr @@ -0,0 +1 @@ +(domain (domid 6)(name 'pvtest')(memory 420)(maxmem 420)(vcpus 2)(uuid '596a5d2171f48fb2e068e2386a5c413e')(on_poweroff 'destroy')(on_reboot 'destroy')(on_crash 'destroy')(image (linux (kernel '/var/lib/xen/vmlinuz.2Dn2YT')(ramdisk '/var/lib/xen/initrd.img.0u-Vhq')(args ' method=http://download.fedora.devel.redhat.com/pub/fedora/linux/core/test/5.91/x86_64/os ')))(device (tap2 (dev 'xvda')(uname 'tap2:aio:/root/some.img')(mode 'w' diff --git a/tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.xml b/tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.xml new file mode 100644 index 000..c6951de --- /dev/null +++ b/tests/sexpr2xmldata/sexpr2xml-disk-drv-blktap2-raw.xml @@ -0,0 +1,27 @@ +domain type='xen' id='6' + namepvtest/name + uuid596a5d21-71f4-8fb2-e068-e2386a5c413e/uuid + memory430080/memory + currentMemory430080/currentMemory + vcpu2/vcpu + os +typelinux/type +kernel/var/lib/xen/vmlinuz.2Dn2YT/kernel +initrd/var/lib/xen/initrd.img.0u-Vhq/initrd +cmdline method=http://download.fedora.devel.redhat.com/pub/fedora/linux/core/test/5.91/x86_64/os /cmdline + /os + clock offset='utc'/ + on_poweroffdestroy/on_poweroff + on_rebootdestroy/on_reboot + on_crashdestroy/on_crash + devices +disk type='file' device='disk' + driver name='tap2' type='aio'/ + source file='/root/some.img'/ + target dev='xvda' bus='xen'/ +/disk +console type='pty' + target type='xen' port='0'/ +/console + /devices +/domain diff --git a/tests/sexpr2xmltest.c b/tests/sexpr2xmltest.c index 297c30e..8c75c52 100644 --- a/tests/sexpr2xmltest.c +++ b/tests/sexpr2xmltest.c @@ -138,6 +138,7 @@ mymain(int argc, char **argv) DO_TEST(disk-block-shareable, disk-block-shareable, 2); DO_TEST(disk-drv-blktap-raw, disk-drv-blktap-raw, 2); DO_TEST(disk-drv-blktap-qcow, disk-drv-blktap-qcow, 2); +DO_TEST(disk-drv-blktap2-raw, disk-drv-blktap2-raw, 2); DO_TEST(curmem, curmem, 2); DO_TEST(net-routed, net-routed, 2); diff --git a/tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.sexpr b/tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.sexpr new file mode 100644 index 000..0293cc6 --- /dev/null +++ b/tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.sexpr @@ -0,0 +1 @@ +(vm (name 'pvtest')(memory 420)(maxmem 420)(vcpus 2)(uuid '596a5d21-71f4-8fb2-e068-e2386a5c413e')(on_poweroff 'destroy')(on_reboot 'destroy')(on_crash 'destroy')(image (linux (kernel '/var/lib/xen/vmlinuz.2Dn2YT')(ramdisk '/var/lib/xen/initrd.img.0u-Vhq')(args ' method=http://download.fedora.devel.redhat.com/pub/fedora/linux/core/test/5.91/x86_64/os ')))(device (tap2 (dev 'xvda')(uname 'tap2:aio:/root/some.img')(mode 'w' \ No newline at end of file diff --git a/tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.xml b/tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.xml new file mode 100644 index 000..0cc37cc --- /dev/null +++ b/tests/xml2sexprdata/xml2sexpr-disk-drv-blktap2-raw.xml @@ -0,0 +1,23 @@ +domain type='xen' id='15' + namepvtest/name + uuid596a5d2171f48fb2e068e2386a5c413e/uuid + os +typelinux/type +kernel/var/lib/xen/vmlinuz.2Dn2YT/kernel +initrd/var/lib/xen/initrd.img.0u-Vhq/initrd +cmdline
Re: [libvirt] virsh create and virsh dumpxml certain code location
Hi Jim, Thank 's your patch! After applying the V2 patch, guestVM with tap2 driver-name in xml can be created and works well!! disk type='file' device='disk' driver name='tap2' type='vhd'/ source file='/root/tapdisk/vhd-f12-2'/ target dev='hda' bus='ide'/ /disk But dumpxml to the corresponding guestVM still get driver name='tap' disk type='file' device='disk' driver name='tap' type='vhd'/ source file='/root/tapdisk/vhd-f12-2'/ target dev='hda' bus='ide'/ /disk I am trying to chase the variable def-driverName located in src/domain_conf.c:5452: virBufferVSprintf(buf, name='%s', def-driverName); to find out why dumpxml still get wrong name Any hints will be very helpful for me Thank you very much! Regards, Ben 2010/8/25 Jim Fehlig jfeh...@novell.com benian wrote: Hi Jim, Thanks for your reply! I use xm create to create a tap2 disk and it works well disk = [ 'tap2:vhd:/root/tapdisk/vhd-f12,hda,w'] but virsh dumpxml can't get anything about the disk After i apply the patch, i can catch disk information by virsh dumpxml but it seems that it only recognize tap only but not tap2 disk type='file' device='disk' driver name='tap' type='vhd'/ source file='/root/tapdisk/vhd-f12'/ target dev='hda' bus='ide'/ /disk Afterwards i try to use this xml file to virsh create VM and no active disk is found. Opps, I forgot to account for tap2 in functions that generate sexpr. V2 attached. Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
