- Devel - libvirt List Archives

[libvirt] libvirt.pc file
by Eric Blake 09 May '11

09 May '11

Why is libvirt.pc included in the tarball? It contains information learned at configure time, thus its contents depend on who built the tarball, which is in violation of the normal rule that any generated file that depends on config.status must not be shipped. Unless anyone has a good reason why it is distributed, I'm working on a patch to fix that. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

4 8

[libvirt] virsh nodedev-dempxml is not supported by the connection driver
by guan qin 09 May '11

09 May '11

Hi, I meet a problem when I use the command "virsh nodedev-dumpxml pci_0000_00_19_0",it shows as follows: root@shahe26:~# virsh nodedev-list error: Failed to count node devices error: this function is not supported by the connection driver: virNodeNumOfDevices root@shahe26:~# virsh nodedev-dumpxml pci_0000_00_19_0 error: Could not find matching device 'pci_0000_00_19_0' error: this function is not supported by the connection driver: virNodeDeviceLookupByName root@shahe26:~# virsh -version 0.9.0 root@shahe26:~# virsh net-list Name State Autostart ----------------------------------------- default active yes root@shahe26:~# virsh list Id Name State ---------------------------------- root@shahe26:~# I find that only the command "virsh nodedev-? ***" can't work . How can I solve this problem ? thanks. best regards, qinguan

2 5

[libvirt] [PATCH] json: Fix *GetBoolean functions
by Jiri Denemark 09 May '11

09 May '11

They were not used anywhere so far so nobody noticed they are broken. --- src/util/json.c | 11 ++++++----- src/util/json.h | 4 ++-- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/util/json.c b/src/util/json.c index 0daeae9..df4771d 100644 --- a/src/util/json.c +++ b/src/util/json.c @@ -491,12 +491,13 @@ int virJSONValueGetNumberDouble(virJSONValuePtr number, double *value) } -int virJSONValueGetBoolean(virJSONValuePtr val) +int virJSONValueGetBoolean(virJSONValuePtr val, bool *value) { - if (val->type != VIR_JSON_TYPE_NUMBER) + if (val->type != VIR_JSON_TYPE_BOOLEAN) return -1; - return val->data.boolean; + *value = val->data.boolean; + return 0; } @@ -593,7 +594,7 @@ int virJSONValueObjectGetNumberDouble(virJSONValuePtr object, const char *key, d } -int virJSONValueObjectGetBoolean(virJSONValuePtr object, const char *key) +int virJSONValueObjectGetBoolean(virJSONValuePtr object, const char *key, bool *value) { virJSONValuePtr val; if (object->type != VIR_JSON_TYPE_OBJECT) @@ -603,7 +604,7 @@ int virJSONValueObjectGetBoolean(virJSONValuePtr object, const char *key) if (!val) return -1; - return virJSONValueGetBoolean(val); + return virJSONValueGetBoolean(val, value); } diff --git a/src/util/json.h b/src/util/json.h index ea28de6..4572654 100644 --- a/src/util/json.h +++ b/src/util/json.h @@ -105,7 +105,7 @@ int virJSONValueGetNumberUint(virJSONValuePtr object, unsigned int *value); int virJSONValueGetNumberLong(virJSONValuePtr object, long long *value); int virJSONValueGetNumberUlong(virJSONValuePtr object, unsigned long long *value); int virJSONValueGetNumberDouble(virJSONValuePtr object, double *value); -int virJSONValueGetBoolean(virJSONValuePtr object); +int virJSONValueGetBoolean(virJSONValuePtr object, bool *value); int virJSONValueIsNull(virJSONValuePtr object); const char *virJSONValueObjectGetString(virJSONValuePtr object, const char *key); @@ -114,7 +114,7 @@ int virJSONValueObjectGetNumberUint(virJSONValuePtr object, const char *key, uns int virJSONValueObjectGetNumberLong(virJSONValuePtr object, const char *key, long long *value); int virJSONValueObjectGetNumberUlong(virJSONValuePtr object, const char *key, unsigned long long *value); int virJSONValueObjectGetNumberDouble(virJSONValuePtr object, const char *key, double *value); -int virJSONValueObjectGetBoolean(virJSONValuePtr object, const char *key); +int virJSONValueObjectGetBoolean(virJSONValuePtr object, const char *key, bool *value); int virJSONValueObjectIsNull(virJSONValuePtr object, const char *key); int virJSONValueObjectAppendString(virJSONValuePtr object, const char *key, const char *value); -- 1.7.5.rc3

2 2

[libvirt] How to suppress error printing to stderr from virConnectOpen*?
by Richard W.M. Jones 09 May '11

09 May '11

I can set the global error handling function (virSetErrorFunc). That doesn't seem to be a good idea from a library. Looking at the code, it doesn't appear that the internal virErrorHandler is thread-local, so I can't set it and restore it around the function call. I can set the error handling function _after_ I've got a connection object (virConnSetErrorFunc). That doesn't help with making the initial connection. libguestfs itself has the same problem with the guestfs_create call, so I'm not going to point any fingers :-) However it seems like a shortcoming of the libvirt API. Am I missing something here? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

