- Devel - libvirt List Archives

[libvirt] [PATCH 0/8 v2] Report disk latency info
by Osier Yang 06 Sep '11

06 Sep '11

This patch series introduces a new API to report the disk latency related information, which is supported by upstream QEMU just a few days ago (commit c488c7f649, Thu Aug 25). Per previous dicussion on the ABI compatiblity, and API design principle, the new API is defined with style: int virDomainBlockStatsFlags (virDomainPtr dom, const char *path, virTypeParamsPtr params, int *nparams, unsigned int flags) V1 - V2: * Use virTypedParameter instead of creating a new struct for the new API. * Update comments for the API, (Eric's suggestion). [PATCH 1/8] latency: Define new public API and structure [PATCH 2/8] latency: Define the internal driver callback [PATCH 3/8] latency: Implemente the public API [PATCH 4/8] latency: Wire up the remote protocol [PATCH 5/8] latency: Update monitor functions for new latency fields [PATCH 6/8] latency: Implemente internal API for qemu driver [PATCH 7/8] latency: Expose the new API for Python binding [PATCH 8/8] latency: Update cmdBlkStats to use new API Regards, Osier

2 17

[libvirt] [PATCH 1/2] make remote_exec_pexpect return the output of command
by Guannan Ren 06 Sep '11

06 Sep '11

*utils/Python/utils.py return 0,child.before intead *repos/remoteAccess/tcp_setup.py repos/remoteAccess/tls_setup.py switch over to use new remote_exec_pexpect() --- repos/remoteAccess/tcp_setup.py | 18 +++++++++--------- repos/remoteAccess/tls_setup.py | 20 ++++++++++---------- utils/Python/utils.py | 4 ++-- 3 files changed, 21 insertions(+), 21 deletions(-) diff --git a/repos/remoteAccess/tcp_setup.py b/repos/remoteAccess/tcp_setup.py index 8f88810..b3877f7 100644 --- a/repos/remoteAccess/tcp_setup.py +++ b/repos/remoteAccess/tcp_setup.py @@ -56,7 +56,7 @@ def sasl_user_add(target_machine, username, password, util, logger): """ execute saslpasswd2 to add sasl user """ logger.info("add sasl user on server side") saslpasswd2_add = "echo %s | %s -a libvirt %s" % (password, SASLPASSWD2, username) - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, saslpasswd2_add) if ret: logger.error("failed to add sasl user") @@ -70,7 +70,7 @@ def tcp_libvirtd_set(target_machine, username, password, logger.info("setting libvirtd.conf on libvirt server") # open libvirtd --listen option listen_open_cmd = "echo 'LIBVIRTD_ARGS=\"--listen\"' >> %s" % SYSCONFIG_LIBVIRTD - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, listen_open_cmd) if ret: logger.error("failed to uncomment --listen in %s" % SYSCONFIG_LIBVIRTD) @@ -79,7 +79,7 @@ def tcp_libvirtd_set(target_machine, username, password, # set listen_tls logger.info("set listen_tls to 0 in %s" % LIBVIRTD_CONF) listen_tls_disable = "echo \"listen_tls = 0\" >> %s" % LIBVIRTD_CONF - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, listen_tls_disable) if ret: logger.error("failed to set listen_tls to 0 in %s" % LIBVIRTD_CONF) @@ -89,7 +89,7 @@ def tcp_libvirtd_set(target_machine, username, password, if listen_tcp == 'enable': logger.info("enable listen_tcp = 1 in %s" % LIBVIRTD_CONF) listen_tcp_set = "echo 'listen_tcp = 1' >> %s" % LIBVIRTD_CONF - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, listen_tcp_set) if ret: logger.error("failed to set listen_tcp in %s" % LIBVIRTD_CONF) @@ -98,7 +98,7 @@ def tcp_libvirtd_set(target_machine, username, password, # set auth_tcp logger.info("set auth_tcp to \"%s\" in %s" % (auth_tcp, LIBVIRTD_CONF)) auth_tcp_set = "echo 'auth_tcp = \"%s\"' >> %s" % (auth_tcp, LIBVIRTD_CONF) - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, auth_tcp_set) if ret: logger.error("failed to set auth_tcp in %s" % LIBVIRTD_CONF) @@ -107,7 +107,7 @@ def tcp_libvirtd_set(target_machine, username, password, # restart remote libvirtd service libvirtd_restart_cmd = "service libvirtd restart" logger.info("libvirtd restart") - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, libvirtd_restart_cmd) if ret: logger.error("failed to restart libvirtd service") @@ -225,18 +225,18 @@ def tcp_setup_clean(params): if auth_tcp == 'sasl': saslpasswd2_delete = "%s -a libvirt -d %s" % (SASLPASSWD2, username) - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, saslpasswd2_delete) if ret: logger.error("failed to delete sasl user") libvirtd_conf_retore = "sed -i -n '/^[ #]/p' %s" % LIBVIRTD_CONF - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, libvirtd_conf_retore) if ret: logger.error("failed to restore %s" % LIBVIRTD_CONF) sysconfig_libvirtd_restore = "sed -i -n '/^[ #]/p' %s" % SYSCONFIG_LIBVIRTD - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, sysconfig_libvirtd_restore) if ret: logger.error("failed to restore %s" % SYSCONFIG_LIBVIRTD) diff --git a/repos/remoteAccess/tls_setup.py b/repos/remoteAccess/tls_setup.py index 4e7f24e..27bb8a7 100644 --- a/repos/remoteAccess/tls_setup.py +++ b/repos/remoteAccess/tls_setup.py @@ -213,7 +213,7 @@ def deliver_cert(target_machine, username, password, pkipath, util, logger): # mkdir /etc/pki/libvirt/private on remote host libvirt_priv_cmd = "mkdir -p %s" % PRIVATE_KEY_FOLDER - ret = util.remote_exec_pexpect(target_machine, username, password, libvirt_priv_cmd) + ret, output = util.remote_exec_pexpect(target_machine, username, password, libvirt_priv_cmd) if ret: logger.error("failed to make /etc/pki/libvirt/private on %s" % target_machine) return 1 @@ -257,7 +257,7 @@ def sasl_user_add(target_machine, username, password, util, logger): """ execute saslpasswd2 to add sasl user """ logger.info("add sasl user on server side") saslpasswd2_add = "echo %s | %s -a libvirt %s" % (password, SASLPASSWD2, username) - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, saslpasswd2_add) if ret: logger.error("failed to add sasl user") @@ -271,7 +271,7 @@ def tls_libvirtd_set(target_machine, username, password, logger.info("setting libvirtd.conf on tls server") # open libvirtd --listen option listen_open_cmd = "echo 'LIBVIRTD_ARGS=\"--listen\"' >> /etc/sysconfig/libvirtd" - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, listen_open_cmd) if ret: logger.error("failed to uncomment --listen in /etc/sysconfig/libvirtd") @@ -280,7 +280,7 @@ def tls_libvirtd_set(target_machine, username, password, if listen_tls == 'disable': logger.info("set listen_tls to 0 in %s" % LIBVIRTD_CONF) listen_tls_disable = "echo \"listen_tls = 0\" >> %s" % LIBVIRTD_CONF - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, listen_tls_disable) if ret: logger.error("failed to set listen_tls to 0 in %s" % LIBVIRTD_CONF) @@ -289,7 +289,7 @@ def tls_libvirtd_set(target_machine, username, password, if auth_tls == 'sasl': logger.info("enable auth_tls = sasl in %s" % LIBVIRTD_CONF) auth_tls_set = "echo 'auth_tls = \"sasl\"' >> %s" % LIBVIRTD_CONF - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, auth_tls_set) if ret: logger.error("failed to set auth_tls to sasl in %s" % LIBVIRTD_CONF) @@ -298,7 +298,7 @@ def tls_libvirtd_set(target_machine, username, password, # restart remote libvirtd service libvirtd_restart_cmd = "service libvirtd restart" logger.info("libvirtd restart") - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, libvirtd_restart_cmd) if ret: logger.error("failed to restart libvirtd service") @@ -311,7 +311,7 @@ def iptables_stop(target_machine, username, password, util, logger): """ This is a temprory method in favor of migration """ logger.info("stop local and remote iptables temprorily") iptables_stop_cmd = "service iptables stop" - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, iptables_stop_cmd) if ret: logger.error("failed to stop remote iptables service") @@ -466,13 +466,13 @@ def tls_setup_clean(params): util = utils.Utils() cacert_rm = "rm -f %s/cacert.pem" % CA_FOLDER - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, cacert_rm) if ret: logger.error("failed to remove cacert.pem on remote machine") ca_libvirt_rm = "rm -rf %s" % CERTIFICATE_FOLDER - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, ca_libvirt_rm) if ret: logger.error("failed to remove libvirt folder") @@ -482,7 +482,7 @@ def tls_setup_clean(params): if auth_tls == 'sasl': saslpasswd2_delete = "%s -a libvirt -d %s" % (SASLPASSWD2, username) - ret = util.remote_exec_pexpect(target_machine, username, + ret, output = util.remote_exec_pexpect(target_machine, username, password, saslpasswd2_delete) if ret: logger.error("failed to delete sasl user") diff --git a/utils/Python/utils.py b/utils/Python/utils.py index 6787e87..d521254 100644 --- a/utils/Python/utils.py +++ b/utils/Python/utils.py @@ -406,10 +406,10 @@ class Utils(object): child.sendline(password) elif index == 2: child.close() - return 0 + return 0, child.before elif index == 3: child.close() - return 1 + return 1, "" return 0 -- 1.7.1

2 4

[libvirt] [test-API][PATCH 1/2] Remove cases/migrate.conf testcases and create a set of migration testcases
by Guannan Ren 06 Sep '11

06 Sep '11

*cases/migrate.conf remove it. *cases/migration/* create a new set of migraion testcases with tcp, tls and sasl combination It's huge, so I send the header of commit here. --- cases/migrate.conf | 97 ---- cases/migration/ssh_persistent_paused_no_dst.conf | 459 +++++++++++++++++++ .../migration/ssh_persistent_paused_with_dst.conf | 459 +++++++++++++++++++ cases/migration/ssh_persistent_running_no_dst.conf | 435 ++++++++++++++++++ .../migration/ssh_persistent_running_with_dst.conf | 435 ++++++++++++++++++ cases/migration/ssh_transient_paused_no_dst.conf | 403 +++++++++++++++++ cases/migration/ssh_transient_paused_with_dst.conf | 403 +++++++++++++++++ cases/migration/ssh_transient_running_no_dst.conf | 388 ++++++++++++++++ .../migration/ssh_transient_running_with_dst.conf | 382 ++++++++++++++++ cases/migration/tcp_persistent_paused_no_dst.conf | 471 ++++++++++++++++++++ .../migration/tcp_persistent_paused_with_dst.conf | 471 ++++++++++++++++++++ cases/migration/tcp_persistent_running_no_dst.conf | 447 +++++++++++++++++++ .../migration/tcp_persistent_running_with_dst.conf | 447 +++++++++++++++++++ .../tcp_sasl_persistent_paused_no_dst.conf | 167 +++++++ .../tcp_sasl_persistent_paused_with_dst.conf | 168 +++++++ .../tcp_sasl_persistent_running_no_dst.conf | 159 +++++++ .../tcp_sasl_persistent_running_with_dst.conf | 159 +++++++ .../tcp_sasl_transient_paused_no_dst.conf | 151 +++++++ .../tcp_sasl_transient_paused_with_dst.conf | 151 +++++++ .../tcp_sasl_transient_running_no_dst.conf | 143 ++++++ .../tcp_sasl_transient_running_with_dst.conf | 143 ++++++ cases/migration/tcp_transient_paused_no_dst.conf | 415 +++++++++++++++++ cases/migration/tcp_transient_paused_with_dst.conf | 415 +++++++++++++++++ cases/migration/tcp_transient_running_no_dst.conf | 400 +++++++++++++++++ .../migration/tcp_transient_running_with_dst.conf | 394 ++++++++++++++++ cases/migration/tls_persistent_paused_no_dst.conf | 471 ++++++++++++++++++++ .../migration/tls_persistent_paused_with_dst.conf | 471 ++++++++++++++++++++ cases/migration/tls_persistent_running_no_dst.conf | 447 +++++++++++++++++++ .../migration/tls_persistent_running_with_dst.conf | 447 +++++++++++++++++++ .../tls_sasl_persistent_paused_no_dst.conf | 167 +++++++ .../tls_sasl_persistent_paused_with_dst.conf | 167 +++++++ .../tls_sasl_persistent_running_no_dst.conf | 159 +++++++ .../tls_sasl_persistent_running_with_dst.conf | 159 +++++++ .../tls_sasl_transient_paused_no_dst.conf | 151 +++++++ .../tls_sasl_transient_paused_with_dst.conf | 151 +++++++ .../tls_sasl_transient_running_no_dst.conf | 143 ++++++ .../tls_sasl_transient_running_with_dst.conf | 143 ++++++ cases/migration/tls_transient_paused_no_dst.conf | 415 +++++++++++++++++ cases/migration/tls_transient_paused_with_dst.conf | 415 +++++++++++++++++ cases/migration/tls_transient_running_no_dst.conf | 400 +++++++++++++++++ .../migration/tls_transient_running_with_dst.conf | 394 ++++++++++++++++ 41 files changed, 12765 insertions(+), 97 deletions(-) delete mode 100644 cases/migrate.conf create mode 100644 cases/migration/ssh_persistent_paused_no_dst.conf create mode 100644 cases/migration/ssh_persistent_paused_with_dst.conf create mode 100644 cases/migration/ssh_persistent_running_no_dst.conf create mode 100644 cases/migration/ssh_persistent_running_with_dst.conf create mode 100644 cases/migration/ssh_transient_paused_no_dst.conf create mode 100644 cases/migration/ssh_transient_paused_with_dst.conf create mode 100644 cases/migration/ssh_transient_running_no_dst.conf create mode 100644 cases/migration/ssh_transient_running_with_dst.conf create mode 100644 cases/migration/tcp_persistent_paused_no_dst.conf create mode 100644 cases/migration/tcp_persistent_paused_with_dst.conf create mode 100644 cases/migration/tcp_persistent_running_no_dst.conf create mode 100644 cases/migration/tcp_persistent_running_with_dst.conf create mode 100644 cases/migration/tcp_sasl_persistent_paused_no_dst.conf create mode 100644 cases/migration/tcp_sasl_persistent_paused_with_dst.conf create mode 100644 cases/migration/tcp_sasl_persistent_running_no_dst.conf create mode 100644 cases/migration/tcp_sasl_persistent_running_with_dst.conf create mode 100644 cases/migration/tcp_sasl_transient_paused_no_dst.conf create mode 100644 cases/migration/tcp_sasl_transient_paused_with_dst.conf create mode 100644 cases/migration/tcp_sasl_transient_running_no_dst.conf create mode 100644 cases/migration/tcp_sasl_transient_running_with_dst.conf create mode 100644 cases/migration/tcp_transient_paused_no_dst.conf create mode 100644 cases/migration/tcp_transient_paused_with_dst.conf create mode 100644 cases/migration/tcp_transient_running_no_dst.conf create mode 100644 cases/migration/tcp_transient_running_with_dst.conf create mode 100644 cases/migration/tls_persistent_paused_no_dst.conf create mode 100644 cases/migration/tls_persistent_paused_with_dst.conf create mode 100644 cases/migration/tls_persistent_running_no_dst.conf create mode 100644 cases/migration/tls_persistent_running_with_dst.conf create mode 100644 cases/migration/tls_sasl_persistent_paused_no_dst.conf create mode 100644 cases/migration/tls_sasl_persistent_paused_with_dst.conf create mode 100644 cases/migration/tls_sasl_persistent_running_no_dst.conf create mode 100644 cases/migration/tls_sasl_persistent_running_with_dst.conf create mode 100644 cases/migration/tls_sasl_transient_paused_no_dst.conf create mode 100644 cases/migration/tls_sasl_transient_paused_with_dst.conf create mode 100644 cases/migration/tls_sasl_transient_running_no_dst.conf create mode 100644 cases/migration/tls_sasl_transient_running_with_dst.conf create mode 100644 cases/migration/tls_transient_paused_no_dst.conf create mode 100644 cases/migration/tls_transient_paused_with_dst.conf create mode 100644 cases/migration/tls_transient_running_no_dst.conf create mode 100644 cases/migration/tls_transient_running_with_dst.conf

2 3

[libvirt] [PATCH 0/3] Libvirt RPC dispatching and unresponsive QEMU
by Michal Privoznik 05 Sep '11

05 Sep '11

If there is an unresponsive qemu process and libvirt access it's monitor, it will not get any response and this thread will block indefinitely, until the qemu process resumes or it's destroyed. If users continues executing APIs against that domain, libvirt will run out of worker threads and hangs (if those APIs will access monitor as well). Although, they will timeout in approx 30 seconds, which will free some workers, during that time is libvirt unable to process any request. Even worse - if the number of unresponsive qemu exceeds the size of worker thread pool, libvirt will hangs forever, and even restarting the daemon will not make it any better. This patch set heals the daemon on several levels, so nothing from written above will cause it to hangs: 1. RPC dispatching - all APIs are now annotated as 'high' or 'low' priority. Then a special thread pool is created. Low priority APIs will be still placed into usual pool, but high priority can be placed into this new pool if the former has no free worker. Which APIs should be marked high and which low? The splitting presented here is my guessing. It is not something written in stone, but from the logic of things it is not safe to annotate any API which is NOT guaranteed to end in reasonable small time as high priority call. 2. Job queue size limit - this sets bound on the number of threads blocked by a stuck qemu. Okay, there exists timeout on this, but if user application continue dispatching low priority calls it can still consume all (low priority) worker threads and therefore affect other users/VMs. Even if they timeout in approx 30 secs. 3. Run monitor re-connect in a separate thread per VM. If libvirtd is restarted, it tries to reconnect to all running qemu processes. This is potentially risky - one stuck qemu block daemon startup. However, putting the monitor startup code into one thread per VM allows libvirtd to startup, accept client connections and work with all VMs which monitor was successfully re-opened. Unresponsive qemu will hold job until we open the monitor. So clever user application can destroy such domain. All APIs requiring job will just fail in acquiring lock. Michal Privoznik (3): daemon: Create priority workers pool qemu: Introduce job queue size limit qemu: Deal with stucked qemu on daemon startup daemon/libvirtd.aug | 1 + daemon/libvirtd.c | 10 +- daemon/libvirtd.conf | 6 + daemon/remote.c | 26 ++ daemon/remote.h | 2 + src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 7 + src/qemu/qemu_conf.c | 4 + src/qemu/qemu_conf.h | 2 + src/qemu/qemu_domain.c | 17 ++ src/qemu/qemu_domain.h | 2 + src/qemu/qemu_driver.c | 23 +-- src/qemu/qemu_process.c | 89 ++++++- src/remote/qemu_protocol.x | 13 +- src/remote/remote_protocol.x | 544 +++++++++++++++++++++--------------------- src/rpc/gendispatch.pl | 48 ++++- src/rpc/virnetserver.c | 32 +++- src/rpc/virnetserver.h | 6 +- src/util/threadpool.c | 38 ++- src/util/threadpool.h | 1 + 20 files changed, 554 insertions(+), 318 deletions(-) -- 1.7.3.4

5 22

[libvirt] [PATCH v2] Source control for storage pool
by Lei Li 05 Sep '11

05 Sep '11

Fix bug #611823 storage driver should prohibit pools with duplicate underlying storage. Add API virStoragePoolSourceFindDuplicate() to do uniqueness check based on source location infomation for pool type. Signed-off-by: Lei Li <lilei(a)linux.vnet.ibm.com> --- src/conf/storage_conf.c | 80 ++++++++++++++++++++++++++++++++++++++++++ src/conf/storage_conf.h | 5 +++ src/libvirt_private.syms | 2 + src/storage/storage_driver.c | 6 +++ 4 files changed, 93 insertions(+), 0 deletions(-) diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index 8d14e87..1e7da69 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -1311,6 +1311,21 @@ virStoragePoolObjFindByName(virStoragePoolObjListPtr pools, return NULL; } +virStoragePoolObjPtr +virStoragePoolSourceFindDuplicateDevices(virStoragePoolObjPtr pool, + virStoragePoolDefPtr def) { + unsigned int i, j; + + for (i = 0; i < pool->def->source.ndevice; i++) { + for (j = 0; j < def->source.ndevice; j++) { + if (STREQ(pool->def->source.devices[i].path, def->source.devices[j].path)) + return pool; + } + } + + return NULL; +} + void virStoragePoolObjClearVols(virStoragePoolObjPtr pool) { @@ -1701,6 +1716,71 @@ cleanup: return ret; } +int virStoragePoolSourceFindDuplicate(virStoragePoolObjListPtr pools, + virStoragePoolDefPtr def) +{ + int i; + int ret = 1; + virStoragePoolObjPtr pool = NULL; + virStoragePoolObjPtr matchpool = NULL; + + /* Check the pool list for duplicate underlying storage */ + for (i = 0; i < pools->count; i++) { + pool = pools->objs[i]; + if (def->type != pool->def->type) + continue; + + virStoragePoolObjLock(pool); + + switch (pool->def->type) { + case VIR_STORAGE_POOL_DIR: + if (STREQ(pool->def->target.path, def->target.path)) + matchpool = pool; + break; + case VIR_STORAGE_POOL_NETFS: + if ((STREQ(pool->def->source.dir, def->source.dir)) \ + && (STREQ(pool->def->source.host.name, def->source.host.name))) + matchpool = pool; + break; + case VIR_STORAGE_POOL_SCSI: + if (STREQ(pool->def->source.adapter, def->source.adapter)) + matchpool = pool; + break; + case VIR_STORAGE_POOL_ISCSI: + { + matchpool = virStoragePoolSourceFindDuplicateDevices(pool, def); + if (matchpool) { + if (STREQ(matchpool->def->source.host.name, def->source.host.name)) { + if ((matchpool->def->source.initiator.iqn) && (def->source.initiator.iqn)) { + if (STREQ(matchpool->def->source.initiator.iqn, def->source.initiator.iqn)) + break; + matchpool = NULL; + } + break; + } + matchpool = NULL; + } + break; + } + case VIR_STORAGE_POOL_FS: + case VIR_STORAGE_POOL_LOGICAL: + case VIR_STORAGE_POOL_DISK: + matchpool = virStoragePoolSourceFindDuplicateDevices(pool, def); + break; + default: + break; + } + virStoragePoolObjUnlock(pool); + } + + if (matchpool) { + virStorageReportError(VIR_ERR_OPERATION_FAILED, + _("Storage source conflict with pool: '%s'"), + matchpool->def->name); + ret = -1; + } + return ret; +} void virStoragePoolObjLock(virStoragePoolObjPtr obj) { diff --git a/src/conf/storage_conf.h b/src/conf/storage_conf.h index 271441a..d115a15 100644 --- a/src/conf/storage_conf.h +++ b/src/conf/storage_conf.h @@ -335,6 +335,8 @@ virStoragePoolObjPtr virStoragePoolObjFindByUUID(virStoragePoolObjListPtr pools, const unsigned char *uuid); virStoragePoolObjPtr virStoragePoolObjFindByName(virStoragePoolObjListPtr pools, const char *name); +virStoragePoolObjPtr virStoragePoolSourceFindDuplicateDevices(virStoragePoolObjPtr pool, + virStoragePoolDefPtr def); virStorageVolDefPtr virStorageVolDefFindByKey(virStoragePoolObjPtr pool, const char *key); @@ -388,6 +390,9 @@ int virStoragePoolObjIsDuplicate(virStoragePoolObjListPtr pools, virStoragePoolDefPtr def, unsigned int check_active); +int virStoragePoolSourceFindDuplicate(virStoragePoolObjListPtr pools, + virStoragePoolDefPtr def); + void virStoragePoolObjLock(virStoragePoolObjPtr obj); void virStoragePoolObjUnlock(virStoragePoolObjPtr obj); diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 9f03e30..316eb7e 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -947,7 +947,9 @@ virStoragePoolObjClearVols; virStoragePoolObjDeleteDef; virStoragePoolObjFindByName; virStoragePoolObjFindByUUID; +virStoragePoolSourceFindDuplicateDevices; virStoragePoolObjIsDuplicate; +virStoragePoolSourceFindDuplicate; virStoragePoolObjListFree; virStoragePoolObjLock; virStoragePoolObjRemove; diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 68cac1f..c05b74e 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -536,6 +536,9 @@ storagePoolCreate(virConnectPtr conn, if (virStoragePoolObjIsDuplicate(&driver->pools, def, 1) < 0) goto cleanup; + if (virStoragePoolSourceFindDuplicate(&driver->pools, def) < 0) + goto cleanup; + if ((backend = virStorageBackendForType(def->type)) == NULL) goto cleanup; @@ -589,6 +592,9 @@ storagePoolDefine(virConnectPtr conn, if (virStoragePoolObjIsDuplicate(&driver->pools, def, 0) < 0) goto cleanup; + if (virStoragePoolSourceFindDuplicate(&driver->pools, def) < 0) + goto cleanup; + if (virStorageBackendForType(def->type) == NULL) goto cleanup; -- 1.7.1

2 1

[libvirt] [PATCH 1/3] PIIX3 USB controller is on function 2
by Marc-André Lureau 05 Sep '11

05 Sep '11

Current code reserves slot 1 function 2 even if there is a user defined PIIX3 USB controller there. --- src/qemu/qemu_command.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 6ff1b2c..e4bdb57 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1181,7 +1181,8 @@ qemuAssignDevicePCISlots(virDomainDefPtr def, qemuDomainPCIAddressSetPtr addrs) * hardcoded slot=1, multifunction device */ for (function = 0; function < QEMU_PCI_ADDRESS_LAST_FUNCTION; function++) { - if (function == 1 && (reservedIDE || reservedUSB)) + if ((function == 1 && reservedIDE) || + (function == 2 && reservedUSB)) /* we have reserved this pci address */ continue; -- 1.7.6

2 4

Re: [libvirt] migration of vnlink VMs
by Oved Ourfalli 05 Sep '11

05 Sep '11

----- Original Message ----- > From: "Laine Stump" <lstump(a)redhat.com> > To: "Oved Ourfalli" <ovedo(a)redhat.com> > Cc: "Ayal Baron" <abaron(a)redhat.com>, "Barak Azulay" <bazulay(a)redhat.com>, "Shahar Havivi" <shaharh(a)redhat.com>, > "Itamar Heim" <iheim(a)redhat.com>, "Dan Kenigsberg" <danken(a)redhat.com> > Sent: Thursday, April 28, 2011 10:20:35 AM > Subject: Re: migration of vnlink VMs > Oved, > > Would it be okay to repost this message to the thread on libvir-list > so > that other parties can add their thoughts? > Of course. I'm sending my answer to the libvirt list. > On 04/27/2011 09:58 AM, Oved Ourfalli wrote: > > Laine, hello. > > > > We read your proposal for abstraction of guest<--> host network > > connection in libvirt. > > > > You has an open issue there regarding the vepa/vnlink attributes: > > "3) What about the parameters in the<virtualport> element that are > > currently used by vepa/vnlink. Do those belong with the host, or > > with the guest?" > > > > The parameters for the virtualport element should be on the guest, > > and not the host, because a specific interface can run multiple > > profiles, > > Are you talking about host interface or guest interface? If you mean > that multiple different profiles can be used when connecting to a > particular switch - as long as there are only a few different > profiles, > rather than each guest having its own unique profile, then it still > seems better to have the port profile live with the network definition > (and just define multiple networks, one for each port profile). > The profile names can be changed regularly, so it looks like it will be better to put them in the guest level, so that the network host file won't have to be changed on all hosts once something has changed in the profiles. Also, you will have a duplication of data, writing all the profile name on all the hosts that are connected to the vn-link/vepa switch. > > > so it will be a mistake to define a profile to be interface > > specific on the host. Moreover, putting it in the guest level will > > enable us in the future (if supported by libvirt/qemu) to migrate > > a vm from a host with vepa/vnlink interfaces, to another host with > > a bridge, for example. > > It seems to me like doing exactly the opposite would make it easier to > migrate to a host that used a different kind of switching (from vepa > to > vnlink, or from a bridged interface to vepa, etc), since the port > profile required for a particular host's network would be at the host > waiting to be used. You are right, but we would want to have the option to prevent that from happening in case we wouldn't want to allow it. We can make the ability to migrate between different network types configurable, and we would like an easy way to tell libvirt - "please allow/don't allow it". > > > So, in the networks at the host level you will have: > > <network type='direct'> > > <name>red-network</name> > > <source mode='vepa'> > > <pool> > > <interface> > > <name>eth0</name> > > ..... > > </interface> > > <interface> > > <name>eth4</name> > > ..... > > </interface> > > <interface> > > <name>eth18</name> > > ..... > > </interface> > > </pool> > > </source> > > </network> > > > > And in the guest you will have (for vepa): > > <interface type='network'> > > <source network='red-network'/> > > <virtualport type="802.1Qbg"> > > <parameters managerid="11" typeid="1193047" typeidversion="2" > > instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> > > </virtualport> > > </interface> > > > > Or (for vnlink): > > <interface type='network'> > > <source network='red-network'/> > > <virtualport type="802.1Qbh"> > > <parameters profile_name="profile1"/> > > </virtualport> > > </interface> > > This illustrates the problem I was wondering about - in your example > it > would not be possible for the guest to migrate from the host using a > vepa switch to the host using a vnlink switch (and it would be > possible You are right. When trying to migrate between vepa and vnlink there will be missing attributes in each in case we leave it on the host. > to migrate to a host using a standard bridge only if the virtualport > element was ignored). If the virtualport element lived with the > network > definition of red-network on each host, it could be migrated without > problem. > > The only problematic thing would be if any of the attributes within > <parameters> was unique for each guest (I don't know anything about > the > individual attributes, but "instanceid" sounds like it might be > different for each guest). > > > Then, when migrating from a vepa/vnlink host to another vepa/vnlink > > host containing red-network, the profile attributes will be > > available at the guest domain xml. > > In case the target host has a red-network, which isn't vepa/vnlink, > > we want to be able to choose whether to make the use of the profile > > attributes optional (i.e., libvirt won't fail in case of migrating > > to a network of another type), or mandatory (i.e., libvirt will fail > > in case of migration to a non-vepa/vnlink network). > > > > We have something similar in CPU flags: > > <cpu match="exact"> > > <model>qemu64</model> > > <topology sockets="S" cores="C" threads="T"/> > > <feature policy="require/optional/disable......" > > name="sse2"/> > > </cpu> > > In this analogy, does "CPU flags" == "mode (vepa/vnlink/bridge)" or > does > "CPU flags" == "virtualport parameters" ? It seems like what you're > wanting can be satisfied by simply not defining "red-network" on the > hosts that don't have the proper networking setup available (maybe > what > you *really* want to call it is "red-vnlink-network"). What I meant to say in that is that we would like to have the ability to say if an attribute must me used, or not. The issues you mention are indeed interesting. I'm cc-ing libvirt-list to see what other people think. Putting it on the guest will indeed make it problematic to migrate between networks that need different parameters (vnlink/vepa for example). Oved

7 11

[libvirt] [BUG] Xen->libvirt: localtime reported as UTC
by Philipp Hahn 05 Sep '11

05 Sep '11

Hello, just a report, no fix for that bug yet. If I create a domain and set <clock offset='localtime'/>, that information is correctly translated to Xends sxpr data, but on reading it back I get it reported as 'utc': # virsh dumpxml 85664d3f-68dd-a4c2-4d2f-be7f276b95f0 | grep clock <clock offset='utc'/> # gfind localtime ./85664d3f-68dd-a4c2-4d2f-be7f276b95f0/config.sxp: (platform ((device_model /usr/lib64/xen/bin/qemu-dm) (localtime 1))) ./85664d3f-68dd-a4c2-4d2f-be7f276b95f0/config.sxp: (localtime 1) BYtE Philipp -- Philipp Hahn Open Source Software Engineer hahn(a)univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/

3 6

[libvirt] [PATCH] Add directsync cache mode support for disk driver
by Osier Yang 05 Sep '11

05 Sep '11

Newer QEMU introduced cache=directsync for -drive, this patchset is to expose it in libvirt layer. * Introduced a new QEMU capability flag ($prefix_CACHE_DIRECTSYNC), As even $prefix_CACHE_V2 is set, we can't known if directsync is supported. --- docs/formatdomain.html.in | 2 +- docs/schemas/domain.rng | 1 + src/conf/domain_conf.c | 3 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 6 +++++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 29 ++++++++++++++++++++++------- tests/qemuargv2xmltest.c | 1 + tests/qemuxml2argvtest.c | 3 +++ tools/virsh.pod | 3 ++- 10 files changed, 39 insertions(+), 11 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index f46771d..6cb36d3 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -976,7 +976,7 @@ <li> The optional <code>cache</code> attribute controls the cache mechanism, possible values are "default", "none", - "writethrough" and "writeback". + "writethrough", "writeback", and "directsync". <span class="since">Since 0.6.0</span> </li> <li> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index dd8c41a..e43b17d 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -829,6 +829,7 @@ <value>none</value> <value>writeback</value> <value>writethrough</value> + <value>directsync</value> </choice> </attribute> </define> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 00212db..a2de8df 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -160,7 +160,8 @@ VIR_ENUM_IMPL(virDomainDiskCache, VIR_DOMAIN_DISK_CACHE_LAST, "default", "none", "writethrough", - "writeback") + "writeback", + "directsync") VIR_ENUM_IMPL(virDomainDiskErrorPolicy, VIR_DOMAIN_DISK_ERROR_POLICY_LAST, "default", diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 8382d28..0abb75e 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -165,6 +165,7 @@ enum virDomainDiskCache { VIR_DOMAIN_DISK_CACHE_DISABLE, VIR_DOMAIN_DISK_CACHE_WRITETHRU, VIR_DOMAIN_DISK_CACHE_WRITEBACK, + VIR_DOMAIN_DISK_CACHE_DIRECTSYNC, VIR_DOMAIN_DISK_CACHE_LAST }; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index f665de4..631d683 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -125,6 +125,7 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST, "sga", "virtio-blk-pci.event_idx", "virtio-net-pci.event_idx", + "cache-directsync", ); struct qemu_feature_flags { @@ -902,8 +903,11 @@ qemuCapsComputeCmdFlags(const char *help, if (strstr(help, "-drive")) { qemuCapsSet(flags, QEMU_CAPS_DRIVE); if (strstr(help, "cache=") && - !strstr(help, "cache=on|off")) + !strstr(help, "cache=on|off")) { qemuCapsSet(flags, QEMU_CAPS_DRIVE_CACHE_V2); + if (strstr(help, "directsync")) + qemuCapsSet(flags, QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC); + } if (strstr(help, "format=")) qemuCapsSet(flags, QEMU_CAPS_DRIVE_FORMAT); if (strstr(help, "readonly=")) diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 13af0b9..c01d438 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -100,6 +100,7 @@ enum qemuCapsFlags { QEMU_CAPS_SGA = 62, /* Serial Graphics Adapter */ QEMU_CAPS_VIRTIO_BLK_EVENT_IDX = 63, /* virtio-blk-pci.event_idx */ QEMU_CAPS_VIRTIO_NET_EVENT_IDX = 64, /* virtio-net-pci.event_idx */ + QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC = 65, /* Is cache=directsync supported? */ QEMU_CAPS_LAST, /* this must always be the last item */ }; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 44a553b..fa52dc0 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -64,14 +64,16 @@ VIR_ENUM_DECL(qemuDiskCacheV2) VIR_ENUM_IMPL(qemuDiskCacheV1, VIR_DOMAIN_DISK_CACHE_LAST, "default", "off", - "off", /* writethrough not supported, so for safety, disable */ - "on"); /* Old 'on' was equivalent to 'writeback' */ + "off", /* writethrough not supported, so for safety, disable */ + "on", /* Old 'on' was equivalent to 'writeback' */ + "off"); /* directsync not supported, for safety, disable */ VIR_ENUM_IMPL(qemuDiskCacheV2, VIR_DOMAIN_DISK_CACHE_LAST, "default", "none", "writethrough", - "writeback"); + "writeback", + "directsync"); VIR_ENUM_DECL(qemuVideo) @@ -1516,10 +1518,21 @@ qemuBuildDriveStr(virDomainDiskDefPtr disk, } if (disk->cachemode) { - const char *mode = - qemuCapsGet(qemuCaps, QEMU_CAPS_DRIVE_CACHE_V2) ? - qemuDiskCacheV2TypeToString(disk->cachemode) : - qemuDiskCacheV1TypeToString(disk->cachemode); + const char *mode = NULL; + + if (qemuCapsGet(qemuCaps, QEMU_CAPS_DRIVE_CACHE_V2)) { + mode = qemuDiskCacheV2TypeToString(disk->cachemode); + + if (disk->cachemode == VIR_DOMAIN_DISK_CACHE_DIRECTSYNC && + !qemuCapsGet(qemuCaps, QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC)) { + qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("disk cache mode 'directsync' is not " + "supported by this QEMU")); + goto error; + } + } else { + mode = qemuDiskCacheV1TypeToString(disk->cachemode); + } virBufferAsprintf(&opt, ",cache=%s", mode); } else if (disk->shared && !disk->readonly) { @@ -5211,6 +5224,8 @@ qemuParseCommandLineDisk(virCapsPtr caps, def->cachemode = VIR_DOMAIN_DISK_CACHE_WRITEBACK; else if (STREQ(values[i], "writethrough")) def->cachemode = VIR_DOMAIN_DISK_CACHE_WRITETHRU; + else if (STREQ(values[i], "directsync")) + def->cachemode = VIR_DOMAIN_DISK_CACHE_DIRECTSYNC; } else if (STREQ(keywords[i], "werror") || STREQ(keywords[i], "rerror")) { if (STREQ(values[i], "stop")) diff --git a/tests/qemuargv2xmltest.c b/tests/qemuargv2xmltest.c index c2b6cf2..91f15af 100644 --- a/tests/qemuargv2xmltest.c +++ b/tests/qemuargv2xmltest.c @@ -168,6 +168,7 @@ mymain(void) DO_TEST("disk-drive-cache-v2-wt"); DO_TEST("disk-drive-cache-v2-wb"); DO_TEST("disk-drive-cache-v2-none"); + DO_TEST("disk-drive-cache-directsync"); DO_TEST("disk-drive-network-nbd"); DO_TEST("disk-drive-network-rbd"); DO_TEST("disk-drive-network-sheepdog"); diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 6e8da5e..b009bf3 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -338,6 +338,9 @@ mymain(void) QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_CACHE_V2, QEMU_CAPS_DRIVE_FORMAT); DO_TEST("disk-drive-cache-v2-none", false, QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_CACHE_V2, QEMU_CAPS_DRIVE_FORMAT); + DO_TEST("disk-drive-cache-directsync", false, + QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_CACHE_V2, + QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC, QEMU_CAPS_DRIVE_FORMAT); DO_TEST("disk-drive-network-nbd", false, QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_FORMAT); DO_TEST("disk-drive-network-rbd", false, diff --git a/tools/virsh.pod b/tools/virsh.pod index b90c26e..5ac2c5c 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1099,7 +1099,8 @@ floppy device; consider using B<update-device> for this usage instead. I<mode> can specify the two specific mode I<readonly> or I<shareable>. I<persistent> indicates the changes will affect the next boot of the domain. I<sourcetype> can indicate the type of source (block|file) -I<cache> can be one of "default", "none", "writethrough" or "writeback". +I<cache> can be one of "default", "none", "writethrough", "writeback", or +"directsync". I<serial> is the serial of disk device. I<shareable> indicates the disk device is shareable between domains. I<address> is the address of disk device in the form of pci:domain.bus.slot.function, -- 1.7.6

3 6

Re: [libvirt] [RFC] block I/O throttling: how to enable in libvirt
by Zhi Yong Wu 05 Sep '11

05 Sep '11

On Fri, Sep 02, 2011 at 08:34:19AM -0500, Adam Litke wrote: >From: Adam Litke <agl(a)us.ibm.com> >To: Zhi Yong Wu <wuzhy(a)linux.vnet.ibm.com> >Cc: libvir-list(a)redhat.com >Subject: Re: [libvirt] [RFC] block I/O throttling: how to enable in libvirt >Message-ID: <20110902133419.GW15683(a)aglitke.rchland.ibm.com> >References: <20110901050531.GB17963(a)f15.cn.ibm.com> > <20110902021447.GD19143(a)f15.cn.ibm.com> >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >In-Reply-To: <20110902021447.GD19143(a)f15.cn.ibm.com> >User-Agent: Mutt/1.5.21 (2010-09-15) >X-Brightmail-Tracker: AAAAAA== >X-Xagent-From: agl(a)us.ibm.com >X-Xagent-To: wuzhy(a)linux.vnet.ibm.com >X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGENTU8 at VMSDVMA) > >On Fri, Sep 02, 2011 at 10:14:48AM +0800, Zhi Yong Wu wrote: >> On Thu, Sep 01, 2011 at 01:05:31PM +0800, Zhi Yong Wu wrote: >> HI, Adam, >> Now stefan, Daniel, and Gui all suggest extending blkiotune to keep libivrt unified interface. What do you think of it? > >It seems like it would be nice to extend the blkiotune API for this use case, >but there is one problem. The blkiotune interface operates at the VM level and >the QEMU throttling is at the disk level. So if you want per-disk throttling >granularity the blkiotune API may not be suitable. I see 3 possible paths >forward: > >1) Accept the blkiotune limitation of a global setting and add a throttle option >that assigns the same throttle value to all disks. > > <blkiotune> > <shares>250</shares> > <throttle>1024</throttle> > </blkiotune> > > + Nice for simplicity and ease of implementation > - May be too simplistic (can't set different throttling for different disks) > > >2) Extend the blkiotune API to allow per-disk tunings: > > <blkiotune> > <shares>250</shares> > <throttle device='virtio-disk0'>1024</throttle> > </blkiotune> > > + Use an existing API > - Unfortunately it doesn't look like this can be done cleanly > > >3) Use a new API virDomainSetBlkDevParameters() to set device specific >tuning parameters: > ><blkiotune> > <shares>250</shares> ></blkiotune> >... ><disk type='file' device='disk'> > <driver name='qemu' type='raw'/> > <source file='...'/> > <target dev='vda' bus='virtio'/> > <blkdevtune> > <throttle>1024</throttle> Several I/O throttling tags should be supported, such as thrbps, thrbpsrd, thrbpswr, thriops, etc. > </blkdevtune> ></disk> > > + Throttle can be specified with the disk it is effecting > - Proliferation of tuning APIs > > >Obviously #1 is the best if you can accept the limitations of the API. #2 would #1 is not accepted by us. If it is adopted, the advantage of QEMU I/O throttling is not used fully. >be nice if we could figure out how to extend virTypedParameter to represent a I guess that #2 is less extendable than #3. >(disk, param) pair. I see #3 as a last resort. Did I miss any other solutions. To be honest, i prefer to #3. At first, i plan to check how blkiotune works currently. >Did I just manage to completely over-complicate this? :) NO, they are nice. thanks. Regards, Zhiyong Wu > >-- >Adam Litke <agl(a)us.ibm.com> >IBM Linux Technology Center

1 0