August 2011 - Devel - libvirt List Archives

[libvirt] managedsave vs. transient domains
by Eric Blake 11 Aug '11

11 Aug '11

How in the world is managedsave supposed to work on transient domains? The moment you save a domain, the qemu process is ended; but ending the qemu process means that a transient domain no longer has any state tracked by libvirt. Should libvirt be temporarily defining a domain when creating a managedsave of a transient domain? Seeing as how persistent domains cannot be marked autostart, does this mean that you have to use 'virsh start dom' rather than autostart to restart a transient domain with managedsave state? Or should managedsave be prohibited on transient domains, and only exist as a possibility for persistent ones? After all, qemuDomainHasManagedSaveImage() will always return false for a running domain - a managed save state file only exists if you have shut down the domain into managed state file with plans to later start from that file. Personally, I'm leaning towards the latter - just like virDomainSetAutostart fails on transient domains, I think virDomainManagedSave should likewise fail on transient domains, and that applications that favor transient domains should also be managing state files themselves, via virDomainSave[Flags], rather than relying on virDomainManagedSave. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

2 3

[libvirt] [PATCH] docs: describe new virtual switch configuration in network XML docs
by Laine Stump 11 Aug '11

11 Aug '11

This should have been done with the rest of the patch for virtual switch / network device abstraction. If documents the new elements (and new usage of existing elements) in the <network> XML to support libvirt networks that use existing host bridges and macvtap direct connections, as well as the new <portgroup> element. --- docs/formatnetwork.html.in | 286 ++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 262 insertions(+), 24 deletions(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index ddfa77c..4be03cd 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -70,36 +70,172 @@ bridge device allowing them to talk to each other. The bridge device may also be connected to the LAN. It is recommended that bridge device names started with the prefix <code>vir</code>, but the name - <code>virbr0</code> is reserved for the "default" virtual network. - This element should always be provided when defining a new network. - Attribute <code>stp</code> specifies if Spanning Tree Protocol is - 'on' or 'off' (default is 'on'). Attribute <code>delay</code> sets - the bridge's forward delay value in seconds (default is 0). + <code>virbr0</code> is reserved for the "default" virtual + network. This element should always be provided when defining + a new network with a <code><forward></code> mode of + "nat" or "route" (or an isolated network with + no <code><forward></code> element). + Attribute <code>stp</code> specifies if Spanning Tree Protocol + is 'on' or 'off' (default is + 'on'). Attribute <code>delay</code> sets the bridge's forward + delay value in seconds (default is 0). Since 0.3.0 </dd> <dt><code>domain</code></dt> <dd> - The <code>name</code> attribute on the <code>domain</code> element - defines the DNS domain of the DHCP server. This element is optional. - Since 0.4.5 + The <code>name</code> attribute on the <code>domain</code> + element defines the DNS domain of the DHCP server. This + element is optional, and is only used for those networks with + a <code><forward></code> mode of "nat" or "route" (or an + isolated network with no <code><forward></code> + element). Since 0.4.5 </dd> <dt><code>forward</code></dt> <dd>Inclusion of the <code>forward</code> element indicates that the virtual network is to be connected to the physical - LAN. the <code>mode</code> attribute determines the method of - forwarding; possible selections are 'nat' and 'route'. If mode - is not specified, NAT forwarding will be used for - connectivity. If a network has any IPv6 addresses defined, - even if <code>mode</code> is given as 'nat', the IPv6 traffic - will be forwarded using routing, since IPv6 has no concept of NAT. - Firewall rules will allow forwarding to any other network device whether - ethernet, wireless, dialup, or VPN. If the <code>dev</code> attribute - is set, the firewall rules will restrict forwarding to the named - device only. If the <code>mode</code> attribute is set to <code>route</code> - then the traffic will not have NAT applied. This presumes that the - local LAN router has suitable routing table entries to return traffic - to this host. Since 0.3.0; 'mode' attribute since - 0.4.2</dd> + LAN.Since 0.3.0. + The <code>mode</code> attribute determines the method of + forwarding. If there is no <code>forward</code> element, the + network will be isolated from any other network (unless a + guest connected to that network is acting as a router, of + course). The following are valid settings + for <code>mode</code> (if there is a <code>forward</code> + element but mode is not specified, <code>mode='nat'</code> is + assumed): + <dl> + <dt><code>nat</code></dt> + <dd> + All traffic between guests connected to this network and + the physical network will be forwarded to the physical + network via the host's IP routing stack, after the guest's + IP address is translated to appear as the host machine's + public IP address (a.k.a. Network Address Translation, or + "NAT"). This allows multiple guests, all having access to + the physical network, on a host that is only allowed a + single public IP address. If a network has any IPv6 + addresses defined, the IPv6 traffic will be forwarded + using plain routing, since IPv6 has no concept of NAT. + Firewall rules will allow outbound connections to any + other network device whether ethernet, wireless, dialup, + or VPN. If the <code>dev</code> attribute is set, the + firewall rules will restrict forwarding to the named + device only. Inbound connections from other networks are + all prohibited; all connections between guests on the same + network, and to/from the host to the guests, are + unrestricted and not NATed.Since + 0.4.2 + </dd> + + <dt><code>route</code></dt> + <dd> + Guest network traffic will be forwarded to the physical + network via the host's IP routing stack, but without + having NAT applied. Again, if the <code>dev</code> + attribute is set, firewall rules will restrict forwarding + to the named device only. This presumes that the local LAN + router has suitable routing table entries to return + traffic to this host. Firewall rules are also installed + that prevent incoming sessions from the physical network + to the guests, but outgoing sessions are unrestricted (as + are sessions from the host to the guests, and between + guests on the same network.)Since + 0.4.2 + </dd> + + <dt><code>bridge</code></dt> + <dd> + This network describes either 1) an existing host bridge + that was configured outside of libvirt (if + a <code><bridge name='xyz'/></code> element has been + specified), or 2) an interface or group of interfaces to + be used for a "direct" connection via macvtap using + macvtap's "bridge" mode (if the forward element has one or + more <code><interface></code> subelements) + (see <a href="formatdomain.html#elementsNICSDirect">Direct + attachment to physical interface</a> for descriptions of + the various macvtap modes). libvirt doesn't attempt to + manage the bridge interface at all, thus + the <code><bridge></code> element's <code>stp</code> + and <code>delay</code> attributes are not allowed; no + iptables rules, IP addresses, or DHCP/DNS services are + added; at the IP level, the guest interface appears to be + directly connected to the physical + interface.Since 0.9.4 + </dd> + <dt><code>private</code></dt> + <dd> + This network uses a macvtap "direct" connection in + "private" mode to connect each guest to the network. The + physical interface to be used will be picked from among + those listed in <code><interface></code> subelements + of the <code><forward></code> element; when using + 802.1Qbh mode (as indicated by + the <code><virtualport></code> type attribute - note + that this requires an 802.1Qbh-capable hardware switch), + each physical interface can only be in use by a single + guest interface at a time; in modes other than 802.1Qbh, + multiple guest interfaces can share each physical + interface (libvirt will attempt to balance usage between + all available interfaces).Since + 0.9.4 + </dd> + <dt><code>vepa</code></dt> + <dd> + This network uses a macvtap "direct" connection in "vepa" + mode to connect each guest to the network (this requires + that the physical interfaces used be connected to a + vepa-capable hardware switch. The physical interface to be + used will be picked from among those listed + in <code><interface></code> subelements of + the <code><forward></code> element; multiple guest + interfaces can share each physical interface (libvirt will + attempt to balance usage between all available + interfaces).Since 0.9.4 + </dd> + <dt><code>passthrough</code></dt> + <dd> + This network uses a macvtap "direct" connection in + "passthrough" mode to connect each guest to the network + (note that this is not the same thing as "PCI + passthrough"). The physical interface to be used will be + picked from among those listed + in <code><interface></code> subelements of + the <code><forward></code> element. Each physical + interface can only be in use by a single guest interface + at a time, so libvirt will keep track of which interfaces + are currently in use, and only assign unused interfaces + (if there are no available physical interfaces when a + domain interface is being attached, an error will be + logged, and the operation causing the attach will fail + (usually either a domain start, or a hotplug interface + attach to a domain).Since 0.9.4 + </dd> + </dl> + As mentioned above, a <code><forward></code> element can + have multiple <code><interface></code> subelements, each + one giving the name of a physical interface that can be used + for this networkSince 0.9.4: + <pre> +... + <forward mode='passthrough'> + <interface dev='eth10'/> + <interface dev='eth11'/> + <interface dev='eth12'/> + <interface dev='eth13'/> + <interface dev='eth14'/> + </forward> +... + </pre> + When a guest interface is being constructed, libvirt will pick + an interface from this list to use for the connection. In + modes where physical interfaces can be shared by multiple + guest interfaces, libvirt will choose the interface that + currently has the least number of connections. For those modes + that do not allow sharing of the physical device (in + particular, 'passthrough' mode, and 'private' mode when using + 802.1Qbh), libvirt will choose an unused physical interface + or, if it can't find an unused interface, fail the operation. + </dd> </dl> <h5><a name="elementQoS">Quality of service</a></h5> @@ -110,7 +246,6 @@ <inbound average='1000' peak='5000' burst='5120'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> - <mac address='00:16:3E:5D:C7:9E'/> ...</pre> @@ -134,13 +269,66 @@ Since 0.9.4 + <h5><a name="elementsPortgroup">Portgroups</a></h5> + +<pre> +... + <forward mode='vepa'/> + <bridge name='br0'/> + <portgroup name='engineering' default='yes'> + <virtualport type='802.1Qbg'> + <parameters profileid='test'/> + </virtualport> + <bandwidth> + <inbound average='1000' peak='5000' burst='5120'/> + <outbound average='1000' peak='5000' burst='5120'/> + </bandwidth> + &lt/portgroup> + <portgroup name='sales'> + <virtualport type='802.1Qbg'> + <parameters profileid='salestest'/> + </virtualport> + <bandwidth> + <inbound average='500' peak='2000' burst='2560'/> + <outbound average='128' peak='256' burst='256'/> + </bandwidth> + &lt/portgroup> +...</pre> + + + A portgroup provides a method of easily putting guest + connections to the network into different classes, with each + class potentially having a different level/type of service. Each + network can have multiple portgroup elements (and one of those + can optionally be designated as the 'default' portgroup for the + network), and each portgroup has a name, as well as various + subelements associated with it. The currently supported + subelements are <code><bandwidth></code> + and <code><virtualport></code>, which are both fully + described in the domain XML documentation. If a domain + interface definition specifies a portgroup (by adding + a <code>portgroup</code> attribute to + the <code><source></code> subelement), that portgroup's + info will be merged into the interface's configuration. If no + portgroup is given in the interface definition, and one of the + network's portgroups has <code>default='yes'</code>, that + default portgroup will be used. If no portgroup is given in the + interface definition, and there is no default portgroup, then + none will be used. Any <code><bandwidth></code> + or <code><virtualport></code> specified directly in the + domain XML will take precedence over any setting in the chosen + portgroup. + + <h3><a name="elementsAddress">Addressing</a></h3> The final set of elements define the addresses (IPv4 and/or IPv6, as well as MAC) to be assigned to the bridge device associated with the virtual network, and optionally enable DHCP - services. + services. These elements are only valid for isolated networks + (no <code>forward</code> element specified), and for those with + a forward mode of 'route' or 'nat'. <pre> @@ -345,5 +533,55 @@ <ip family="ipv6" address="2001:8794:ca2:3::1" prefix="64" /> </network></pre> + <h3><a name="examplesBridge">Using an existing host bridge</a></h3> + + + This shows how to use a pre-existing host bridge "br0". The + guests will effectively be directly connected to the physical + network (i.e. their IP addresses will all be on the subnet of + the physical network, and there will be no restrictions on + inbound or outbound connections). + + + <pre> + <network> + <name>host-bridge</name> + <forward mode="bridge"/> + <bridge name="br0"/> + </network></pre> + + <h3><a name="examplesDirect">Using a macvtap "direct" connection</a></h3> + + + This shows how to use macvtap to connect to the physical network + directly through one of a group of physical devices (without + using a host bridge device). As with the host bridge network, + the guests will effectively be directly connected to the + physical network so their IP addresses will all be on the subnet + of the physical network, and there will be no restrictions on + inbound or outbound connections. Note that, due to a limitation + in the implementation of macvtap, these connections do not allow + communication directly between the host and the guests - if you + require this you will either need the attached physical switch + to be operating in a mirroring mode (so that all traffic coming + to the switch is reflected back to the host's interface), or + provide alternate means for this communication (e.g. a second + interface on each guest that is connected to an isolated + network). The other forward modes that use macvtap (private, + vepa, and passthrough) would be used in a similar fashion. + + + <pre> + <network> + <name>direct-macvtap</name> + <forward mode="bridge"> + <interface dev="eth20"/> + <interface dev="eth21"/> + <interface dev="eth22"/> + <interface dev="eth23"/> + <interface dev="eth24"/> + </forward> + </network></pre> + </body> </html> -- 1.7.3.4

