- Devel - libvirt List Archives

[libvirt] [PATCHv2] schema: Relax schema for domain name
by Peter Krempa 31 Jan '12

31 Jan '12

The domain schema enforced restrictions on the domain name string that the code doesn't. This patch relaxes the check, leaving the restrictions on the driver or hypervisor. The only invalid character is a newline. --- docs/schemas/domaincommon.rng | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 4fa968d..ecf3484 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -3030,7 +3030,7 @@ </define> <define name="domainName"> <data type="string"> - <param name="pattern">[A-Za-z0-9_\.\+\-&:/]+</param> + <param name="pattern">[^\n]+</param> </data> </define> <define name="diskSerial"> -- 1.7.3.4

2 3

[libvirt] RFC API proposal: virDomainBlockRebase
by Eric Blake 31 Jan '12

31 Jan '12

Right now, the existing virDomainBlockPull API has a tough limitation - it is an all-or-none approach. In all my examples below, I'm starting from the following relationship, where '<-' means 'is a backing file of': template <- intermediate <- current virDomainBlockPull can only convert things in a forward direction, with the merge destination being the current image, resulting in: merge template and intermediate into current, creating: current Meanwhile, qemu is adding support for a partial block pull operation, still on the current image as the merge destination, but where you can now specify an optional argument to limit the pull to just the intermediate files and altering the current image to be backed by an ancestor file, as in: merge intermediate into current, creating: template <- current For 0.9.10, I'd like to add the following API: /** * virDomainBlockRebase: * @dom: pointer to domain object * @disk: path to the block device, or device shorthand * @base: new base image, or NULL for entire block pull * @bandwidth: (optional) specify copy bandwidth limit in Mbps * @flags: extra flags; not used yet, so callers should always pass 0 * * Populate a disk image with data from its backing image chain, and * setting the new backing image to @base, where base is the absolute * path of one of the backing images in the chain. If @base is NULL, * then this operation is identical to virDomainBlockPull(). Once all * data from its backing image chain has been pulled, the disk no * longer depends on those intermediate backing images. This function * pulls data for the entire device in the background. Progress of the * operation can be checked with virDomainGetBlockJobInfo() and * the operation can be aborted with virDomainBlockJobAbort(). When * finished, an asynchronous event is raised to indicate the final * status. * * The @disk, @bandwidth, and @flags parameters are handled as in * virDomainBlockPull(). * * Returns 0 if the operation has started, -1 on failure. */ int virDomainBlockRebase(virDomainPtr dom, const char *disk, const char *base, unsigned long bandwidth, unsigned int flags); Given that Adam has a pending patch to support a VIR_DOMAIN_BLOCK_PULL_ASYNC flag, this same flag would have to be supported in virDomainBlockRebase. I've also been chatting with Federico Simoncelli about how the above operation would work for VDSM purposes in doing a live block move, while preserving a common template base file: start with: vda: template <- current1 create a disk-only snapshot, with: tmpsnap = virDomainSnapshotCreateXML(dom, "<domainsnapshot>\n" " <disks>\n" " <disk name='vda'>\n" " <source>/path/to/current2</source>\n" " </disk>\n" " <disks>\n" "</domainsnapshot>", VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY) where the xml calls out the destination file name, resulting in: vda: template <- current1 <- current2 perform the block rebase, with: virDomainBlockRebase(dom, "vda", "/path/to/template", VIR_DOMAIN_BLOCK_PULL_ASYNC) as well as waiting for the event (or polling status) to wait for completion, resulting in: vda: template <- current2 delete the disk-only snapshot metadata as no longer useful, with: virDomainSnapshotDelete(tmpsnap, VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY) At one point, I thought of creating a single libvirt API that performs all of those steps in one call; but right now, I'm not proposing that, because of the fact that qemu has no way to undo a snapshot. In other words, without an undo operation, if the snapshot phase succeeds but the block rebase phase fails, a single API would have to report failure even though the domain was altered, while the ideal scenario is that reporting failure means things were in the same state as before the API started. Beyond 0.9.10, there are some additional useful merge patterns that might be worth exposing. All of these operations are already possible on offline images, using qemu-img; but none of them are possible on live images using current qemu, which is why I'm thinking it is something for another day. I'm also hoping to someday enhance the set of virStorageVol APIs to make backing file manipulation of offline images easier. At any rate, the addition merge operations are: forward live merge with a non-current image as the merge destination, as in: merge template into intermediate, creating: intermediate <- current backward merge of a current image (that is, undoing a current snapshot): merge current into intermediate, creating: template <- intermediate and backward merge of a non-current image (that is, undoing an earlier snapshot, but by modifying the template rather than the current image): merge intermediate into base, creating: template <- current Backward merge of the current image seems like something easy to fit into my proposed API (add a new flag, maybe called VIR_DOMAIN_BLOCK_REBASE_BACKWARD). Manipulations of anything that does not involve the current image seems tougher, assuming qemu ever even reaches the point where it exposes those operations on live volumes - the user has to specify not one, but two backing file names. But even that could possibly be fit into my API, by adding a flag that states that the const char *backing argument is treated as an XML snippet describing the full details of the merge, with the XML listing which image is being merged to which destination, rather than as just the name of the backing file becoming the new base of the current image. Perhaps something like: virDomainBlockRebase(dom, block, "<rebase>\n" " <source>/path/to/intermediate</source>\n" " <dest>/path/to/template</dest>\n" "</rebase>", VIR_DOMAIN_BLOCK_REBASE_XML|VIR_DOMAIN_BLOCK_REBASE_BACKWARD) as a specification to take the contents of intermediate, merge those backwards into template, and as well as adjusting the rest of the backing file chain so that whatever used to be backed by intermediate is now backed by template. Or, if qemu ever gives us the ability to merge non-current images, we may decide at that time that it is worth a new API to expose those new complexities. Another thing I have been thinking about is virDomainSnapshotDelete. The above conversation talks about merging of a single disk, but a live disk snapshot operation can create backing file chains for multiple disks at once, all tracked by a snapshot. Additionally, the current code allows a snapshot delete of internal snapshots, but refuses to do anything useful with an external snapshot, because there is currently no way to specify if the snapshot is removed by merging the base into the new current, or by undoing the current and merging it backwards into the base. Alas, virDomainSnapshotDelete doesn't take any arguments for how to handle the situation, and use of a flag to make the decision would limit all disks to be handled in the same manner. So what I'm thinking is that when a snapshot is created (or redefined, using redefinition as the vehicle to add in the new XML), that the snapshot XML itself can record the preferred direction for undoing the snapshot; for example: <domainsnapshot> <disks> <disk name='/path/to/old_vda'> <source file='/path/to/new_vda'/> <on_delete merge='forward'/> </disk> <disk name='/path/to/old_vdb'> <source file='/path/to/new_vdb'/> <on_delete merge='backward'/> </disk> <disks> </domainsnapshot> then when virDomainSnapshotDelete is called on that snapshot, old_vda would be forward merged into new_vda, while new_vdb would be backward merged into old_vdb. Again, that's food for thought for post-0.9.10, and shouldn't get in the way of adding virDomainBlockRebase() now. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

