- Devel - libvirt List Archives

[libvirt] [PATCH RFC v3 0/6] support cpu bandwidth in libvirt
by Wen Congyang 19 Jul '11

19 Jul '11

TODO: 1. We create sub directory for each vcpu in cpu subsystem. So we should recalculate cpu.shares for each vcpu. Changelog: v3: fix some small bugs implement the simple way v2: almost rewrite the patchset to support to control each vcpu's bandwidth. Limit quota to [-1, 2^64/1000] at the schemas level. We will check it at cgroup level. Wen Congyang (6): Introduce the function virCgroupForVcpu cgroup: Implement cpu.cfs_period_us and cpu.cfs_quota_us tuning API Update XML Schema for new entries qemu: Implement period and quota tunable XML configuration and parsing qemu: Implement cfs_period and cfs_quota's modification doc: Add documentation for new cputune elements period and quota docs/formatdomain.html.in | 19 ++ docs/schemas/domain.rng | 26 +++- src/conf/domain_conf.c | 20 ++- src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 5 + src/qemu/qemu_cgroup.c | 127 +++++++++++ src/qemu/qemu_cgroup.h | 4 + src/qemu/qemu_driver.c | 259 ++++++++++++++++++++--- src/qemu/qemu_process.c | 4 + src/util/cgroup.c | 153 +++++++++++++- src/util/cgroup.h | 11 + tests/qemuxml2argvdata/qemuxml2argv-cputune.xml | 2 + 12 files changed, 596 insertions(+), 36 deletions(-)

3 22

[libvirt] [PATCH 00/10] network: physical device abstraction aka 'virtual switch'
by Laine Stump 19 Jul '11

19 Jul '11