3 3

[libvirt] Is there smt missing at Java bindings?
by kadir yüceer 10 Aug '11

10 Aug '11

Hello all, I've been posting questions about my issue to the user list but it seems nobody can answer, so I had to try this list, sorry if there is any disturbance. Here is the case: I've been trying to develop a java app that can register callbacks for domain lifecycle events(suspend,resume,etc.). Only method that I've seen is Connect.VirDomainEventRegisterAny, and there is an abstract callback method inside VirConnectDomainEventGenericCallback. I implement the callback, and register it for all the domains by passing the domain pointer as NULL. Additionally for testing, I've added a println into the suspend function in org.libvirt.Domain.java, and compiled the java bindings and used the new jar file, and I was successful, I can see the message whenever I suspend the domain either by clicking *pause* or by writing dom.suspend() in my java app. However, when I try to register a callback as I mentioned in the beginning (with eventID 0, which is life_cycle ID), after the suspend operation, I get the error that you can see at the end of the mail. But before you check it out, I have to ask, are some of the event-related features of libvirt missing in java bindings? For example; VirEventAddHandleFunc, VirEventAddHandleCallback, and their derivatives. Is this a problem or the only Connect.VirDomainEventRegisterAny method of java binding suffice for providing callbacks for domain events? Thanks in advance for your responses. The error is below. Kind Regards Kadir # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000000, pid=5692, tid=3077520240 # # JRE version: 6.0_20-b20 # Java VM: OpenJDK Server VM (19.0-b09 mixed mode linux-x86 ) # Derivative: IcedTea6 1.9.7 # Distribution: Ubuntu 10.10, package 6b20-1.9.7-0ubuntu1 # Problematic frame: # C 0x00000000 # # An error report file with more information is saved as: # /root/NetBeansProjects/NovaTest_v0.3/hs_err_pid5692.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Java Result: 134