2 2

[libvirt] [PATCH] Allow destroying QEMU VM even if a job is active
by Daniel P. Berrange 09 May '11

09 May '11

Introduce a virProcessKill function that can be safely called even when the job mutex is held. This allows virDomainDestroy to kill any VM even if it is asleep in a monitor job. The PID will die and the thread asleep on the monitor will then wake up releasing the job mutex. * src/qemu/qemu_driver.c: Kill process before using qemuProcessStop to ensure job is released * src/qemu/qemu_process.c: Add virProcessKill for killing off QEMU processes --- src/qemu/qemu_driver.c | 7 +++++++ src/qemu/qemu_process.c | 39 +++++++++++++++++++++++++++++++-------- src/qemu/qemu_process.h | 2 ++ 3 files changed, 40 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index b3f9e00..6d6fb51 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1482,6 +1482,13 @@ static int qemudDomainDestroy(virDomainPtr dom) { goto cleanup; } + /* Although qemuProcessStop does this already, there may + * be an outstanding job active. We want to make sure we + * can kill the process even if a job is active. Killing + * it now, means the job will be released + */ + qemuProcessKill(vm); + if (qemuDomainObjBeginJobWithDriver(driver, vm) < 0) goto cleanup; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index a6c0dc8..c60c51f 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2369,6 +2369,36 @@ cleanup: } +void qemuProcessKill(virDomainObjPtr vm) +{ + int i; + int rc; + VIR_DEBUG("vm=%s pid=%d", vm->def->name, vm->pid); + + if (!virDomainObjIsActive(vm)) { + VIR_DEBUG("VM '%s' not active", vm->def->name); + return; + } + + for (i = 0 ; i < 15 ; i++) { + int signum; + if (i == 0) + signum = SIGTERM; + else if (i == 8) + signum = SIGKILL; + else + signum = 0; /* Just check for existance */ + + rc = virKillProcess(vm->pid, signum); + VIR_DEBUG("Iteration %d rc=%d", i, rc); + if (rc < 0) + break; + + usleep(200 * 1000); + } +} + + void qemuProcessStop(struct qemud_driver *driver, virDomainObjPtr vm, int migrated) @@ -2436,13 +2466,6 @@ void qemuProcessStop(struct qemud_driver *driver, } } - /* This will safely handle a non-running guest with pid=0 or pid=-1*/ - if (virKillProcess(vm->pid, 0) == 0 && - virKillProcess(vm->pid, SIGTERM) < 0) - virReportSystemError(errno, - _("Failed to send SIGTERM to %s (%d)"), - vm->def->name, vm->pid); - if (priv->mon) qemuMonitorClose(priv->mon); @@ -2454,7 +2477,7 @@ void qemuProcessStop(struct qemud_driver *driver, } /* shut it off for sure */ - virKillProcess(vm->pid, SIGKILL); + qemuProcessKill(vm); /* now that we know it's stopped call the hook if present */ if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h index f1ab599..d8afab0 100644 --- a/src/qemu/qemu_process.h +++ b/src/qemu/qemu_process.h @@ -49,4 +49,6 @@ void qemuProcessStop(struct qemud_driver *driver, virDomainObjPtr vm, int migrated); +void qemuProcessKill(virDomainObjPtr vm); + #endif /* __QEMU_PROCESS_H__ */ -- 1.7.4.4

2 2

[libvirt] RFC: APIs for managing a subset of a domain's disks
by Eric Blake 09 May '11

