[libvirt] [PATCH] docs: describe new virtual switch configuration in network XML docs
by Laine Stump
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).
<span class="since">Since 0.3.0</span>
</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.
- <span class="since">Since 0.4.5</span>
+ 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). <span class="since">Since 0.4.5</span>
</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. <span class="since">Since 0.3.0; 'mode' attribute since
- 0.4.2</span></dd>
+ LAN.<span class="since">Since 0.3.0.</span>
+ 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.<span class="since">Since
+ 0.4.2</span>
+ </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.)<span class="since">Since
+ 0.4.2</span>
+ </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.<span class="since">Since 0.9.4</span>
+ </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).<span class="since">Since
+ 0.9.4</span>
+ </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).<span class="since">Since 0.9.4</span>
+ </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 <i>not</i> 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).<span class="since">Since 0.9.4</span>
+ </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 network<span class="since">Since 0.9.4</span>:
+ <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></b>
- <mac address='00:16:3E:5D:C7:9E'/>
...</pre>
<p>
@@ -134,13 +269,66 @@
<span class="since">Since 0.9.4</span>
</p>
+ <h5><a name="elementsPortgroup">Portgroups</a></h5>
+
+<pre>
+...
+ <forward mode='vepa'/>
+ <bridge name='br0'/>
+ <b><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>
+ </portgroup></b>
+ <b><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>
+ </portgroup></b>
+...</pre>
+
+ <p>
+ 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.
+ </p>
+
<h3><a name="elementsAddress">Addressing</a></h3>
<p>
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'.
</p>
<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>
+
+ <p>
+ 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).
+ </p>
+
+ <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>
+
+ <p>
+ 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.
+ </p>
+
+ <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
13 years, 4 months
[libvirt] Is there smt missing at Java bindings?
by kadir yüceer
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
13 years, 4 months
[libvirt] [PATCH 0/4] snapshot improvements
by Eric Blake
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
13 years, 4 months
[libvirt] [PATCH] qemu: Fix -chardev udp if parameters are omitted
by Cole Robinson
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
13 years, 4 months
[libvirt] [RFC v2] Export KVM Host Power Management capabilities
by Srivatsa S. Bhat
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__ */
13 years, 4 months
[libvirt] [BUG] Re: [2/6] loadvm: improve tests before bdrv_snapshot_goto()
by Philipp Hahn
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/
13 years, 4 months
[libvirt] [RFC v5] Export KVM Host Power Management capabilities
by Srivatsa S. Bhat
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</p>
<feature name='xtpr'/>
...
</cpu>
+ <power_management>
+ <S3/>
+ <S4/>
+ <power_management/>
</host></span>
<!-- xen-3.0-x86_64 -->
@@ -61,11 +65,16 @@ BIOS you will see</p>
...
</capabilities></pre>
<p>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).</p>
+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).</p>
<p>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.</p>
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);
}
13 years, 4 months
[libvirt] [PATCH] build: fix regression in large file support
by Eric Blake
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
13 years, 4 months
Re: [libvirt] [libvirt-users] virt-manager - how to add /dev/mapper as a storage pool
by Cole Robinson
On 08/09/2011 12:31 PM, Marc Haber wrote:
> On Tue, Aug 09, 2011 at 11:09:06AM -0400, Cole Robinson wrote:
>> On 08/08/2011 04:37 PM, Marc Haber wrote:
>>> I would like to be able to configure VMs running off dm-crypt devices
>>> that were unlocked in the host. Unlocked dm-crypt devices show up in
>>> /dev/mapper/devicename, with devicename being the second parameter
>>> given to cryptsetup luksOpen.
>>>
>>> The LVM storage pool type insists on searching in /dev/vgname and
>>> cannot be tricked into reading /dev/mapper by giving it a fake VG
>>> named mapper; the LVM storage pool type "dir" mishandles
>>> /dev/mapper/control ("illegal seek").
>>>
>>> Is there a workaround to be able to use such devices in virt-manager
>>> without having to define a single storage pool for every device used?
>>
>> cc-ing virt-tool-list
>
> Bcc, or forgotten?
>
>> Latest virt-manager-0.9.0 allows adding a libvirt mpath pool which might
>> be what you're looking for. If you don't have that version you can try
>> configuring it on the command line with virsh.
>
> I have that version, but an mpath pool set to /dev/mapper stays empty.
> Googling and reading the available docs suggests that this feature
> only looks for /dev/mapper/mpath*
>
Forgotten, sorry.
Not really sure then, maybe this is something that libvirt should be
extended to handle. CCing libvirt devel list
- Cole
13 years, 4 months