2 2

[libvirt] [PATCH 0/4] snapshot improvements
by Eric Blake 10 Aug '11

10 Aug '11

There's still a lot to go before virsh snapshot can manage disk snapshots in addition to checkpoints, but I wanted to get the review started on these. Even with these patches, there are some major bugs with snapshots: 1. Snapshots aren't storing the domain XML. If you create a snapshot, then hotplug a device, then revert to the snapshot, then the reversion process should include hot-unplugging that device (qemu won't automatically do it); fixing that requires diffing the xml between now and the reversion point. 2. Restarting libvirtd forgets which snapshot is current. When creating a new snapshot, it is important to remember the current snapshot in order to track the relationships correctly. 3. Deleting a domain that has snapshots doesn't warn. Unlike managed save images, where this represents data loss (you are throwing away the saved RAM state of the guest), it might be possible to permit undefining a domain with snapshots, but that would require a way to define a domain based on a snapshot, so maybe it really is better to prohibit undefining a domain with snapshots. 4. Probably more issues that need thinking about... Eric Blake (4): qemu: minor formatting cleanup qemu: give correct event when reverting to paused snapshot qemu: improve reverting to paused snapshots virsh: concatenate qemu-monitor-command arguments include/libvirt/libvirt.h.in | 3 +- src/qemu/qemu_driver.c | 76 +++++++++++++++++++++++++----------------- tools/virsh.c | 19 ++++++++-- tools/virsh.pod | 6 ++- 4 files changed, 66 insertions(+), 38 deletions(-) -- 1.7.4.4

3 14

[libvirt] [PATCH] qemu: Fix -chardev udp if parameters are omitted
by Cole Robinson 10 Aug '11

10 Aug '11

The following XML: <serial type='udp'> <source mode='connect' service='9999'/> </serial> is accepted by domain_conf.c but maps to the qemu command line: -chardev udp,host=127.0.0.1,port=2222,localaddr=(null),localport=(null) qemu can cope with everything omitting except the connection port, which seems to also be the intent of domain_conf validation, so let's not generate bogus command lines for that case. Additionally, tweak the qemu cli parsing to handle omitted host parameters for -serial udp --- src/qemu/qemu_command.c | 48 +++++++++++--------- .../qemuxml2argv-serial-udp-chardev.args | 6 ++- .../qemuxml2argv-serial-udp-chardev.xml | 4 ++ .../qemuxml2argvdata/qemuxml2argv-serial-udp.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml | 4 ++ 5 files changed, 39 insertions(+), 25 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index c9b9850..231d7c3 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2119,14 +2119,17 @@ qemuBuildChrChardevStr(virDomainChrSourceDefPtr dev, const char *alias, break; case VIR_DOMAIN_CHR_TYPE_UDP: - virBufferVSprintf(&buf, - "udp,id=char%s,host=%s,port=%s,localaddr=%s," - "localport=%s", + virBufferVSprintf(&buf, "udp,id=char%s,port=%s", alias, - dev->data.udp.connectHost, - dev->data.udp.connectService, - dev->data.udp.bindHost, - dev->data.udp.bindService); + dev->data.udp.connectService); + + if (dev->data.udp.connectHost) + virBufferVSprintf(&buf, ",host=%s", dev->data.udp.connectHost); + if (dev->data.udp.bindHost) + virBufferVSprintf(&buf, ",localaddr=%s", dev->data.udp.bindHost); + if (dev->data.udp.bindService) + virBufferVSprintf(&buf, ",localport=%s", + dev->data.udp.bindService); break; case VIR_DOMAIN_CHR_TYPE_TCP: @@ -2216,11 +2219,13 @@ qemuBuildChrArgStr(virDomainChrSourceDefPtr dev, const char *prefix) break; case VIR_DOMAIN_CHR_TYPE_UDP: - virBufferVSprintf(&buf, "udp:%s:%s@%s:%s", - dev->data.udp.connectHost, - dev->data.udp.connectService, - dev->data.udp.bindHost, - dev->data.udp.bindService); + virBufferVSprintf(&buf, "udp:%s:%s", + dev->data.udp.connectHost ?: "", + dev->data.udp.connectService); + if (dev->data.udp.bindService) + virBufferVSprintf(&buf, "@%s:%s", + dev->data.udp.bindHost ?: "", + dev->data.udp.bindService); break; case VIR_DOMAIN_CHR_TYPE_TCP: @@ -5302,13 +5307,12 @@ qemuParseCommandLineChr(const char *val) host2 = svc1 ? strchr(svc1, '@') : NULL; svc2 = host2 ? strchr(host2, ':') : NULL; - if (svc1) + if (svc1 && (svc1 != val)) { def->source.data.udp.connectHost = strndup(val, svc1-val); - else - def->source.data.udp.connectHost = strdup(val); - if (!def->source.data.udp.connectHost) - goto no_memory; + if (!def->source.data.udp.connectHost) + goto no_memory; + } if (svc1) { svc1++; @@ -5323,14 +5327,14 @@ qemuParseCommandLineChr(const char *val) if (host2) { host2++; - if (svc2) + if (svc2 && (svc2 != host2)) { def->source.data.udp.bindHost = strndup(host2, svc2-host2); - else - def->source.data.udp.bindHost = strdup(host2); - if (!def->source.data.udp.bindHost) - goto no_memory; + if (!def->source.data.udp.bindHost) + goto no_memory; + } } + if (svc2) { svc2++; def->source.data.udp.bindService = strdup(svc2); diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.args b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.args index 7525110..8c6a6d5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.args @@ -2,6 +2,8 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M \ pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults -chardev socket,\ id=charmonitor,path=/tmp/test-monitor,server,nowait -mon chardev=charmonitor,\ id=monitor,mode=readline -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -chardev \ -udp,id=charserial0,host=127.0.0.1,port=9998,localaddr=127.0.0.1,localport=9999 \ --device isa-serial,chardev=charserial0,id=serial0 -usb -device \ +udp,id=charserial0,port=9998,host=127.0.0.1,localaddr=127.0.0.1,localport=9999 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev udp,id=charserial1,port=9999 \ +-device isa-serial,chardev=charserial1,id=serial1 -usb -device \ virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.xml index 12622d4..9627c67 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.xml @@ -25,6 +25,10 @@ <source mode='connect' host='127.0.0.1' service='9998'/> <target port='0'/> </serial> + <serial type='udp'> + <source mode='connect' service='9999'/> + <target port='1'/> + </serial> <console type='udp'> <source mode='bind' host='127.0.0.1' service='9999'/> <source mode='connect' host='127.0.0.1' service='9998'/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.args b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.args index 53c69bc..cf25fe0 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.args @@ -1,4 +1,4 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M \ pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait \ -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial \ -udp:127.0.0.1:9998@127.0.0.1:9999 -parallel none -usb +udp:127.0.0.1:9998@127.0.0.1:9999 -serial udp::9999 -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml index 8697f5a..f606ea4 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml @@ -25,6 +25,10 @@ <source mode='connect' host='127.0.0.1' service='9998'/> <target port='0'/> </serial> + <serial type='udp'> + <source mode='connect' service='9999'/> + <target port='1'/> + </serial> <console type='udp'> <source mode='bind' host='127.0.0.1' service='9999'/> <source mode='connect' host='127.0.0.1' service='9998'/> -- 1.7.4

3 3

[libvirt] [RFC v2] Export KVM Host Power Management capabilities
by Srivatsa S. Bhat 10 Aug '11

10 Aug '11

This patch exports KVM Host Power Management capabilities as XML so that higher-level systems management software can make use of these features available in the host. The script "pm-is-supported" (from pm-utils package) is run to discover if Suspend-to-RAM (S3) or Suspend-to-Disk (S4) is supported by the host. If either of them are supported, then a new tag "<power_management>" is introduced in the XML under the <host> tag. Eg: When the host supports both S3 and S4, the XML looks like this: <capabilities> <host> <uuid>dc699581-48a2-11cb-b8a8-9a0265a79bbe</uuid> <cpu> <arch>i686</arch> <model>coreduo</model> <vendor>Intel</vendor> <topology sockets='1' cores='2' threads='1'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> </cpu> <power_management> <<<=== New host power management features <S3/> <S4/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> </host> . . . However in case the host does not support any power management feature, then the XML will not contain the <power_management> tag. The initial discussion about this patch was done in [1]. And the choice to name the new tag as "power_management" was discussed in [2]. Please let me know your comments and feedback. References: ---------- [1] Exporting KVM host power saving capabilities through libvirt http://thread.gmane.org/gmane.comp.emulators.libvirt/40886 [2] http://article.gmane.org/gmane.comp.emulators.libvirt/41688 Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat(a)linux.vnet.ibm.com> --- src/conf/capabilities.c | 34 +++++++++++++++++++++++++++ src/conf/capabilities.h | 7 ++++++ src/libvirt_private.syms | 2 ++ src/qemu/qemu_capabilities.c | 10 ++++++++ src/util/util.c | 52 ++++++++++++++++++++++++++++++++++++++++++ src/util/util.h | 7 ++++++ 6 files changed, 112 insertions(+), 0 deletions(-) diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c index 2f243ae..94423dc 100644 --- a/src/conf/capabilities.c +++ b/src/conf/capabilities.c @@ -166,6 +166,10 @@ virCapabilitiesFree(virCapsPtr caps) { virCapabilitiesFreeNUMAInfo(caps); + for(i = 0; i < caps->host.npowerMgmt ; i++) + VIR_FREE(caps->host.powerMgmt[i]); + VIR_FREE(caps->host.powerMgmt); + for (i = 0 ; i < caps->host.nmigrateTrans ; i++) VIR_FREE(caps->host.migrateTrans[i]); VIR_FREE(caps->host.migrateTrans); @@ -201,6 +205,27 @@ virCapabilitiesAddHostFeature(virCapsPtr caps, return 0; } +/** + * virCapabilitiesAddHostPowerManagement: + * @caps: capabilities to extend + * @name: name of power management feature + * + * Registers a new host power management feature, eg: 'S3' or 'S4' + */ +int +virCapabilitiesAddHostPowerManagement(virCapsPtr caps, + const char *name) +{ + if(VIR_RESIZE_N(caps->host.powerMgmt, caps->host.npowerMgmt_max, + caps->host.npowerMgmt, 1) < 0) + return -1; + + if((caps->host.powerMgmt[caps->host.npowerMgmt] = strdup(name)) == NULL) + return -1; + caps->host.npowerMgmt++; + + return 0; +} /** * virCapabilitiesAddHostMigrateTransport: @@ -686,6 +711,15 @@ virCapabilitiesFormatXML(virCapsPtr caps) virBufferAddLit(&xml, " </cpu>\n"); + if(caps->host.npowerMgmt) { + virBufferAddLit(&xml, " <power_management>\n"); + for (i = 0; i < caps->host.npowerMgmt ; i++) { + virBufferAsprintf(&xml, " <%s/>\n", + caps->host.powerMgmt[i]); + } + virBufferAddLit(&xml, " </power_management>\n"); + } + if (caps->host.offlineMigrate) { virBufferAddLit(&xml, " <migration_features>\n"); if (caps->host.liveMigrate) diff --git a/src/conf/capabilities.h b/src/conf/capabilities.h index e2fa1d6..eb6e561 100644 --- a/src/conf/capabilities.h +++ b/src/conf/capabilities.h @@ -105,6 +105,9 @@ struct _virCapsHost { size_t nfeatures; size_t nfeatures_max; char **features; + size_t npowerMgmt; + size_t npowerMgmt_max; + char **powerMgmt; int offlineMigrate; int liveMigrate; size_t nmigrateTrans; @@ -186,6 +189,10 @@ virCapabilitiesAddHostFeature(virCapsPtr caps, const char *name); extern int +virCapabilitiesAddHostPowerManagement(virCapsPtr caps, + const char *name); + +extern int virCapabilitiesAddHostMigrateTransport(virCapsPtr caps, const char *name); diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 830222b..5754fdd 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -41,6 +41,7 @@ virCapabilitiesAddGuestFeature; virCapabilitiesAddHostFeature; virCapabilitiesAddHostMigrateTransport; virCapabilitiesAddHostNUMACell; +virCapabilitiesAddHostPowerManagement; virCapabilitiesAllocMachines; virCapabilitiesDefaultGuestArch; virCapabilitiesDefaultGuestEmulator; @@ -1025,6 +1026,7 @@ safezero; virArgvToString; virAsprintf; virBuildPathInternal; +virCheckPMCapability; virDirCreate; virEmitXMLWarning; virEnumFromString; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 3f36212..6e969a7 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -824,6 +824,16 @@ virCapsPtr qemuCapsInit(virCapsPtr old_caps) old_caps->host.cpu = NULL; } + /* Add the power management features of the host */ + + /* Check for Suspend-to-RAM support (S3) */ + if(virCheckPMCapability(HOST_PM_S3) == 0) + virCapabilitiesAddHostPowerManagement(caps, "S3"); + + /* Check for Suspend-to-Disk support (S4) */ + if(virCheckPMCapability(HOST_PM_S4) == 0) + virCapabilitiesAddHostPowerManagement(caps, "S4"); + virCapabilitiesAddHostMigrateTransport(caps, "tcp"); diff --git a/src/util/util.c b/src/util/util.c index 03a9e1a..9893597 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -2641,3 +2641,55 @@ or other application using the libvirt API.\n\ return 0; } + +/** + * Check the Power Management Capabilities of the host system. + * The script 'pm-is-supported' (from the pm-utils package) is run + * to find out if the capability is supported by the host. + * + * @capability: capability to check for + * HOST_PM_S3: Check for Suspend-to-RAM support + * HOST_PM_S4: Check for Suspend-to-Disk support + * + * Returns 0 if supported, -1 if not supported. + */ +int +virCheckPMCapability(int capability) +{ + + char *path = NULL; + int status = -1, ret = -1; + virCommandPtr cmd; + + if((path = virFindFileInPath("pm-is-supported")) == NULL) + return -1; + + cmd = virCommandNew(path); + switch(capability) { + case HOST_PM_S3: + /* Check support for suspend (S3) */ + virCommandAddArg(cmd, "--suspend"); + break; + + case HOST_PM_S4: + /* Check support for hibernation (S4) */ + virCommandAddArg(cmd, "--hibernate"); + break; + + default: + goto cleanup; + } + + if(virCommandRun(cmd, &status) < 0) + goto cleanup; + + /* Check return code of command == 0 for success */ + if(status == 0) + ret = 0; + +cleanup: + virCommandFree(cmd); + VIR_FREE(path); + return ret; +} + diff --git a/src/util/util.h b/src/util/util.h index af8b15d..c428eb4 100644 --- a/src/util/util.h +++ b/src/util/util.h @@ -272,4 +272,11 @@ bool virIsDevMapperDevice(const char *devname) ATTRIBUTE_NONNULL(1); int virEmitXMLWarning(int fd, const char *name, const char *cmd) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3); + +/* Power Management Capabilities of the host system */ +# define HOST_PM_S3 1 /* Suspend-to-RAM */ +# define HOST_PM_S4 2 /* Suspend-to-Disk */ + +int virCheckPMCapability(int capability); + #endif /* __VIR_UTIL_H__ */

5 9

[libvirt] [BUG] Re: [2/6] loadvm: improve tests before bdrv_snapshot_goto()
by Philipp Hahn 09 Aug '11

09 Aug '11

Hello, Am Dienstag 03 August 2010 06:44:26 schrieb Kevin Wolf: > From: Miguel Di Ciurcio Filho <miguel.filho(a)gmail.com> > > This patch improves the resilience of the load_vmstate() function, doing > further and better ordered tests. This patch broke restoring not-running VMs using libvirt-0.8.7 with qemu-0.14: When the domain is not running while taking a snpshot, the sn.vm_state_size == 0: 2021 } else if (sn.vm_state_size == 0) { (gdb) print sn $6 = {id_str = "1", '\0' <repeats 126 times>, name = "pre-update-flash", '\0' <repeats 239 times>, vm_state_size = 0, date_sec = 1302698007, date_nsec = 711909000, vm_clock_nsec = 0} > The [old] process: ... > - run bdrv_snapshot_goto() on devices > - if fails, give an warning and goes to the next (not good!) > - if fails on the VM state device, return zero (not good!) > - check if the requested snapshot exists on the device that saves the VM > state and the state is not zero > - if fails return -error Previously the qcow2 image was still reverted to the old state, so on the next start of the domain the qcow2 image would be in the state of the snapshot > New behavior: ... > - check if the requested snapshot exists on the device that saves the VM > state and the state is not zero > - if fails return -error ... > - run snapshot_goto() on devices Now the qcow2 image is not reverted and when the domain is started, it is NOT in the state of the snapshot. I can't decide if this regression is an Qemu bug or libvirt should be adapted to this new behavior. I found the Bug also reported with Ubuntu and created a Bug in our own German bugtracker: <https://bugs.launchpad.net/qemu/+bug/726619> <https://forge.univention.org/bugzilla/show_bug.cgi?id=22221> Sincerely Philipp Hahn -- 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 2

[libvirt] [RFC v5] Export KVM Host Power Management capabilities
by Srivatsa S. Bhat 09 Aug '11

09 Aug '11

This patch exports KVM Host Power Management capabilities as XML so that higher-level systems management software can make use of these features available in the host. The script "pm-is-supported" (from pm-utils package) is run to discover if Suspend-to-RAM (S3) or Suspend-to-Disk (S4) is supported by the host. If either of them are supported, then a new tag "<power_management>" is introduced in the XML under the <host> tag. Eg: When the host supports both S3 and S4, the XML looks like this: <capabilities> <host> <uuid>dc699581-48a2-11cb-b8a8-9a0265a79bbe</uuid> <cpu> <arch>i686</arch> <model>coreduo</model> <vendor>Intel</vendor> <topology sockets='1' cores='2' threads='1'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> </cpu> <power_management> <<<=== New host power management features <S3/> <S4/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> </host> . . . However in case the query to check for power management features succeeded, but the host does not support any such feature, then the XML will contain an empty <power_management/> tag. In the event that the PM query itself failed, the XML will not contain any "power_management" tag. Open issues: ----------- 1. Design new APIs in libvirt to exploit power management features such as S3/S4. This was discussed in [1] and [2]. Please let me know your comments and feedback. Changelog: --------- This version v5: Some redundant error messages were removed and the code was streamlined. v4: http://www.redhat.com/archives/libvir-list/2011-August/msg00316.html v3: http://www.redhat.com/archives/libvir-list/2011-August/msg00282.html v2: http://www.redhat.com/archives/libvir-list/2011-August/msg00238.html v1: http://thread.gmane.org/gmane.comp.emulators.libvirt/40886 References: ---------- [1] http://www.redhat.com/archives/libvir-list/2011-August/msg00248.html [2] http://www.redhat.com/archives/libvir-list/2011-August/msg00302.html Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat(a)linux.vnet.ibm.com> --- docs/formatcaps.html.in | 19 ++++++++++++---- docs/schemas/capability.rng | 18 +++++++++++++++ include/libvirt/virterror.h | 1 + libvirt.spec.in | 2 ++ src/conf/capabilities.c | 27 +++++++++++++++++++++- src/conf/capabilities.h | 4 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 7 ++++++ src/util/util.c | 51 ++++++++++++++++++++++++++++++++++++++++++ src/util/util.h | 14 ++++++++++++ src/util/virterror.c | 3 ++ 11 files changed, 141 insertions(+), 6 deletions(-) diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in index a4297ce..ce6f9a6 100644 --- a/docs/formatcaps.html.in +++ b/docs/formatcaps.html.in @@ -28,6 +28,10 @@ BIOS you will see <feature name='xtpr'/> ... </cpu> + <power_management> + <S3/> + <S4/> + <power_management/> </host>  @@ -61,11 +65,16 @@ BIOS you will see ... </capabilities></pre> The first block (in red) indicates the host hardware capabilities, currently -it is limited to the CPU properties but other information may be available, -it shows the CPU architecture, topology, model name, and additional features -which are not included in the model but the CPU provides them. Features of the -chip are shown within the feature block (the block is similar to what you will -find in a Xen fully virtualized domain description). +it is limited to the CPU properties and the power management features of +the host platform, but other information may be available, it shows the CPU architecture, +topology, model name, and additional features which are not included in the model but the +CPU provides them. Features of the chip are shown within the feature block (the block is +similar to what you will find in a Xen fully virtualized domain description). Further, +the power management features supported by the host are shown, such as Suspend-to-RAM (S3) +and Suspend-to-Disk (S4). In case the query for power management features succeeded but the +host does not support any such feature, then an empty <power_management/> +tag will be shown. Otherwise, if the query itself failed, no such tag will +be displayed (i.e., there will not be any power_management block or empty tag in the XML). The second block (in blue) indicates the paravirtualization support of the Xen support, you will see the os_type of xen to indicate a paravirtual kernel, then architecture information and potential features. diff --git a/docs/schemas/capability.rng b/docs/schemas/capability.rng index 99b4a9a..8238a37 100644 --- a/docs/schemas/capability.rng +++ b/docs/schemas/capability.rng @@ -35,6 +35,9 @@ </optional> </element> <optional> + <ref name='power_management'/> + </optional> + <optional> <ref name='migration'/> </optional> <optional> @@ -105,6 +108,21 @@ </zeroOrMore> </define> + <define name='power_management'> + <element name='power_management'> + <optional> + <element name='S3'> + <empty/> + </element> + </optional> + <optional> + <element name='S4'> + <empty/> + </element> + </optional> + </element> + </define> + <define name='migration'> <element name='migration_features'> <optional> diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index 9cac437..a831c73 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -82,6 +82,7 @@ typedef enum { VIR_FROM_EVENT = 40, /* Error from event loop impl */ VIR_FROM_LIBXL = 41, /* Error from libxenlight driver */ VIR_FROM_LOCKING = 42, /* Error from lock manager */ + VIR_FROM_CAPABILITIES = 43, /* Error from capabilities */ } virErrorDomain; diff --git a/libvirt.spec.in b/libvirt.spec.in index e2b7f65..3193de3 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -482,6 +482,8 @@ Requires: nc Requires: gettext # Needed by virt-pki-validate script. Requires: gnutls-utils +# Needed for probing the power management features of the host. +Requires: pm-utils %if %{with_sasl} Requires: cyrus-sasl # Not technically required, but makes 'out-of-box' config diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c index 2f243ae..84fba8a 100644 --- a/src/conf/capabilities.c +++ b/src/conf/capabilities.c @@ -29,6 +29,13 @@ #include "util.h" #include "uuid.h" #include "cpu_conf.h" +#include "virterror_internal.h" + + +#define VIR_FROM_THIS VIR_FROM_CAPABILITIES + +VIR_ENUM_IMPL(virHostPMCapability, VIR_HOST_PM_LAST, + "S3", "S4") /** * virCapabilitiesNew: @@ -201,7 +208,6 @@ virCapabilitiesAddHostFeature(virCapsPtr caps, return 0; } - /** * virCapabilitiesAddHostMigrateTransport: * @caps: capabilities to extend @@ -686,6 +692,25 @@ virCapabilitiesFormatXML(virCapsPtr caps) virBufferAddLit(&xml, " </cpu>\n"); + if (caps->host.powerMgmt_valid) { + /* The PM query was successful. */ + if (caps->host.powerMgmt) { + /* The host supports some PM features. */ + unsigned int pm = caps->host.powerMgmt; + virBufferAddLit(&xml, " <power_management>\n"); + while (pm) { + int bit = ffs(pm) - 1; + virBufferAsprintf(&xml, " <%s/>\n", + virHostPMCapabilityTypeToString(bit)); + pm &= ~(1U << bit); + } + virBufferAddLit(&xml, " </power_management>\n"); + } else { + /* The host does not support any PM feature. */ + virBufferAddLit(&xml, " <power_management/>\n"); + } + } + if (caps->host.offlineMigrate) { virBufferAddLit(&xml, " <migration_features>\n"); if (caps->host.liveMigrate) diff --git a/src/conf/capabilities.h b/src/conf/capabilities.h index e2fa1d6..c51f220 100644 --- a/src/conf/capabilities.h +++ b/src/conf/capabilities.h @@ -105,6 +105,10 @@ struct _virCapsHost { size_t nfeatures; size_t nfeatures_max; char **features; + bool powerMgmt_valid; + unsigned int powerMgmt; /* Bitmask of the PM capabilities. + * See enum virHostPMCapability. + */ int offlineMigrate; int liveMigrate; size_t nmigrateTrans; diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 830222b..40fc4d0 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1058,6 +1058,7 @@ virFormatMacAddr; virGenerateMacAddr; virGetGroupID; virGetHostname; +virGetPMCapabilities; virGetUserDirectory; virGetUserID; virGetUserName; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 3f36212..7e717ad 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -824,6 +824,13 @@ virCapsPtr qemuCapsInit(virCapsPtr old_caps) old_caps->host.cpu = NULL; } + /* Add the power management features of the host */ + + if (virGetPMCapabilities(&caps->host.powerMgmt) < 0) + VIR_WARN("Failed to get host power management capabilities"); + else + caps->host.powerMgmt_valid = true; /* The PM query succeeded. */ + virCapabilitiesAddHostMigrateTransport(caps, "tcp"); diff --git a/src/util/util.c b/src/util/util.c index 03a9e1a..1df4e5c 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -2641,3 +2641,54 @@ or other application using the libvirt API.\n\ return 0; } + +/** + * Get the Power Management Capabilities of the host system. + * The script 'pm-is-supported' (from the pm-utils package) is run + * to find out all the power management features supported by the host, + * such as Suspend-to-RAM (S3) and Suspend-to-Disk (S4). + * + * @bitmask: Pointer to the bitmask which will be set appropriately to + * indicate all the supported host power management features. + * + * Returns 0 if the query was successful, -1 upon failure. + */ +int +virGetPMCapabilities(unsigned int *bitmask) +{ + int ret = -1; + int status; + virCommandPtr cmd; + + *bitmask = 0; + + /* Check support for Suspend-to-RAM (S3) */ + cmd = virCommandNewArgList("pm-is-supported", "--suspend", NULL); + if (virCommandRun(cmd, &status) < 0) + goto cleanup; + + /* Check return code of command == 0 for success + * (i.e., the PM capability is supported) + */ + if (status == 0) + *bitmask |= 1U << VIR_HOST_PM_S3; + virCommandFree(cmd); + + /* Check support for Suspend-to-Disk (S4) */ + cmd = virCommandNewArgList("pm-is-supported", "--hibernate", NULL); + if (virCommandRun(cmd, &status) < 0) + goto cleanup; + + /* Check return code of command == 0 for success + * (i.e., the PM capability is supported) + */ + if (status == 0) + *bitmask |= 1U << VIR_HOST_PM_S4; + + ret = 0; + +cleanup: + virCommandFree(cmd); + return ret; +} + diff --git a/src/util/util.h b/src/util/util.h index af8b15d..24a87ff 100644 --- a/src/util/util.h +++ b/src/util/util.h @@ -272,4 +272,18 @@ bool virIsDevMapperDevice(const char *devname) ATTRIBUTE_NONNULL(1); int virEmitXMLWarning(int fd, const char *name, const char *cmd) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3); + +/* Power Management Capabilities of the host system */ + +enum virHostPMCapability { + VIR_HOST_PM_S3, /* Suspend-to-RAM */ + VIR_HOST_PM_S4, /* Suspend-to-Disk */ + + VIR_HOST_PM_LAST +}; + +VIR_ENUM_DECL(virHostPMCapability) + +int virGetPMCapabilities(unsigned int *); + #endif /* __VIR_UTIL_H__ */ diff --git a/src/util/virterror.c b/src/util/virterror.c index 9a27feb..e07de61 100644 --- a/src/util/virterror.c +++ b/src/util/virterror.c @@ -172,6 +172,9 @@ static const char *virErrorDomainName(virErrorDomain domain) { case VIR_FROM_LOCKING: dom = "Locking "; break; + case VIR_FROM_CAPABILITIES: + dom = "Capabilities "; + break; } return(dom); }

1 0

[libvirt] Documentation
by Rafael Fernández López 09 Aug '11

09 Aug '11

Hi all, Reading libvirt documentation I have found that there is an example that is pretty broken. I'm referring to http://libvirt.org/guide/html/Application_Development_Guide-Guest_Domains-L…, example 4.6. I attach a patch (untested) that fixes some logic, type and function signature problems. I kept small problems like 'i' missing definition for the sake of readiness. Best regards, Rafael Fernández López.

2 1

[libvirt] [PATCH] build: fix regression in large file support
by Eric Blake 09 Aug '11

09 Aug '11

https://bugzilla.redhat.com/show_bug.cgi?id=728772 points out that libvirt commit 1c93fbbb pulled in a gnulib regression that broke large file support. * .gnulib: Update to latest, for largefile fix. --- Pushing under the trivial rule. .gnulib | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/.gnulib b/.gnulib index 7f494c7..4470580 160000 --- a/.gnulib +++ b/.gnulib @@ -1 +1 @@ -Subproject commit 7f494c7d725db4a7f3abdef09d4070725487da67 +Subproject commit 4470580881a7b821b52fb5635102ef3e27aa5af4 -- 1.7.4.4

3 6