09 May '11

Consider the case of a guest that has multiple virtual disks, some residing on shared storage (such as the OS proper) and some on local storage (scratch space, where the OS has faster response if the virtual disk does not have to go over the network, and possibly one where the guest can still work even if the disk is hot-unplugged). During migration, you'd want different handling of the two disks (the destination can already see the shared disk, but must either copy the contents or recreate a blank scratch volume for the local disk). Or, consider the case where a guest has one disk as qcow2 (it is not modified frequently, and benefits from sharing a common backing file with other guests), while another disk is raw (for better read-write performance). Right now, 'virsh snapshot' fails, because it only works if all disks are qcow2; and in fact it may be the case that it is desirable to only take a snapshot of a subset of the domain's disks. So, I think we need some way to request an operation on a subset of VM disks, in a manner that can be shared between migration and volume management APIs. And I'm not sure it makes sense to add two more parameters to migration commands (an array of disks, and the size of that array), nor to modify the snapshot XML to describe which disks belong to the snapshot. So I'm thinking we need some sort of API set to manage a stateful set of disk operations. Maybe the trick is to define that every VM has a (possibly empty) set of selected disks, with APIs to manage moving a single disk in or out of the set, an API for listing the entire set, then a single flag to migration that states that live block migration is attempted for all disks currently in the VMs selected disk set. Being stateful, this would have to be represented in XML (so that if libvirtd is restarted, it remembers which disks are selected); I'm thinking of adding a new selected='yes|no' attribute to <disk>, as in: <disk type='file' device='disk' selected='yes'/> <driver name='qemu' type='raw'/> ... </disk> where if the attribute is absent, it defaults to no. For hypervisors where the state is maintained by libvirtd (qemu, lxc), the XML works; for other hypervisors, the notion of a subset of selected disks would have to just fail unless there is some hypervisor-specific way to track that information alongside a domain. For my API proposal, I'm including an unused flags argument to all the virDomainDiskSet* commands (experience has taught me well). In fact, we could even use that flags parameter, to maintain parallel sets (set 0 is the set of disks to migrate, set 1 is the set of disks to snapshot, ...), although I don't think we need that complexity yet (besides, it would affect the proposed XML). /* Add disk to the domain's set of selected disks; flags ignored for now; return 0 on success, 1 if already in the set, -1 on failure */ int virDomainDiskSetAdd(virDomainPtr dom, char *disk, unsigned int flags); /* Remove disk from the domain's set of selected disks; flags ignored for now; return 0 on success, 1 if already absent from the set, -1 on failure */ int virDomainDiskSetRemove(virDomainPtr dom, char *disk, unsigned int flags); /* Add all disks to the domain's set of selected disks; flags ignored for now; return 0 on success, -1 on failure */ int virDomainDiskSetAddAll(virDomainPtr dom, unsigned int flags); /* Remove all disks from the domain's set of selected disks; flags ignored for now; return 0 on success, -1 on failure */ int virDomainDiskSetRemoveAll(virDomainPtr dom, unsigned int flags); /* Return the size of the domain's currently selected disk set, or -1 on failure; flags ignored for now */ int virDomainDiskSetSize(virDomainPtr dom, unsigned int flags); /* Populate up to n entries of the array with the names of the domain's selected disk set, and return how many entries were populated, or -1 on failure; flags ignored for now */ int virDomainDiskSetList(virDomainPtr dom, char **array, int n, unsigned int flags) With API in place for tracking a subset of selected disks, we can then extend existing APIs with new flags: /* Old way - domain migration without any disks migrated */ virDomainMigrate(dom, dconn, flags | 0, dname, uri, bandwidth) /* New way - domain migration, including all disks in the domain's selected disk set being copied to the destination */ virDomainMigrate(dom, dconn, flags | VIR_MIGRATE_WITH_DISK_SET, dname, uri, bandwidth) /* Old way - snapshot of all disks */ virDomainSnapshotCreateXML(dom, xml, 0) /* New way - snapshot of just disks in selected disk set */ virDomainSnapshotCreateXML(dom, xml, VIR_DOMAIN_SAVE_DISK_SET) I'd also like to see some collaboration between virDomainSave (for memory) and virDomainSmapshotCreateXML (for disks); unfortunately, virDomainSave doesn't take a flags argument. Maybe this calls for a new API, and possibly a new version of the header to a 'virsh save' image to track the location of snapshotted disks alongside the saved memory state: /* Save the RAM state of domain to the base file "to". If "xml" is NULL, no disks are snapshotted. Otherwise, "xml" is a snapshot XML that describes how disk state will also be saved; if flags includes VIR_DOMAIN_SAVE_DISK_SET, then the domain's selected disk set is snapshotted, otherwise all disks are snapshotted. If flags contains VIR_DOMAIN_SAVE_LIVE, then the guest is resumed after snapshot is completed; otherwise the guest is halted. */ int virDomainSaveFlags(virDomainPtr dom, const char *to, const char *xml, unsigned int flags); Thoughts before I start implementing some of this for post-0.9.1? -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