2 3

[libvirt] Qemu text monitor
by Shradha Shah 31 Jan '12

31 Jan '12

Hello All, I am currently working with libvirt on RHEL6.2. There are a few points I have noticed regarding the QEMU monitor. When I hotplug a device into the guest, the Qemu text monitor receives a device_add command and adds the device to its current devices list (I found this list via the qemu-monitor-command "info pci"). When I hot-unplug the device from the guest, the Qemu text monitor receives the device_del command but does not remove the device from its current devices list (qemu-monitor-command "info pci" still shows the device). The result of this is that the next hotplug of the device fails giving an error "Duplicate id". I was wondering if any of you have hit this issue before or know about any qemu-monitor bugs I may not be aware of? Many Thanks in advance, Regards, Shradha Shah

3 2

[libvirt] [PATCH v2 0/4] RFC: grant KVM guest rawio capability
by Taku Izumi 31 Jan '12

31 Jan '12

This is the new version of http://www.redhat.com/archives/libvir-list/2012-January/msg01312.html Thank you for reviewing, Danie, Paolo, and Eric. -- This patchset achieves #1 and #2 of the following tasks: > 1. rawio="yes|nmo" on the <disk> element somewhere > 2. Give the QEMU process CAP_SYS_RAWIO > 3. Use the devices cgroup to specify which individual disks > can use rawio. In short, if you specify the following XML: <disk type='block' device='lun' rawio='yes'> the domain will be granted CAP_SYS_RAWIO. # virsh start VM # cat /proc/<VM's PID>/status ... CapInh: 0000000000000000 CapPrm: fffffffc00020000 CapEff: fffffffc00020000 CapBnd: fffffffc00020000 ... *[PATCH v2 1/4] conf: add rawio attribute to disk element of domain XML *[PATCH v2 2/4] util: add functions to keep capabilities *[PATCH v2 3/4] util: extend virExecWithHook() *[PATCH v2 4/4] qemu: make qemu processes to retain rawio capability - Best regards, Taku Izumi

4 15

[libvirt] [PATCH] qemu: never send SIGKILL to qemu process unless specifically requested
by Laine Stump 31 Jan '12

31 Jan '12