This patch is in response to the following bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=643947 (RHEL) https://bugzilla.redhat.com/show_bug.cgi?id=636106 (upstream) It is functionally complete, and has gone through rudimentary testing for bridge networks (host bridge) and direct networks in bridge mode (macvtap). The patch series doesn't yet include updates to the domain and network XML documentation, though, so it isn't ready to push. I am sending it now to get feedback, both on the specifics of the code, as well as on how it is designed and how it works. I will be transferring info from my design document (at the end of this message) into the libvirt doc files during this week, and will have them ready for the V2 of the series that is sure to be requested. ***************** (The working design document) Network device abstraction aka virtual switch - V4 ================================================== The <interface> element of a guest's domain config in libvirt has a <source> element that describes what resources on a host will be used to connect the guest's network interface to the rest of the world. This is very flexible, allowing several different types of connection (virtual network, host bridge, direct macvtap connection to physical interface, qemu usermode, user-defined via an external script), but currently has the problem that unnecessary details of the host resources are embedded into the guest's config; if the guest is migrated to a different host, and that host has a different hardware or network config (or possibly the same hardware, but that hardware is currently in use by a different guest), the migration will fail. This document outlines a change to libvirt's network XML that will allow us to (optionally - old configs will remain valid) remove the host details from the guest's domain XML (which can move around from host to host) and place them in the network XML (which remains with a single host); the domain XML will then use existing config elements to associate each guest interface with a "network". The motivating use case for this change is the "direct" connection type (which uses macvtap for vepa and vnlink connections directly between a guest and a physical interface, rather than through a bridge), but it is applicable for all types of connection. (Another hopeful side effect of this change will be to make libvirt's network connection model easier to realize on non-Linux hypervisors (eg, VMWare ESX) and for other network technologies, such as openvswitch, VDE, and various VPN implementations). Background ========== (parts lifted from Dan Berrange's mail on this subject) Currently <network> supports 3 connectivity modes - Non-routed network, separate subnet (no <forward> element present) - Routed network, separate subnet with NAT (<forward mode='nat'/>) - Routed network, separate subnet (<forward mode='route'/>) Each of these is implemented in the existing network driver by creating a bridge device using brctl, and connecting the guest network interfaces via tap devices (a detail which, now that I've stated it, you should promptly forget!). All traffic between that bridge and the outside network is done via the host's IP routing stack (ie, there is no physical device directly connected to the bridge) In the future, these two additional routed modes might be useful: - Routed network, IP subnetting - Routed network, separate subnet with VPN The core goal of this proposal, though, is to replace type=bridge and type=direct from the domain interface XML with new types of <network> definitions so that the domain can just give "type='network'" and have all the necessary details filled in at runtime. This basically means we're adding several bridging modes (the submodes of "direct" have been flattened out here): - Bridged network, eth + bridge + tap - Bridged network, eth + macvtap + vepa - Bridged network, eth + macvtap + private - Bridged network, eth + macvtap + passthrough - Bridged network, eth + macvtap + bridge Another "future expansion" could be to add: - Bridged network, with VPN Likewise, support for other technologies, such as openvswitch and VDE would each be another entry on this list. (Dan also listed each of the above "+sriov" separately, but that ends up being handled in an orthogonal manner (by just specifying a pool of interfaces for a single network), so I'm only giving the abbreviated list) I. Changes to domain <interface> element ======================================== In many cases, the <interface> element of the domain XML will be identical to what is used now when connecting the interface to a libvirt-style virtual network: <interface type='network'> <source network='red-network'/> <mac address='xx:xx:xx:xx:xx:xx'/> </interface> Depending on the definition of the network "red-network" on the host the guest was started on / migrated to, this could be either a direct (macvtap) connection using one of the various direct modes (vepa/private/bridge/passthrough), a bridge (again, pointed to by the definition of 'red-network'), or a virtual network (using the current network definition syntax). This way the same guest could be migrated not only between macvtap-enabled hosts, but from there to a host using a bridge, or maybe a host in a remote location that used a virtual network with a secure tunnel to connect back to the rest of the red-network. (Part of the migration process would of course check that the destination host had a network of the proper name with adequate available resources, and fail if it didn't; management software at a level above libvirt would probably filter a list of candidate migration destinations based on available networks and any various details of those networks (eg. it could search for only networks using vepa for the connection), and only attempt migration to one that had the matching network available). <virtualport> element of <interface> ------------------------------------ Since mamy of the attributes/sub-elements of <virtualport> (used by some modes of "direct" interface connections) are identical for all interfaces connecting to any given switch, most of the information in <virtualport> will be optional in the domain's interface definition - it can be filled in from a similar <virtualport> element that will be added to the <network> definition. Some parameters in <virtualport> ("instanceid", for example) must be unique for every interface, though, so those will still be specified in the <interface> XML. The two <virtualport> elements will be OR'ed at runtime to arrive at the actual set of parameters that are used. (Open Question: What should be the policy when a parameter is specified in both places? Should one take precedence? Or should it be considered an error?) portgroup attribute of <source> ------------------------------- The <source> element of an interface definition will be able to optionally specify a "portgroup" attribute. If portgroup is *NOT* given, the default portgroup of the network will be used (if a default is defined, otherwise no portgroup will be used). If portgroup *IS* specified, the source network must have a portgroup by that name (or the domain startup/migration will fail), and the attributes of that portgroup will be used for the connection. Here is an example <interface> definition that has both a reduced <virtualport> element, as well as a portgroup attribute: <interface type='network'> <source network='red-network' portgroup='engineering'/> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport> <mac address='de:ad:be:ef:ca:fe'/> </interface> (The specifics of what can be in a portgroup are given below) storing the actual chosen/running config in state dir ----------------------------------------------------- Note: the following additions to the XML will only ever be visible in the statedir copy of the domain config, which is used to keep track of the state of running domains in case libvirtd is restarted while domains are still running. The described element cannot be used in a user-generated config file, and will never be present in a domain interface config produced by the libvirt public API, nor by "virsh dumpxml". In order to remind libvirt about which interfaces are actually in use in the event that libvirtd is restarted while domains are still running, the copy of the domain XML stored in "statedir" (/var/lib/libvirt/qemu/*.xml) may have an extra element <actual> stored as a subelement of each <interface>: <interface type='network'> <source network='red-network' portgroup='engineering'/> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport> <mac address='de:ad:be:ef:ca:fe'/> <actual type='direct'> <source dev='eth1' mode='vepa'/> </actual> </interface> In short, merging the <auto> element up into <interface> will yield the full interface as it was actually instantiated for the domain. In this case, the interface still has a mac address of de:ad:be:ef:ca:fe, and will use the same <virtualport> parameters, but the actual type of the interface will be 'direct' (so macvtap will be used to connect the interface), and the connection will be via physical device eth1 in vepa mode. network II. Changes to <network> definition =================================== As Dan has pointed out, any additions to <network> must be designed so that existing management applications (written to understand <network> prior to these new additions) will at least recognize that the XML they've been given is for something new that they don't fully understand. At the same time, the new types of network definition should attempt to re-use as much of the existing elements/attributes as possible, both to make it easier to extend these applications, as well as to make the status displays of un-updated applications make as much sense as possible. The new types of network will be specified by extending the choices for <forward mode='....'>. The current modes are: <forward mode='route|nat'/> (in addition to not listing any mode, which equates to "isolated") Here are suggested new modes: <forward mode='bridge|vepa|private|passthrough'/> A description of each: bridge - equivalent to "<interface type='bridge'>" in the interface definition. The bridge device to use would be given in the existing <bridge name='xxx'>. or <interface type='direct'> ... <source mode='bridge'/> (ie, macvtap bridge mode) with the physical interface name given in <forward dev='xxx'> or from the pool of devices given as subelements of <forward> (see below) vepa - same as "<interface type='direct'>..." with <source mode='vepa'/> private - <interface type='direct'> ... <source mode='private'/> passthrough - <interface type='direct'> ... <source mode='passthrough'/> Interface Pools --------------- In many cases, a single host network may have multiple physical network devices associated with it (especially in the case of an SRIOV-capable ethernet card, which will have several "virtual functions" associated with a single physical ethernet connection). The host will at least want to balance the load of multiple guests between these multiple devices, and may even require (in the case of passthrough mode, for example) that only a single guest interface be attached to each host device. The current specification for <forward> only allows for a single "dev" attribute, though. In order to support multiple device names, we will extend <forward> to allow 0 or more <interface> subelements: <forward mode='vepa'> <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> </forward> Note that, as a convenience, *on output* the first of these elements will always be a duplicate of the "dev" attribute in <forward> itself. When sending XML definnitions to libvirt, either a single interface should be send in <forward>, or a pool of them as sub-elements, but not both (if you do this, and the first in the pool matches the one given in <forward>, it will be ignored, but if they don't match, that is an error). In the case of mode='passthrough' (as well as mode='private' if the virtPortProfile has a mode setting of 802.1Qbh), only one guest interface can be connected to a device at a time. libvirt will keep track of which devices are in use, and attempt to assign a free device; failure to assign a device will result in a failure of the domain to start/migrate. For the other direct modes, libvirt will simply keep track of the number of guest interfaces currently using each device, and attempt to keep them balanced. Portgroups ----------- A <portgroup> (subelement of <network>) is just a way of easily putting connections to the network into different classes, with each class having a different level/type of service. Each <network> can have multiple <portgroup> elements, and each <portgroup> has a name, as well as various attributes associated with it. If an interface definition specifies a portgroup, that portgroup's info will be used to modify the interface's setup. If no portgroup is given and one of the network's portgroups has "default='yes'", that default portgroup will be used. If no portgroup is given in the interface definition, and there is no default portgroup, then none will be used. The first thing we will use portgroups for is as an alternate place to specify <virtualport> parameters: <portgroup name='engineering' default='yes'> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2"/> </virtualport> </portgroup> Anything that is valid in an interface's <virtualport> is also valid here. The next thing to specify in a portgroup will be bandwidth limiting / QoS configuration. Since I don't know exactly what's needed for that, I won't specify it here. If anything is specified both directly under <network> and in a <portgroup>, the value in portgroup will take precedence. (Again - what will the precedence of items specified in the <interface> be?) EXAMPLES -------- Examples of 'red-network' for different types of connections (all of these would work with minor variations of the interface XML given above, eg the 'vepa' version would require <virtualport> in the interface that specified an instanceid, and if the <interface> specified a portgroup, it would need to also be in the <network> definition (even if it was empty aside from name).  <network> <name>red-network</name> <bridge name='virbr0'/> <forward mode='route'/> ... </network>  <network> <name>red-network</name> <forward mode='bridge'/> <bridge name='eth0'/> </network>  <network> <name>red-network</name> <forward mode='vepa' dev='eth10'/> <virtualport type='802.1Qbg'> <parameters managerid='11' typeid='1193047' typeidversion='2'/> </virtualport>   <portgroup name='accounting'> <virtualport> <parameters typeid='22'/> </virtualport> </portgroup> <portgroup name='engineering'> <virtualport> <parameters typeid='33'/> </virtualport> </portgroup> </network>  <network> <name>red-network</name> <forward mode='passthrough'> <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> <interface dev='eth14'/> <interface dev='eth15'/> <interface dev='eth16'/> <interface dev='eth17'/> </forward> </network> ============= Keeping Track of Interface Usage by Guests ========================================== While libvirtd is running, each physical interface in a network's pool will maintain a count of how many guest interfaces are using that physical interface. Each guest interface will also maintain information about which network, and which physical interface on that network, it is using. The following situations could occur: 1) A guest is terminated while libvirtd is running. libvirtd will notice this, and decrement the usage count for each interface used by the guest, as maintained in the guest's state info. 2) The host system is rebooted When the libvirt network driver is restarted, no guests will yet be running, so the usage count of each physical interface will be 0, and get incremented as guests are started up. 3) libvirtd is restarted When the network is restarted, the usage count for all physical interfaces will be set to 0, just as if the entire system had been rebooted. One of two situations might be encountered: 3a) The guest is still running when libvirtd is restarted. In this case, the existing state information of the guest will be examined to determine which physical interface usage count to increment. 3b) The guest has been terminated while libvirtd wasn't present. Since the guest is no longer running, its state information will be thrown away.