4 5

[libvirt] [RFC PATCH] NUMA tuning support
by Osier Yang 09 May '11

09 May '11

Hi, All, This is a simple implenmentation for NUMA tuning support based on binary program 'numactl', currently only supports to bind memory to specified nodes, using option "--membind", perhaps it need to support more, but I'd like send it early so that could make sure if the principle is correct. Ideally, NUMA tuning support should be added in qemu-kvm first, such as they could provide command options, then what we need to do in libvirt is just to pass the options to qemu-kvm, but unfortunately qemu-kvm doesn't support it yet, what we could do currently is only to use numactl, it forks process, a bit expensive than qemu-kvm supports NUMA tuning inside with libnuma, but it shouldn't affects much I guess. The NUMA tuning XML is like: <numatune> <membind nodeset='+0-4,8-12'/> </numatune> Any thoughts/feedback is appreciated. Regards Osier [PATCH 1/5] build: Define NUMACTL for numa tuning use [PATCH 2/5] docs: Define XML schema for numa tuning and add docs [PATCH 3/5] conf: Support NUMA tuning XML [PATCH 4/5] qemu: Build command line for NUMA tuning [PATCH 5/5] tests: Add tests for guest use NUMA tuning

4 23

[libvirt] libvirt: TLS client certificate handling
by Doug Goldstein 06 May '11

06 May '11

Trying to setup qemu+tls here and I'm running into a few oddities (well that I feel are oddities) that I wanted clarification on before I submitted patches. The documentation I am following is: [1] http://libvirt.org/remote.html#Remote_certificates [2] http://wiki.libvirt.org/page/TLSSetup [3] http://wiki.libvirt.org/page/VNCTLSSetup All my storage is on iSCSI. I have 3 VM servers. 2 which every user can access and 1 which only a subset of users can access via the "tls_allowed_dn_list" parameter. Now how I envision this is that each of the 3 machines have their server certs & client certs in /etc/pki/libvirt, while each of the clients have their certs in $HOME/.pki/libvirt. That way a user, who doesn't have root or sudo access on the machine they are on could access the 2 VM servers they are allowed to access. However, if you look at the code, the only time $HOME/.pki/libvirt is used is when getuid() != 0 (this is correct) but the user either had to not specify a server to connect to and is using /session or you're auto-probing the local auto-spawned daemon for the remote URI. Effectively this means my approach can't happen. To complicate matters further, the documentation tells you to chown the client cert & key as root:root and set the permissions to 400. Which effectively means users can never use qemu+tls. I propose that we change the code for getuid() != 0 to always try $HOME/.pki/libvirt/ first and then try the system certificate. If everyone agrees, then I'll submit patches shortly. Additionally I wanted to note that as per [3], the default path for libvirt's user keys in $HOME differs from all other applications out there so I would also make it check $HOME/.pki/libvirt/private/clientkey.pem as well as $HOME/.pki/libvirt/clientkey.pem so that we'd match other application configurations. -- Doug Goldstein

1 0

[libvirt] [PATCH 00/22] Extend remote generator to generate function bodies too
by Matthias Bolte 06 May '11

06 May '11

