[libvirt] [PATCH 1/1] Add note about numeric domain names to manpage
by Dave Allan
Clarify that domains with numeric names can only be identified by
their domain id.
---
tools/virsh.pod | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 2120429..e30f1b6 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -26,12 +26,16 @@ The basic structure of most virsh usage is:
virsh [OPTION]... <command> <domain> [ARG]...
-Where I<command> is one of the commands listed below, I<domain> is the numeric
-domain id, or the domain name, or the domain UUID and I<ARGS> are command
-specific options. There are a few exceptions to this rule in the cases where
-the command in question acts on all domains, the entire machine, or directly
-on the xen hypervisor. Those exceptions will be clear for each of those
-commands.
+Where I<command> is one of the commands listed below, I<domain> is the
+numeric domain id, or the domain name, or the domain UUID and I<ARGS>
+are command specific options. There are a few exceptions to this rule
+in the cases where the command in question acts on all domains, the
+entire machine, or directly on the xen hypervisor. Those exceptions
+will be clear for each of those commands. Note: it is permissible to
+give numeric names to domains, however, doing so will result in a
+domain that can only be identified by domain id. In other words, if a
+numeric value is supplied it will be interpreted as a domain id, not
+as a name.
The B<virsh> program can be used either to run one I<COMMAND> by giving the
command and its arguments on the shell command line, or a I<COMMAND_STRING>
--
1.7.11.4
12 years, 6 months
- 2
- 1
[libvirt] [PATCH 0/3] Transport network port data during live migration
by Kyle Mestery
This series of commits has the end goal of allowing per-port data stored
in the Open vSwitch DB to be transported during live migration. This is
done by first providing a generic infrastructure for transporting network
data, adding some utility functions specific to Open vSwitch, and hooking
the two together.
The framework provided is generic in that other networking data could be
transferred as well by simply adding in additional hooks as needed.
An example of the XML being transported is shown here:
<network>
<interface index='1' vporttype='openvswitch' netdata='blah blah blah'/>
<interface index='7' vporttype='openvswitch' netdata='blah blah blah'/>
</network>
----
- V3 of this patch series fixes issues found by Laine during review around
making the XML more generic.
- V2 of this patch series fixes some issues found when migrating VMs on
standard Linux bridges.
Kyle Mestery (3):
Add the ability for the Qemu V3 migration protocol to include
transporting network configuration. A generic framework is proposed
with this patch to allow for the transfer of opaque data.
Add utility functions for Open vSwitch to both save per-port data
before a live migration, and restore the per-port data after a
live migration.
Transport Open vSwitch per-port data during live migration by
using the utility functions
virNetDevOpenvswitchGetMigrateData() and
virNetDevOpenvswitchSetMigrateData().
src/libvirt_private.syms | 2 +
src/qemu/qemu_migration.c | 293 +++++++++++++++++++++++++++++++++++++++-
src/util/virnetdevopenvswitch.c | 70 ++++++++++
src/util/virnetdevopenvswitch.h | 6 +
4 files changed, 369 insertions(+), 2 deletions(-)
--
1.7.11.4
12 years, 6 months
- 5
- 15