When libvirt is shutting down the qemu process, it first sends SIGTERM, then waits for 1.6 seconds and, if it sees the process still there, sends a SIGKILL. There have been reports that this behavior can lead to data loss because the guest running in qemu doesn't have time to flush it's disk cache buffers before it's unceremoniously whacked. One suggestion on how to solve that problem was to remove SIGKILL from the normal virDomainDestroyFlags, but still provide the ability to kill qemu with SIGKILL by using a new flag to virDomainDestroyFlags. This patch is a quick attempt at that in order to start a conversation on the topic. So what are your opinions? Is this the right way to solve the problem? Any better ideas? --- include/libvirt/libvirt.h.in | 12 ++++++------ src/qemu/qemu_driver.c | 7 +++++-- src/qemu/qemu_process.c | 40 ++++++++++++++++++++++------------------ src/qemu/qemu_process.h | 8 +++++++- 4 files changed, 40 insertions(+), 27 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index e99cd00..f9ac865 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -1182,12 +1182,6 @@ virConnectPtr virDomainGetConnect (virDomainPtr domain); * Domain creation and destruction */ - -/* - * typedef enum { - * } virDomainDestroyFlagsValues; - */ - virDomainPtr virDomainCreateXML (virConnectPtr conn, const char *xmlDesc, unsigned int flags); @@ -1222,6 +1216,12 @@ int virDomainReset (virDomainPtr domain, unsigned int flags); int virDomainDestroy (virDomainPtr domain); + +typedef enum { + VIR_DOMAIN_DESTROY_NONE = 0, /* Default behavior */ + VIR_DOMAIN_DESTROY_IMMEDIATE = 1 << 0, /* immediately kill, could lead to data loss!! */ +} virDomainDestroyFlagsValues; + int virDomainDestroyFlags (virDomainPtr domain, unsigned int flags); int virDomainRef (virDomainPtr domain); diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index ab69dca..0e80241 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1754,7 +1754,7 @@ qemuDomainDestroyFlags(virDomainPtr dom, virDomainEventPtr event = NULL; qemuDomainObjPrivatePtr priv; - virCheckFlags(0, -1); + virCheckFlags(VIR_DOMAIN_DESTROY_IMMEDIATE, -1); qemuDriverLock(driver); vm = virDomainFindByUUID(&driver->domains, dom->uuid); @@ -1775,7 +1775,10 @@ qemuDomainDestroyFlags(virDomainPtr dom, * can kill the process even if a job is active. Killing * it now means the job will be released */ - qemuProcessKill(vm, false); + if (flags & VIR_DOMAIN_DESTROY_IMMEDIATE) + qemuProcessKill(vm, VIR_QEMU_PROCESS_KILL_IMMEDIATELY); + else + qemuProcessKill(vm, VIR_QEMU_PROCESS_KILL_FORCEFULLY); /* We need to prevent monitor EOF callback from doing our work (and sending * misleading events) while the vm is unlocked inside BeginJob API diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index d22020b..efbe46c 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -586,7 +586,7 @@ endjob: cleanup: if (vm) { if (ret == -1) - qemuProcessKill(vm, false); + qemuProcessKill(vm, VIR_QEMU_PROCESS_KILL_FORCEFULLY); if (virDomainObjUnref(vm) > 0) virDomainObjUnlock(vm); } @@ -611,12 +611,12 @@ qemuProcessShutdownOrReboot(struct qemud_driver *driver, qemuProcessFakeReboot, vm) < 0) { VIR_ERROR(_("Failed to create reboot thread, killing domain")); - qemuProcessKill(vm, true); + qemuProcessKill(vm, VIR_QEMU_PROCESS_KILL_GRACEFULLY); /* Safe to ignore value since ref count was incremented above */ ignore_value(virDomainObjUnref(vm)); } } else { - qemuProcessKill(vm, true); + qemuProcessKill(vm, VIR_QEMU_PROCESS_KILL_GRACEFULLY); } } @@ -3524,30 +3524,34 @@ cleanup: } -void qemuProcessKill(virDomainObjPtr vm, bool gracefully) +void qemuProcessKill(virDomainObjPtr vm, unsigned int killMode) { int i; - VIR_DEBUG("vm=%s pid=%d gracefully=%d", - vm->def->name, vm->pid, gracefully); + VIR_DEBUG("vm=%s pid=%d killMode=%d", + vm->def->name, vm->pid, killMode); if (!virDomainObjIsActive(vm)) { VIR_DEBUG("VM '%s' not active", vm->def->name); return; } - /* This loop sends SIGTERM, then waits a few iterations - * (1.6 seconds) to see if it dies. If still alive then - * it does SIGKILL, and waits a few more iterations (1.6 - * seconds more) to confirm that it has really gone. + /* This loop sends SIGTERM (or SIGKILL if killMode is + * VIR_QEMU_KILL_MODE_IMMEDIATELY), then waits a few iterations + * (3.2 seconds) to see if it dies. Note that the IMMEDIATELY mode + * will very likely result in lost data in the guest, so it should + * only be used if the guest is hung and can't be destroyed in any + * other manner. */ - for (i = 0 ; i < 15 ; i++) { + for (i = 0 ; i < 16 ; i++) { int signum; - if (i == 0) - signum = SIGTERM; - else if (i == 8) - signum = SIGKILL; - else + if (i == 0) { + if (killMode == VIR_QEMU_PROCESS_KILL_IMMEDIATELY) + signum = SIGKILL; + else + signum = SIGTERM; + } else { signum = 0; /* Just check for existence */ + } if (virKillProcess(vm->pid, signum) < 0) { if (errno != ESRCH) { @@ -3558,7 +3562,7 @@ void qemuProcessKill(virDomainObjPtr vm, bool gracefully) break; } - if (i == 0 && gracefully) + if (i == 0 && (killMode == VIR_QEMU_PROCESS_KILL_GRACEFULLY)) break; usleep(200 * 1000); @@ -3651,7 +3655,7 @@ void qemuProcessStop(struct qemud_driver *driver, } /* shut it off for sure */ - qemuProcessKill(vm, false); + qemuProcessKill(vm, VIR_QEMU_PROCESS_KILL_FORCEFULLY); /* Stop autodestroy in case guest is restarted */ qemuProcessAutoDestroyRemove(driver, vm); diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h index 062d79e..755d4a6 100644 --- a/src/qemu/qemu_process.h +++ b/src/qemu/qemu_process.h @@ -68,7 +68,13 @@ int qemuProcessAttach(virConnectPtr conn, virDomainChrSourceDefPtr monConfig, bool monJSON); -void qemuProcessKill(virDomainObjPtr vm, bool gracefully); +typedef enum { + VIR_QEMU_PROCESS_KILL_GRACEFULLY = 0, + VIR_QEMU_PROCESS_KILL_FORCEFULLY = 1, + VIR_QEMU_PROCESS_KILL_IMMEDIATELY = 2, +} virQemuProcessKillMode; + +void qemuProcessKill(virDomainObjPtr vm, unsigned int killMode); int qemuProcessAutoDestroyInit(struct qemud_driver *driver); void qemuProcessAutoDestroyRun(struct qemud_driver *driver, -- 1.7.7.5

4 8

[libvirt] [PATCH v2 0/3] Add virDomainGetDiskErrors API
by Jiri Denemark 31 Jan '12

31 Jan '12

We already provide ways to detect when a domain has been paused as a result of I/O error, but there was no way of getting the exact error or even the device that experienced it. This new API may be used for both. Changes in version 2: - the API is now called virDomainGetDiskErrors - it returns a list (allocated by caller) of disks with errors instead so that users don't have to call it multiple times to get all errors - there's no python API yet since it can't be autogenerated; I'll send a patch for it tomorrow Jiri Denemark (3): virDomainGetDiskErrors public API and remote protocol qemu: Implement virDomainGetDiskErrors virsh: Implement domblkerror command daemon/remote.c | 40 +++++++++++++++++++ include/libvirt/libvirt.h.in | 32 +++++++++++++++ python/generator.py | 3 +- src/driver.h | 7 +++ src/libvirt.c | 52 ++++++++++++++++++++++++ src/libvirt_public.syms | 1 + src/qemu/qemu_conf.h | 1 + src/qemu/qemu_driver.c | 83 +++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_monitor.c | 40 +++++++++++++++++++ src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 8 ++++ src/qemu/qemu_monitor_text.c | 15 +++++++ src/remote/remote_driver.c | 34 ++++++++++++++++ src/remote/remote_protocol.x | 22 ++++++++++- src/remote_protocol-structs | 16 +++++++ src/rpc/gendispatch.pl | 47 ++++++++++++++++++++++ tools/virsh.c | 89 ++++++++++++++++++++++++++++++++++++++++++ tools/virsh.pod | 7 +++ 18 files changed, 496 insertions(+), 2 deletions(-) -- 1.7.8.4

2 9

[libvirt] [PATCH] XenXs: Update documentation
by Philipp Hahn 31 Jan '12

31 Jan '12

Fix several references to now renamed functions and parameters when the functions were moved from src/xen/ to src/xenxs/. Signed-off-by: Philipp Hahn <hahn(a)univention.de> --- src/xenxs/xen_sxpr.c | 222 +++++++++++++++++++++++++++++++++++++++++-------- 1 files changed, 185 insertions(+), 37 deletions(-) diff --git a/src/xenxs/xen_sxpr.c b/src/xenxs/xen_sxpr.c index 04ba5aa..ac15853 100644 --- a/src/xenxs/xen_sxpr.c +++ b/src/xenxs/xen_sxpr.c @@ -37,7 +37,7 @@ #include "xenxs_private.h" #include "xen_sxpr.h" -/* Get a domain id from a sexpr string */ +/* Get a domain id from a S-expression string */ int xenGetDomIdFromSxprString(const char *sexpr, int xendConfigVersion) { struct sexpr *root = string2sexpr(sexpr); @@ -50,7 +50,7 @@ int xenGetDomIdFromSxprString(const char *sexpr, int xendConfigVersion) return id; } -/* Get a domain id from a sexpr */ +/* Get a domain id from a S-expression */ int xenGetDomIdFromSxpr(const struct sexpr *root, int xendConfigVersion) { int id = -1; @@ -66,16 +66,15 @@ int xenGetDomIdFromSxpr(const struct sexpr *root, int xendConfigVersion) /***************************************************************** ****** - ****** Parsing of SEXPR into virDomainDef objects + ****** Parsing of S-Expression into virDomainDef objects ****** *****************************************************************/ /** - * xenParseSxprOS + * xenParseSxprOS: * @node: the root of the parsed S-Expression * @def: the domain config - * @hvm: true or 1 if no contains HVM S-Expression - * @bootloader: true or 1 if a bootloader is defined + * @hvm: true or 1 if node contains HVM S-Expression * * Parse the xend sexp for description of os and append it to buf. * @@ -166,6 +165,16 @@ no_memory: return -1; } + +/** + * xenParseSxprChar: + * @value: A string describing a character device. + * @tty: the console pty path + * + * Parse the xend S-expression for description of a character device. + * + * Returns a character device object or NULL in case of failure. + */ virDomainChrDefPtr xenParseSxprChar(const char *value, const char *tty) @@ -316,13 +325,15 @@ error: return NULL; } + /** - * xend_parse_sexp_desc_disks - * @conn: connection - * @root: root sexpr + * xenParseSxprDisks: + * @def: the domain config + * @root: root S-expression + * @hvm: true or 1 if node contains HVM S-Expression * @xendConfigVersion: version of xend * - * This parses out block devices from the domain sexpr + * This parses out block devices from the domain S-expression * * Returns 0 if successful or -1 if failed. */ @@ -518,6 +529,15 @@ error: } +/** + * xenParseSxprNets: + * @def: the domain config + * @root: root S-expression + * + * This parses out network devices from the domain S-expression + * + * Returns 0 if successful or -1 if failed. + */ static int xenParseSxprNets(virDomainDefPtr def, const struct sexpr *root) @@ -614,6 +634,15 @@ cleanup: } +/** + * xenParseSxprSound: + * @def: the domain config + * @str: comma separated list of sound models + * + * This parses out sound devices from the domain S-expression + * + * Returns 0 if successful or -1 if failed. + */ int xenParseSxprSound(virDomainDefPtr def, const char *str) @@ -692,6 +721,15 @@ error: } +/** + * xenParseSxprUSB: + * @def: the domain config + * @root: root S-expression + * + * This parses out USB devices from the domain S-expression + * + * Returns 0 if successful or -1 if failed. + */ static int xenParseSxprUSB(virDomainDefPtr def, const struct sexpr *root) @@ -733,6 +771,19 @@ no_memory: return -1; } + +/* + * xenParseSxprGraphicsOld: + * @def: the domain config + * @root: root S-expression + * @hvm: true or 1 if root contains HVM S-Expression + * @xendConfigVersion: version of xend + * @vncport: VNC port number + * + * This parses out VNC devices from the domain S-expression + * + * Returns 0 if successful or -1 if failed. + */ static int xenParseSxprGraphicsOld(virDomainDefPtr def, const struct sexpr *root, @@ -821,6 +872,16 @@ error: } +/* + * xenParseSxprGraphicsNew: + * @def: the domain config + * @root: root S-expression + * @vncport: VNC port number + * + * This parses out VNC devices from the domain S-expression + * + * Returns 0 if successful or -1 if failed. + */ static int xenParseSxprGraphicsNew(virDomainDefPtr def, const struct sexpr *root, int vncport) @@ -918,11 +979,13 @@ error: return -1; } + /** - * xenParseSxprPCI + * xenParseSxprPCI: + * @def: the domain config * @root: root sexpr * - * This parses out block devices from the domain sexpr + * This parses out PCI devices from the domain sexpr * * Returns 0 if successful or -1 if failed. */ @@ -1044,16 +1107,17 @@ error: /** * xenParseSxpr: - * @conn: the connection associated with the XML * @root: the root of the parsed S-Expression * @xendConfigVersion: version of xend * @cpus: set of cpus the domain may be pinned to + * @tty: the console pty path + * @vncport: VNC port number * - * Parse the xend sexp description and turn it into the XML format similar - * to the one unsed for creation. + * Parse the xend S-expression description and turn it into a virDomainDefPtr + * representing these settings as closeley as is practical. * - * Returns the 0 terminated XML string or NULL in case of error. - * the caller must free() the returned value. + * Returns the domain config or NULL in case of error. + * The caller must free() the returned value. */ virDomainDefPtr xenParseSxpr(const struct sexpr *root, @@ -1424,6 +1488,20 @@ error: return NULL; } + +/** + * xenParseSxprString: + * @sexpr: the root of the parsed S-Expression + * @xendConfigVersion: version of xend + * @tty: the console pty path + * @vncport: VNC port number + * + * Parse the xend S-expression description and turn it into a virDomainDefPtr + * representing these settings as closeley as is practical. + * + * Returns the domain config or NULL in case of error. + * The caller must free() the returned value. + */ virDomainDefPtr xenParseSxprString(const char *sexpr, int xendConfigVersion, char *tty, int vncport) @@ -1449,15 +1527,12 @@ xenParseSxprString(const char *sexpr, /** - * virtDomainParseXMLGraphicsDescVFB: - * @conn: pointer to the hypervisor connection - * @node: node containing graphics description - * @buf: a buffer for the result S-Expr + * xenFormatSxprGraphicsNew: + * @def: the domain config + * @buf: a buffer for the result S-expression * - * Parse the graphics part of the XML description and add it to the S-Expr - * in buf. This is a temporary interface as the S-Expr interface will be - * replaced by XML-RPC in the future. However the XML format should stay - * valid over time. + * Convert the graphics part of the domain description into a S-expression + * in buf. (HVM > 3.0.4 or PV > 3.0.3) * * Returns 0 in case of success, -1 in case of error */ @@ -1508,6 +1583,17 @@ xenFormatSxprGraphicsNew(virDomainGraphicsDefPtr def, } +/** + * xenFormatSxprGraphicsOld: + * @def: the domain config + * @buf: a buffer for the result S-expression + * @xendConfigVersion: version of xend + * + * Convert the graphics part of the domain description into a S-expression + * in buf. (HVM <= 3.0.4 or PV <= 3.0.3) + * + * Returns 0 in case of success, -1 in case of error + */ static int xenFormatSxprGraphicsOld(virDomainGraphicsDefPtr def, virBufferPtr buf, @@ -1553,6 +1639,17 @@ xenFormatSxprGraphicsOld(virDomainGraphicsDefPtr def, return 0; } + +/** + * xenFormatSxprChr: + * @def: the domain config + * @buf: a buffer for the result S-expression + * + * Convert the character deivce part of the domain config into a S-expression + * in buf. + * + * Returns 0 in case of success, -1 in case of error + */ int xenFormatSxprChr(virDomainChrDefPtr def, virBufferPtr buf) @@ -1631,15 +1728,14 @@ xenFormatSxprChr(virDomainChrDefPtr def, /** - * virDomainParseXMLDiskDesc: - * @node: node containing disk description - * @buf: a buffer for the result S-Expr + * xenFormatSxprDisk: + * @node: node containing the disk description + * @buf: a buffer for the result S-expression + * @hvm: true or 1 if domain is HVM * @xendConfigVersion: xend configuration file format + * @isAttach: create expression for device attach (1). * - * Parse the one disk in the XML description and add it to the S-Expr in buf - * This is a temporary interface as the S-Expr interface - * will be replaced by XML-RPC in the future. However the XML format should - * stay valid over time. + * Convert the disk device part of the domain config into a S-expresssion in buf. * * Returns 0 in case of success, -1 in case of error. */ @@ -1757,12 +1853,15 @@ xenFormatSxprDisk(virDomainDiskDefPtr def, } /** - * xenFormatSxprNet - * @node: node containing the interface description - * @buf: a buffer for the result S-Expr + * xenFormatSxprNet: + * @conn: connection + * @def: the domain config + * @buf: a buffer for the result S-expression + * @hvm: true or 1 if domain is HVM * @xendConfigVersion: xend configuration file format + * @isAttach: create expression for device attach (1). * - * Parse the one interface the XML description and add it to the S-Expr in buf + * Convert the interface description of the domain config into a S-expression in buf. * This is a temporary interface as the S-Expr interface * will be replaced by XML-RPC in the future. However the XML format should * stay valid over time. @@ -1893,6 +1992,15 @@ xenFormatSxprNet(virConnectPtr conn, } +/** + * xenFormatSxprPCI: + * @def: the device config + * @buf: a buffer for the result S-expression + * + * Convert a single PCI device part of the domain config into a S-expresssion in buf. + * + * Returns 0 in case of success, -1 in case of error. + */ static void xenFormatSxprPCI(virDomainHostdevDefPtr def, virBufferPtr buf) @@ -1904,6 +2012,17 @@ xenFormatSxprPCI(virDomainHostdevDefPtr def, def->source.subsys.u.pci.function); } + +/** + * xenFormatSxprOnePCI: + * @def: the device config + * @buf: a buffer for the result S-expression + * @detach: create expression for device detach (1). + * + * Convert a single PCI device part of the domain config into a S-expresssion in buf. + * + * Returns 0 in case of success, -1 in case of error. + */ int xenFormatSxprOnePCI(virDomainHostdevDefPtr def, virBufferPtr buf, @@ -1926,6 +2045,16 @@ xenFormatSxprOnePCI(virDomainHostdevDefPtr def, return 0; } + +/** + * xenFormatSxprAllPCI: + * @def: the domain config + * @buf: a buffer for the result S-expression + * + * Convert all PCI device parts of the domain config into a S-expresssion in buf. + * + * Returns 0 in case of success, -1 in case of error. + */ static int xenFormatSxprAllPCI(virDomainDefPtr def, virBufferPtr buf) @@ -1973,6 +2102,16 @@ xenFormatSxprAllPCI(virDomainDefPtr def, return 0; } + +/** + * xenFormatSxprSound: + * @def: the domain config + * @buf: a buffer for the result S-expression + * + * Convert all sound device parts of the domain config into S-expression in buf. + * + * Returns 0 if successful or -1 if failed. + */ int xenFormatSxprSound(virDomainDefPtr def, virBufferPtr buf) @@ -2001,6 +2140,15 @@ xenFormatSxprSound(virDomainDefPtr def, } +/** + * xenFormatSxprInput: + * @input: the input config + * @buf: a buffer for the result S-expression + * + * Convert all input device parts of the domain config into S-expression in buf. + * + * Returns 0 if successful or -1 if failed. + */ static int xenFormatSxprInput(virDomainInputDefPtr input, virBufferPtr buf) @@ -2033,7 +2181,7 @@ verify(MAX_VIRT_CPUS <= sizeof(1UL) * CHAR_BIT); * @def: domain config definition * @xendConfigVersion: xend configuration file format * - * Generate an SEXPR representing the domain configuration. + * Generate an S-expression representing the domain configuration. * * Returns the 0 terminated S-Expr string or NULL in case of error. * the caller must free() the returned value. -- 1.7.1

2 4

[libvirt] [PATCH] tests: virnettlscontexttest needs gnutls-2.6.0
by Philipp Hahn 31 Jan '12

31 Jan '12

virnettlscontexttest uses gnutls_x509_crt_set_subject_alt_name() and GNUTLS_FSAN_APPEND, which - according to <http://www.gnu.org/software/gnutls/manual/gnutls.html> - are only available since 2.6.0. Since libvirt still works fine with gnutls-1.0.25 from RHEL5, only enable the test when the version of GNUTLS is at least 2.6.0. Signed-off-by: Philipp Hahn <hahn(a)univention.de> --- tests/virnettlscontexttest.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/virnettlscontexttest.c b/tests/virnettlscontexttest.c index 51f75b4..6dd42d4 100644 --- a/tests/virnettlscontexttest.c +++ b/tests/virnettlscontexttest.c @@ -36,7 +36,7 @@ #include "virsocketaddr.h" #include "gnutls_1_0_compat.h" -#if !defined WIN32 && HAVE_LIBTASN1_H && !defined GNUTLS_1_0_COMPAT +#if !defined WIN32 && HAVE_LIBTASN1_H && !defined GNUTLS_1_0_COMPAT && LIBGNUTLS_VERSION_NUMBER > 0x020600 # include <libtasn1.h> # include "rpc/virnettlscontext.h" -- 1.7.1

3 4

[libvirt] [[libvirt-glib PATCHv3] 1/3] Add proper error reporting to gvir_storage_vol_get_path
by Christophe Fergeau 31 Jan '12

31 Jan '12

gvir_storage_vol_get_name currently call g_error when an error occurs. Since g_error trigger a coredump, calling it in a library is harmful. Replace this with proper GError error reporting. --- libvirt-gobject/libvirt-gobject-storage-vol.c | 7 +++++-- libvirt-gobject/libvirt-gobject-storage-vol.h | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/libvirt-gobject/libvirt-gobject-storage-vol.c b/libvirt-gobject/libvirt-gobject-storage-vol.c index 5b18877..5e83e1b 100644 --- a/libvirt-gobject/libvirt-gobject-storage-vol.c +++ b/libvirt-gobject/libvirt-gobject-storage-vol.c @@ -184,13 +184,16 @@ const gchar *gvir_storage_vol_get_name(GVirStorageVol *vol) return name; } -const gchar *gvir_storage_vol_get_path(GVirStorageVol *vol) +const gchar *gvir_storage_vol_get_path(GVirStorageVol *vol, GError **error) { GVirStorageVolPrivate *priv = vol->priv; const char *path; if (!(path = virStorageVolGetPath(priv->handle))) { - g_error("Failed to get storage_vol path on %p", priv->handle); + gvir_set_error(error, GVIR_STORAGE_VOL_ERROR, 0, + "Failed to get storage_vol path on %p", + priv->handle); + return NULL; } return path; diff --git a/libvirt-gobject/libvirt-gobject-storage-vol.h b/libvirt-gobject/libvirt-gobject-storage-vol.h index db63865..25f683a 100644 --- a/libvirt-gobject/libvirt-gobject-storage-vol.h +++ b/libvirt-gobject/libvirt-gobject-storage-vol.h @@ -78,7 +78,7 @@ GType gvir_storage_vol_info_get_type(void); GType gvir_storage_vol_handle_get_type(void); const gchar *gvir_storage_vol_get_name(GVirStorageVol *vol); -const gchar *gvir_storage_vol_get_path(GVirStorageVol *vol); +const gchar *gvir_storage_vol_get_path(GVirStorageVol *vol, GError **error); gboolean gvir_storage_vol_delete(GVirStorageVol *vol, guint flags, -- 1.7.7.6

2 5

[libvirt] RFC: setting mac address on network devices being assigned to a guest via PCI passthrough (<hostdev>)
by Laine Stump 31 Jan '12

31 Jan '12

To refresh everyone's memory, the origin of the problem I'm trying to solve here is that the VFs of an SRIOV-capable ethernet card are given new random MAC addresses each time the card is initialized. If those VFs are then passed-through to a guest using the existing <hostdev> config, the guest will see a new MAC address each time the host is restarted, and will thus believe that a new ethernet card has been installed. This can result in anything from a dialog claiming that the guest has connected to a new network (MS products) to a new network device name showing up (Linux - "hmm, eth0 was unplugged, but here's this new device. Let's call it "eth1"!) Several months ago I sent out some mail proposing a scheme for automatically allocating network devices from a pool to be assigned to guests via PCI passthrough: https://www.redhat.com/archives/libvir-list/2011-August/msg00937.html My idea was to have a new <network> forward mode combined with guest <interface> definitions that would end up auto-generating a transient <hostdev> entry in the guest's config (and setting the VF's mac address in the process). Dan Berrange pointed out in that thread that we really do need to have a persistent <hostdev> entry for these devices in the domain xml, if for no other reason than to guarantee that the same guest-side PCI address is always used (thus preventing surprises in the guest, such as re-activation demands from Microsoft OSes). (There were other reasons, but that one was the real "hard stop" for me.) I've come back to this problem, and have decided that, while having the actual host device auto-allocated at runtime would be nice, first implementing a less ambitious solution that uses a hand-picked device would not preclude adding the more complicated/useful functionality later. So, here's a new simpler proposal. Step 1 ------ In the end, the solution will be that the VF's auto-generated random MAC address should be replaced with a fixed MAC address supplied by libvirt prior to assigning the VF to the guest. As a first step to satisfy this basic requirement, I'm figuring to just extend the <hostdev> xml in this way: |<hostdev mode='subsystem' type='pci' managed='yes'> |<source> |<address bus='0x06' slot='0x02' function='0x0'/> |</source> |<mac address='11:22:33:44:55:66"/> |</hostdev> When libvirt sees <mac address...> in the hostdev at device attach time, it would first verify that the device is a network device (if not, it would log an error and fail the operation). If it is a network device, the pci address would be converted into a network device name, and that device would have its MAC address set to the configured value, and then the attach would proceed. My main questions here are: 1) Is this the right place for the new element? Or should it go into <source>? 2) Should we bother trying to save the original MAC address to restore when the device is released? (I guess that might be important if, for example, the guest config was changed to use a different device but same MAC address - you could end up with two devices having the same MAC address). 3) I've seen requests from 2 places to do host-side virtual port association (i.e. vepa / 802.1Qb[gh]). Would it be feasible to do that association with the device after setting MAC address and before assigning it to the guest? (and likewise for the inverse) Or would the act of PCI assignment screw that up somehow? (one of the messages in the earlier thread says something about the device initialization by the guest un-doing necessary setup) (if it would work, a <virtualport> could just be added along with <mac address>). Beyond those 3 questons, this all seems rather uncontroversial, so I'll start coding something up right away (and modify as necessary after discussion). Step 2 ------ Once the basic functionality is in place, a further step would be one just to simplify the admins job - we could do this by replacing this config: | <source> | <address bus='x' slot='y' function='z'/> | </source> with: | <source> | <address netdev='eth22'/> | </source> (or possibly it could be a separate element within <source>, e.g. "<network dev='eth22'/>") As long as the domain isn't running, the config would remain like this. The first time the device was attached, the name in netdev would be resolved to a pci address (or failed if the given netdev wasn't a PCI device); and the config auto-filled as follows: | <source> | <address bus='x' slot='y' function='z' netdev='eth22'/> | </source> On subsequent attaches (i.e. when both netdev and a pci address are present) the netdev would again be resolved and compared to the pci address to make sure they still agree; if not, the operation would fail. This would satisfy management applications' desire to see the pci address info of all devices assigned to guests, while retaining the original config info (and also lead quite nicely into step 3...). Step 3 ------ To further simplify configuration, it would be very nice if the choice of network device could be done automatically. Since libvirt's networks already have the concept of a pool of devices (and also of portgroups which can be used to set <virtualport> parameters), it kind of makes to sense to use that. In this case, a network would be defined something like this: | <network> | <name>passthrough-net</name> | <forward dev='eth20' mode='hostdev'>  | <interface dev='eth20'/> | <interface dev='eth21'/> | <interface dev='eth22'/> | .. | </forward> | </network> (it could also contain a virtualport definition and/or portgroups containing virtualport definitions. Obviously, we would have to prohibit <bandwidth> elements (and several other things) in the definitions>) Then, in lieu of a pci address or network device name (as "netdev"), the <hostdev>'s <source> would have a reference to the network: |<hostdev mode='subsystem' type='pci' managed='yes'> |<source> |<address network='passthrough-net'/> |</source> |<mac address='11:22:33:44:55:66"/> |</hostdev> (or, again, maybe use the separate <network> element: "<network name='passthrough-net'/>) At attach time, the pool of devices in passthrough-net would be searched for a free device, and if found, that device would have its MAC address changed and be assigned to the guest. In this case, the live XML would be updated with the pci address information, but when the guest was destroyed, the device would be handed back to the pool, and the pci address info once again removed from the config. Step 2 & 3 probably won't be implemented right away, but I thought I should toss the ideas out there in case they lead to something else that would require a change in step 1.

3 11