Richard W.M. Jones suggested [1] that the code that directly deals with the XDR protocol should be generated. The remote_generate_stubs.pl script already generates all the headers, just the bodies in the daemon and remote driver are manually written. But most of the functions just follow simple patterns. So I extended the generator to exploit this patterns and move 11 kLOC code from manually written to generated code. During this I came a cross many small variations and problems in the XDR protocol. For example, NWFilterDefineXML has a flags parameter in the public API, but it's not transferred in the XDR protocol. Another things is the variations in the usage of unsigned VS signed types. This comes in two forms. public API VS XDR procotol and in between different functions. For example, some functions use int for the flags paramater and some use unsigned int. This results in quite a lot of special case handling in the generator. cfg.mk | 10 +- daemon/Makefile.am | 46 +- daemon/qemu_dispatch_args.h | 2 +- daemon/qemu_dispatch_bodies.c | 6 + daemon/qemu_dispatch_prototypes.h | 2 +- daemon/qemu_dispatch_ret.h | 2 +- daemon/qemu_dispatch_table.h | 2 +- daemon/remote.c | 5765 +---------------------------------- daemon/remote_dispatch_args.h | 2 +- daemon/remote_dispatch_bodies.c | 5933 +++++++++++++++++++++++++++++++++++ daemon/remote_dispatch_prototypes.h | 80 +- daemon/remote_dispatch_ret.h | 2 +- daemon/remote_dispatch_table.h | 158 +- daemon/remote_generate_stubs.pl | 195 -- daemon/remote_generator.pl | 1198 +++++++ po/POTFILES.in | 1 + src/Makefile.am | 13 +- src/remote/qemu_client_bodies.c | 4 + src/remote/qemu_protocol.c | 2 +- src/remote/qemu_protocol.h | 2 +- src/remote/qemu_protocol.x | 2 +- src/remote/remote_client_bodies.c | 4664 +++++++++++++++++++++++++++ src/remote/remote_driver.c | 4907 +---------------------------- src/remote/remote_protocol.c | 26 +- src/remote/remote_protocol.h | 26 +- src/remote/remote_protocol.x | 34 +- src/remote_protocol-structs | 26 +- 27 files changed, 12093 insertions(+), 11017 deletions(-) [1] https://www.redhat.com/archives/libvir-list/2011-April/msg00884.html Matthias

4 31

[libvirt] [PATCH] Balloon dom0 in libxl driver
by Markus Groß 06 May '11

06 May '11

Creating a domU on a freshly booted dom0 does not work, because the libxl driver does not allocate memory for the domU. After creating a domain with xl libvirt is able to create domains too. This patch reserves enough memory for the domU first. --- src/libxl/libxl_driver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 46 insertions(+), 2 deletions(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 247d78e..d4ca025 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -498,6 +498,46 @@ cleanup: return ret; } +static int +libxlFreeMem(libxlDomainObjPrivatePtr priv, libxl_domain_config *d_config) +{ + uint32_t needed_mem; + uint32_t free_mem; + int i; + int ret = -1; + int tries = 3; + int wait_secs = 10; + + if ((ret = libxl_domain_need_memory(&priv->ctx, &d_config->b_info, + &d_config->dm_info, + &needed_mem)) >= 0) { + for (i = 0; i < tries; ++i) { + if ((ret = libxl_get_free_memory(&priv->ctx, &free_mem)) < 0) + break; + + if (free_mem >= needed_mem) { + ret = 0; + break; + } + + if ((ret = libxl_set_memory_target(&priv->ctx, 0, + free_mem - needed_mem, + /* relative */ 1, 0)) < 0) + break; + + ret = libxl_wait_for_free_memory(&priv->ctx, 0, needed_mem, + wait_secs); + if (ret == 0 || ret != ERROR_NOMEM) + break; + + if ((ret = libxl_wait_for_memory_target(&priv->ctx, 0, 1)) < 0) + break; + } + } + + return ret; +} + /* * Start a domain through libxenlight. * @@ -521,8 +561,12 @@ libxlVmStart(libxlDriverPrivatePtr driver, if (libxlBuildDomainConfig(driver, def, &d_config) < 0 ) return -1; - //TODO: Balloon dom0 ?? - //ret = freemem(&d_config->b_info, &d_config->dm_info); + if (libxlFreeMem(priv, &d_config) < 0) { + libxlError(VIR_ERR_INTERNAL_ERROR, + _("libxenlight failed to get free memory for domain '%s'"), + d_config.c_info.name); + goto error; + } ret = libxl_domain_create_new(&priv->ctx, &d_config, NULL, &child_console_pid, &domid); -- 1.7.4.3

3 2