3 43

[libvirt] Build libvirt 0.9.3 failed
by zhang xintao 19 Jul '11

19 Jul '11

I try to build libvirt 0.9.3 but failed ========================== Host OS：Ubuntu server 11.04 ========================== configure:error libnl-devel >= 1.1 is required for macvtap support libnl-dev 1.1-6 is already installed who can help me?

2 1

[libvirt] [PATCH] build: fix broken build
by Eric Blake 19 Jul '11

19 Jul '11

* src/libxl/libxl_driver.c (libxlDomainUndefineFlags): Use correct enum value. --- Pushing under the build-breaker rule. src/libxl/libxl_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 2e7197c..d52a8b6 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -2766,7 +2766,7 @@ libxlDomainUndefineFlags(virDomainPtr dom, if (virFileExists(name)) { if (flags & VIR_DOMAIN_UNDEFINE_MANAGED_SAVE) { if (unlink(name) < 0) { - libxlError(VIR_ERR_INTERNAL_ERR, + libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to remove domain managed save image")); goto cleanup; } -- 1.7.4.4

1 1

[libvirt] [PATCH v4 1/6] undefine: Define the new API
by Osier Yang 19 Jul '11

19 Jul '11

This introduces a new API virDomainUndefineFlags to control the domain undefine process, as the existing API virDomainUndefine doesn't support flags. Currently only flag VIR_DOMAIN_UNDEFINE_MANAGED_SAVE is supported. If the domain has a managed save image, including VIR_DOMAIN_UNDEFINE_MANAGED_SAVE in @flags will also remove that file, and omitting the flag will cause undefine process to fail. This patch also changes the behavior of virDomainUndefine, if the domain has a managed save image, the undefine will be refused. --- include/libvirt/libvirt.h.in | 10 +++++++ src/driver.h | 4 +++ src/libvirt.c | 60 +++++++++++++++++++++++++++++++++++++++++- src/libvirt_public.syms | 5 +++ 4 files changed, 78 insertions(+), 1 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index 607b5bc..5f9f08a 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -1200,6 +1200,16 @@ int virDomainMemoryPeek (virDomainPtr dom, virDomainPtr virDomainDefineXML (virConnectPtr conn, const char *xml); int virDomainUndefine (virDomainPtr domain); + +typedef enum { + VIR_DOMAIN_UNDEFINE_MANAGED_SAVE = 1, + + /* Future undefine control flags should come here. */ +} virDomainUndefineFlagsValues; + + +int virDomainUndefineFlags (virDomainPtr domain, + unsigned int flags); int virConnectNumOfDefinedDomains (virConnectPtr conn); int virConnectListDefinedDomains (virConnectPtr conn, char **const names, diff --git a/src/driver.h b/src/driver.h index 9d0d3de..4c4955f 100644 --- a/src/driver.h +++ b/src/driver.h @@ -219,6 +219,9 @@ typedef virDomainPtr typedef int (*virDrvDomainUndefine) (virDomainPtr dom); typedef int + (*virDrvDomainUndefineFlags) (virDomainPtr dom, + unsigned int flags); +typedef int (*virDrvDomainSetVcpus) (virDomainPtr domain, unsigned int nvcpus); typedef int @@ -733,6 +736,7 @@ struct _virDriver { virDrvDomainCreateWithFlags domainCreateWithFlags; virDrvDomainDefineXML domainDefineXML; virDrvDomainUndefine domainUndefine; + virDrvDomainUndefineFlags domainUndefineFlags; virDrvDomainAttachDevice domainAttachDevice; virDrvDomainAttachDeviceFlags domainAttachDeviceFlags; virDrvDomainDetachDevice domainDetachDevice; diff --git a/src/libvirt.c b/src/libvirt.c index 39e2041..2f5241a 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -6374,7 +6374,13 @@ error: * virDomainUndefine: * @domain: pointer to a defined domain * - * Undefine a domain but does not stop it if it is running + * Undefine a domain. If the domain is running, it's converted to + * transient domain, without stopping it. If the domain is inactive, + * the domain configuration is removed. + * + * If the domain has a managed save image (see + * virDomainHasManagedSaveImage()), then the undefine will fail. See + * virDomainUndefineFlags() for more control. * * Returns 0 in case of success, -1 in case of error */ @@ -6413,6 +6419,58 @@ error: } /** + * virDomainUndefineFlags: + * @domain: pointer to a defined domain + * @flags: bitwise-or of supported virDomainUndefineFlagsValues + * + * Undefine a domain. If the domain is running, it's converted to + * transient domain, without stopping it. If the domain is inactive, + * the domain configuration is removed. + * + * If the domain has a managed save image (see virDomainHasManagedSaveImage()), + * then including VIR_DOMAIN_UNDEFINE_MANAGED_SAVE in @flags will also remove + * that file, and omitting the flag will cause the undefine process to fail. + * + * Returns 0 in case of success, -1 in case of error + */ +int +virDomainUndefineFlags(virDomainPtr domain, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "flags=%x", flags); + + virResetLastError(); + + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + virDispatchError(NULL); + return -1; + } + conn = domain->conn; + if (conn->flags & VIR_CONNECT_RO) { + virLibDomainError(VIR_ERR_OPERATION_DENIED, __FUNCTION__); + goto error; + } + + if (conn->driver->domainUndefineFlags) { + int ret; + ret = conn->driver->domainUndefineFlags (domain, flags); + if (ret < 0) + goto error; + return ret; + } + + virLibConnError(VIR_ERR_NO_SUPPORT, __FUNCTION__); + +error: + virDispatchError(domain->conn); + return -1; +} + + +/** * virConnectNumOfDefinedDomains: * @conn: pointer to the hypervisor connection * diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms index 5f2541a..5cc480e 100644 --- a/src/libvirt_public.syms +++ b/src/libvirt_public.syms @@ -466,4 +466,9 @@ LIBVIRT_0.9.3 { virNodeGetMemoryStats; } LIBVIRT_0.9.2; +LIBVIRT_0.9.4 { + global: + virDomainUndefineFlags; +} LIBVIRT_0.9.3; + # .... define new API here using predicted next version number .... -- 1.7.6

2 12

[libvirt] RHEL guest shuts down after running anaconda instead of rebooting
by Eric 19 Jul '11

19 Jul '11

when i create a RHEL 6 guest using virt-install it will go through the process of installing the OS and want to reboot once finished. when it reboots the VM powers off and i have to start it manually. is there a way to prevent this? i can reboot guests once they're up and running and they'll come back up without issue, but they always shut down when i'm installing them. host OS is RHEL 6 x86_64.

1 0

[libvirt] CentOS/RHEL 6 RPMs repository
by Mohammed Naser 19 Jul '11

19 Jul '11

Hi list! First post here, thanks for a wonderful application, I have been around in #virt on IRC and just signed up today. My little contribution: We use CentOS 6 in production and we were not able to get access to the latest 0.9.3 RPMs and we needed some of the new features, so we compiled a bunch of RPMs to help those save time (and us). Please note that we're not responsible if it blows up your computer, etc. etc. wget http://repo.vexxhost.com/virt/virt.repo -O /etc/yum.repos.d/virt.repo yum install libvirt That should get you started on libvirt 0.9.3, there are a couple of unavailable dependencies that are also on the repo, so you should be good to go! If anyone has any issues, please let me know. Other than that, enjoy the repos! Also, if you don't trust us and want to compile the SRPMS yourself, they are also available -- if you are running i386 and compile a set, drop it by so we can help people as it is x86_64 RPMs only right now. Regards, -- Mohammed Naser — vexxhost -----------------------------------------------------

1 0

[libvirt] [PATCH] maint: fix spelling of Red Hat
by Eric Blake 19 Jul '11

19 Jul '11

* cfg.mk (sc_copyright_format): Add to rule. * src/util/files.h: Fix offenders. * src/util/files.c: Likewise. --- Pushing under the trivial rule. Noticed it because my upcoming edits to files.c triggered my editor's copyright update rule. The 'syntax-check' addition ensures that no one else makes the mistake. cfg.mk | 3 +++ src/util/files.c | 4 ++-- src/util/files.h | 2 +- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/cfg.mk b/cfg.mk index f98c94b..d243862 100644 --- a/cfg.mk +++ b/cfg.mk @@ -584,6 +584,9 @@ sc_copyright_format: @prohibit='Copyright [^(].*Red 'Hat \ halt='consistently use (C) in Red Hat copyright' \ $(_sc_search_regexp) + @prohibit='\<Red''Hat\>' \ + halt='spell Red Hat as two words' \ + $(_sc_search_regexp) # Some functions/macros produce messages intended solely for developers # and maintainers. Do not mark them for translation. diff --git a/src/util/files.c b/src/util/files.c index de4ae87..bef56b6 100644 --- a/src/util/files.c +++ b/src/util/files.c @@ -1,9 +1,9 @@ /* - * memory.c: safer file handling + * files.c: safer file handling * + * Copyright (C) 2010-2011 Red Hat, Inc. * Copyright (C) 2010 IBM Corporation * Copyright (C) 2010 Stefan Berger - * Copyright (C) 2010 RedHat, Inc. * Copyright (C) 2010 Eric Blake * * This library is free software; you can redistribute it and/or diff --git a/src/util/files.h b/src/util/files.h index 5137fb3..8b681eb 100644 --- a/src/util/files.h +++ b/src/util/files.h @@ -1,7 +1,7 @@ /* * files.h: safer file handling * - * Copyright (C) 2010-2011 RedHat, Inc. + * Copyright (C) 2010-2011 Red Hat, Inc. * Copyright (C) 2010 IBM Corporation * Copyright (C) 2010 Stefan Berger * Copyright (C) 2010 Eric Blake -- 1.7.4.4

1 0

[libvirt] [PATCH 0/8] Avoid filesystem cache pollution during virsh save
by Eric Blake 19 Jul '11

19 Jul '11

Saving a domain's state creates a large file, which risks polluting the filesystem cache and slowing down a system. If a system has a lot of domians simultaneously being saved (such as the libvirt-guests init script doing managed saves), then this can cause noticeable slowdown due to filesystem thrashing. This patch series has been successfully tested to do 'virsh save dom file --direct', with lsof(1) used to verify that O_DIRECT was in use, and the resulting file was successfully used with 'virsh restore file'. Still to come - wire up O_DIRECT on the 'virsh restore' path (yes, that means adding virDomainRestoreFlags - if only we had had the foresight to use flags everywhere). Wire up qemu.conf to allow the automatic use of --direct on automatic core dumps. Wire up libvirt-guests init script to allow the use of --direct. But I had enough in place to get the review started now. Also, this series demonstrates some of the points I was making about adding a new Flags API in this thread: https://www.redhat.com/archives/libvir-list/2011-July/msg00762.html This series requires and was tested on top of these (un-acked) patches: https://www.redhat.com/archives/libvir-list/2011-July/msg00670.html https://www.redhat.com/archives/libvir-list/2011-July/msg00675.html Eric Blake (8): save: document new public API save: wire up remote protocol save: wire up trivial saveFlags implementations save: add --direct flag to virsh save operations save: let iohelper handle inherited fd save: let iohelper work on O_DIRECT fds save: add virDirectFd wrapper type save: support O_DIRECT during qemu saves cfg.mk | 1 + configure.ac | 6 +- include/libvirt/libvirt.h.in | 14 +++ po/POTFILES.in | 1 + src/Makefile.am | 1 + src/driver.h | 6 ++ src/fdstream.c | 32 +++----- src/libvirt.c | 94 +++++++++++++++++++++- src/libvirt_private.syms | 6 ++ src/libvirt_public.syms | 5 + src/libxl/libxl_driver.c | 17 ++++- src/qemu/qemu_driver.c | 76 +++++++++++++----- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 11 +++- src/remote_protocol-structs | 6 ++ src/test/test_driver.c | 20 ++++- src/util/iohelper.c | 185 +++++++++++++++++++++++++++++++---------- src/util/virdirect.c | 149 +++++++++++++++++++++++++++++++++ src/util/virdirect.h | 37 +++++++++ src/vbox/vbox_tmpl.c | 19 ++++- src/xen/xen_driver.c | 17 ++++- tools/virsh.c | 12 +++- tools/virsh.pod | 17 +++- 23 files changed, 632 insertions(+), 101 deletions(-) create mode 100644 src/util/virdirect.c create mode 100644 src/util/virdirect.h -- 1.7.4.4

2 44

Re: [libvirt] mingw: test-poll pipe part fails
by Eric Blake 19 Jul '11

19 Jul '11

[adding libvirt] On 06/04/2011 12:24 AM, Paolo Bonzini wrote: > On Sat, Jun 4, 2011 at 00:37, Matthias Bolte > <matthias.bolte(a)googlemail.com> wrote: >> After testing a while and reading MSDN docs the problem seems to be >> that MsgWaitForMultipleObjects doesn't work on pipes. It doesn't >> actually wait but just returns immediately. Digging MSDN and googling >> about this suggest that there is no simple solution to this. > > Yes, Windows pipes are that broken. :( > > Using socketpair is a possibly good idea, but I would do it on > libvirtd only. I don't know exactly how libvirtd uses this pipe, but > perhaps it can be changed to an eventfd-like abstraction that can be > used with both Windows and Unix. This is similar to Eric's > suggestion, but without the pipe at all. It would also be a > libvirtd-specific suggestion. I'm wondering if the problem here is that libvirt is trying to use the pipe-to-self mechanism as a fundamental event loop idiom. That is, the reason libvirt is calling poll is in order to minimize CPU until something interesting happens, where interesting includes needing to wake up a helper thread to do an action inside locks in response to the receipt of a signal. Maybe you are on to something, and replacing all uses of pipe() with virPipeToSelf() (which uses pipe() for efficiency on Linux, but socketpair() on mingw), would allow libvirt to continue to use the pipe-to-self idiom while also using fds that can actually be poll'd on mingw. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

4 6