https://bugzilla.redhat.com/show_bug.cgi?id=1373783
Signed-off-by: Jiri Denemark
---
tools/virsh.pod | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 01453be600..a03f64a262 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -1767,7 +1767,13 @@ periodically increased by I.
I<--rdma-pin-all> can be used with RDMA migration (i.e., when I
starts with rdma://) to tell the hypervisor to pin all domain's memory at once
-before migration starts rather than letting it pin memory pages as needed.
+before migration starts rather than letting it pin memory pages as needed. For
+QEMU/KVM this requires hard_limit memory tuning element (in the domain XML) to
+be used and set to the maximum memory configured for the domain plus any memory
+consumed by the QEMU process itself. Beware of setting the memory limit too
+high (and thus allowing the domain to lock most of the host's memory). Doing so
+may be dangerous to both the domain and the host itself since the host's kernel
+may run out of memory.
B: Individual hypervisors usually do not support all possible types of
migration. For example, QEMU does not support direct migration.
--
2.14.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
When destroying a domain libvirt marks it internally with a
beingDestroyed flag to make sure the qemuDomainDestroyFlags API itself
cleans up after the domain rather than letting an uninformed EOF handler
do it. However, when the domain is being started at the moment libvirt
was asked to destroy it, only the starting thread can properly clean up
after the domain and thus it ignores the beingDestroyed flag. Once
qemuDomainDestroyFlags finally gets a job, the domain may not be running
anymore, which should not be reported as an error if the domain has been
starting up.
https://bugzilla.redhat.com/show_bug.cgi?id=1445600
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_driver.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 6255d89310..a25daae866 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -2224,6 +2224,9 @@ qemuDomainDestroyFlags(virDomainPtr dom,
virObjectEventPtr event = NULL;
qemuDomainObjPrivatePtr priv;
unsigned int stopFlags = 0;
+int state;
+int reason;
+bool starting;
virCheckFlags(VIR_DOMAIN_DESTROY_GRACEFUL, -1);
@@ -2235,13 +2238,29 @@ qemuDomainDestroyFlags(virDomainPtr dom,
if (virDomainDestroyFlagsEnsureACL(dom->conn, vm->def) < 0)
goto cleanup;
+if (!virDomainObjIsActive(vm)) {
+virReportError(VIR_ERR_OPERATION_INVALID,
+ "%s", _("domain is not running"));
+goto cleanup;
+}
+
+state = virDomainObjGetState(vm, &reason);
+starting = (state == VIR_DOMAIN_PAUSED &&
+reason == VIR_DOMAIN_PAUSED_STARTING_UP &&
+!priv->beingDestroyed);
+
if (qemuProcessBeginStopJob(driver, vm, QEMU_JOB_DESTROY,
!(flags & VIR_DOMAIN_DESTROY_GRACEFUL)) < 0)
goto cleanup;
if (!virDomainObjIsActive(vm)) {
-virReportError(VIR_ERR_OPERATION_INVALID,
- "%s", _("domain is not running"));
+if (starting) {
+VIR_DEBUG("Domain %s is not running anymore", vm->def->name);
+ret = 0;
+} else {
+virReportError(VIR_ERR_OPERATION_INVALID,
+ "%s", _("domain is not running"));
+}
goto endjob;
}
--
2.14.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 09/08/2017 10:51 AM, Daniel P. Berrange wrote:
On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
So I could see a flow like the following:
The flow looks good
1. mgmt tool calls virConnectGetCapabilities. This returns an XML
document that includes the following
...other bits...
...hex encoded PDH key...
2. mgmt tool requests to start a guest calling virCreateXML(),
passing VIR_DOMAIN_START_PAUSED. The XML would include
...hex encode DH key...
..hex encode info...
...int32 value..
if is provided and VIR_DOMAIN_START_PAUSED is missing,
libvirt would report an error and refuse to start the guest
One thing which is not clear to me is, how do we know that we are asked
to launch SEV guest? Are you thinking that tag in the XML will
hint libvirt that GO has asked to launch a SEV guest?
Yes, the existance of the tag is the indicator that informs
libvirt that SEV *must* be used for the guest.
Thanks for confirming.
3. Libvirt generates the QEMU cli arg to enable SEV using
the XML data and starts QEMU, leaving CPUs paused
I am looking at [1] to get the feel for how do we model it in the XML.
As you can see I am using ad-hoc to create the sev-guest
object. Currently, sev-guest object accepts the following properties:
dh-cert-file:
session-info-file:
policy:
I believe the new XML model will influence the property input type,
Any recommendation on how do model this part ? thank you so much.
That looks ok to me - even if QEMU wants the data provided in
files on disk, libvirt can just create the files on the fly
from the data it has in the element in the XML file.
Since they're only needed during startup, libvirt can then
easily delete the files the moment QEMU has completed its
startup.
Perfect! works well with me.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 09/08/17 17:51, Daniel P. Berrange wrote:
> On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
>> I am looking at [1] to get the feel for how do we model it in the XML.
>> As you can see I am using ad-hoc to create the sev-guest
>> object. Currently, sev-guest object accepts the following properties:
>>
>> dh-cert-file:
>> session-info-file:
>> policy:
>>
>> I believe the new XML model will influence the property input type,
>> Any recommendation on how do model this part ? thank you so much.
>
> That looks ok to me - even if QEMU wants the data provided in
> files on disk, libvirt can just create the files on the fly
> from the data it has in the element in the XML file.
> Since they're only needed during startup, libvirt can then
> easily delete the files the moment QEMU has completed its
> startup.
/dev/fd/N filenames could be used for poor man's fd passing, I think.
(/dev/fd is a symlink to the /proc/self/fd directory)
proc(5) has documentation on this.
Thanks,
Laszlo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi Daniel,
On 09/08/2017 09:52 AM, Daniel P. Berrange wrote:
On Fri, Sep 08, 2017 at 01:45:06PM +, Relph, Richard wrote:
A few answers in line…
On 9/8/17, 8:16 AM, "Daniel P. Berrange" wrote:
On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> Hi All,
>
> (sorry for the long message)
>
> CPUs from AMD EPYC family supports Secure Encrypted Virtualization (SEV)
> feature - the feature allows running encrypted VMs. To enable the
feature,
> I have been submitting patches to Linux kernel [1], Qemu [2] and OVMF
[3].
> We have been making some good progress in getting patches accepted
upstream
> in Linux and OVMF trees. SEV builds upon SME (Secure Memory Encryption)
> feature -- SME support just got pulled into 4.14 merge window. The base
> SEV patches are accepted in OVMF tree -- now we have SEV aware guest
BIOS.
> I am getting ready to take off "RFC" tag from remaining patches to get
them
> reviewed and accepted.
>
> The boot flow for launching an SEV guest is a bit different from a
typical
> guest launch. In order to launch SEV guest from virt-manager or other
> high-level VM management tools, we need to design and implement new
> interface between libvirt and qemu, and probably add new APIs in libvirt
> to be used by VM management tools. I am new to the libvirt and need some
> expert advice while designing this interface. A pictorial representation
> for a SEV guest launch flow is available in SEV Spec Appendix A [4].
>
> A typical flow looks like this:
>
> 1. Guest owner (GO) asks the cloud provider to launch SEV guest.
> 2. VM tool asks libvirt to provide its Platform Diffie-Hellman (PDH) key.
> 3. libvirt opens /dev/sev device to get its PDH and return the blob to
the
>caller.
What sort of size are we talking about for the PDH ?
The PDH blob is described in reference 4. It’s 0x824 bytes long… a bit over 2K
bytes.
PDH is “Platform Diffie-Hellman” key, public portion.
There's a few ways libvirt could report it
1. As an XML element in the host capabilities XML
2. As an XML element in the emulator capabilities XML
3. Via a newly added host API
> 4. VM tool gives its PDH to GO.
> 5. GO provides its DH key, session-info and guest policy.
Are steps 4 & 5 strictly required to be in this order, or is it
possible
Steps 4 and 5 must occur in that order. The data sent by the GO in the
“session info” is encrypted and integrity protected with keys that the
GO derives from the GO private Diffie-Hellman key and the PDH public
Diffie-Hellman key.
What are the security requirements around the DH key, session info
and guest policy ? Are any of them sensitive data which needs to be
kept private from untrustworthy users. Also are all three of these
items different for every guest launched, or are some of them
likely to be the same for every guest ?
The PDH is not sensitive. It is relatively static for the platform.
(It only changes when the platform owner chooses to change the apparent
identity of the platform that will actually run the virtual machine.)
The 128-byte session info data is encrypted and integrity protected by
the GO. It need not be additionally encrypted or integrity protected.
It should vary for EVERY guest launch.
The 4-byte guest policy must be sent in the clear as some components
may want to observe the policy bits. It may change from guest to guest,
but there will likely only be a few common values.
Given this, and the pretty small data sizes, I think this info could
in fact all be provided inline in the XML config - either hex or base64
encoded for the binary blobs.
> 8. libvirt launches the guest with "-S"
All libvirt guests get launched with -S, to give libvirt chance to do some
setup before starting vCPUs. Normally vCPUs are started by default, but
the VIR_DOMAIN_START_PAUSED flag allows the mgmt app to tell libvirt to
leave vCPUS paused.
Alternatively, if libvirt sees presencese of 'sev' config for the guest,
it could automatically leave it in PAUSED state regardless of the
VIR_DOMAIN_START_PAUSED flag.
While using the LAUNCH_MEASURE and LAUNCH_SECRET operations is expected
to be the common case, they are optional. I would recommend requiring
the upstream software to explicitly set the VIR_DOMAIN_START_PAUSED flag,
if only to minimize the dependencies…
Ok.
> 9. While creating the SEV guest qemu does the following
> i) create encryption context using GO's DH, session-info and guest
policy
> (LAUNCH_START)
> ii) encrypts the guest bios (LAUNCH_UPDATE_DATA)
> iii) calls LAUNCH_MEASUREMENT to get the encrypted bios measurement
> 10. By some interface we must propagate the measurement all the way to GO
> b
On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
> > So I could see a flow like the following:
>
>
> The flow looks good
>
> >
> >
> >1. mgmt tool calls virConnectGetCapabilities. This returns an XML
> > document that includes the following
> >
> >
> > ...other bits...
> >
> > ...hex encoded PDH key...
> >
> >
> >
> >2. mgmt tool requests to start a guest calling virCreateXML(),
> > passing VIR_DOMAIN_START_PAUSED. The XML would include
> >
> >
> > ...hex encode DH key...
> > ..hex encode info...
> > ...int32 value..
> >
> >
> >
> > if is provided and VIR_DOMAIN_START_PAUSED is missing,
> > libvirt would report an error and refuse to start the guest
> >
>
>
> One thing which is not clear to me is, how do we know that we are asked
> to launch SEV guest? Are you thinking that tag in the XML will
> hint libvirt that GO has asked to launch a SEV guest?
Yes, the existance of the tag is the indicator that informs
libvirt that SEV *must* be used for the guest.
> >3. Libvirt generates the QEMU cli arg to enable SEV using
> > the XML data and starts QEMU, leaving CPUs paused
> >
>
>
> I am looking at [1] to get the feel for how do we model it in the XML.
> As you can see I am using ad-hoc to create the sev-guest
> object. Currently, sev-guest object accepts the following properties:
>
> dh-cert-file:
> session-info-file:
> policy:
>
> I believe the new XML model will influence the property input type,
> Any recommendation on how do model this part ? thank you so much.
That looks ok to me - even if QEMU wants the data provided in
files on disk, libvirt can just create the files on the fly
from the data it has in the element in the XML file.
Since they're only needed during startup, libvirt can then
easily delete the files the moment QEMU has completed its
startup.
>
> [1] https://libvirt.org/formatdomain.html#elementsCPU
>
>
> >4. QEMU emits a SEV_MEASURE event containing the measurement
> > blob
> >
> >5. Libvirt catches the QEMU event and emits its own
> > VIR_CONNECT_DOMAIN_EVENT_SEV_MEASURE event containing
> > the measurement blob
> >
> >6. GO does its validation of the measurement
> >
> >7a If validation failed, then virDomainDestroy() to stop QEMU
> >
> >7b If validation succeeed
> >
> > Optionally call
> >
> > virDomainSetSEVSecret()
> >
> > providing the optional secret, then
> >
> > virDomainResume()
> >
> > to let QEMU continue
> >
> >
> >
> >
> > Regards,
> > Daniel
> >
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
From: Wim ten Have
This patch extends guest domain administration adding support to advertise
node sibling distances when configuring HVM numa guests.
NUMA (non-uniform memory access), a method of configuring a cluster of nodes
within a single multiprocessing system such that it shares processor
local memory amongst others improving performance and the ability of the
system to be expanded.
A NUMA system could be illustrated as shown below. Within this 4-node
system, every socket is equipped with its own distinct memory. The whole
typically resembles a SMP (symmetric multiprocessing) system being a
"tightly-coupled," "share everything" system in which multiple processors
are working under a single operating system and can access each others'
memory over multiple "Bus Interconnect" paths.
+-+-+-+ +-+-+-+
| M | CPU | CPU | | CPU | CPU | M |
| E | | | | | | E |
| M +- Socket0 -+ +- Socket3 -+ M |
| O | | | | | | O |
| R | CPU | CPU <-> CPU | CPU | R |
| Y | | | | | | Y |
+-+--^--+-+ +-+--^--+-+
| |
| Bus Interconnect |
| |
+-+--v--+-+ +-+--v--+-+
| M | | | | | | M |
| E | CPU | CPU <-> CPU | CPU | E |
| M | | | | | | M |
| O +- Socket1 -+ +- Socket2 -+ O |
| R | | | | | | R |
| Y | CPU | CPU | | CPU | CPU | Y |
+-+-+-+ +-+-+-+
In contrast there is the limitation of a flat SMP system (not illustrated)
under which the bus (data and address path) can easily become a performance
bottleneck under high activity as sockets are added.
NUMA adds an intermediate level of memory shared amongst a few cores per
socket as illustrated above, so that data accesses do not have to travel
over a single bus.
Unfortunately the way NUMA does this adds its own limitations. This,
as visualized in the illustration above, happens when data is stored in
memory associated with Socket2 and is accessed by a CPU (core) in Socket0.
The processors use the "Bus Interconnect" to create gateways between the
sockets (nodes) enabling inter-socket access to memory. These "Bus
Interconnect" hops add data access delays when a CPU (core) accesses
memory associated with a remote socket (node).
For terminology we refer to sockets as "nodes" where access to each
others' distinct resources such as memory make them "siblings" with a
designated "distance" between them. A specific design is described under
the ACPI (Advanced Configuration and Power Interface Specification)
within the chapter explaining the system's SLIT (System Locality Distance
Information Table).
These patches extend core libvirt's XML description of a virtual machine's
hardware to include NUMA distance information for sibling nodes, which
is then passed to Xen guests via libxl. Recently qemu landed support for
constructing the SLIT since commit 0f203430dd ("numa: Allow setting NUMA
distance for different NUMA nodes"), hence these core libvirt extensions
can also help other drivers in supporting this feature.
The XML changes made allow to describe the node/sockets
amongst node identifiers and propagate these towards the numa
domain functionality finally adding support to libxl.
[below is an example illustrating a 4 node/socket setup]
By default on libxl, if no are given to describe the distance data
between different s, this patch will default to a scheme using 10
for local and 20 for any remote node/socket, which is the assumption of
guest OS when no SLIT is specified. While SLIT is optional, libxl requires
that distances are set nonetheless.
On Linux systems the SLIT detail can be listed with help of the 'numactl -H'
command. The above HVM guest would show the following output.
[root@f25 ~]# numactl -H
available: 4 nodes (0-3)
node 0 cpus: 0 4 5 6 7
node 0 size: 1988 MB
node 0 free: 1743 MB
node 1 cpus: 1 8 9 10 12 13 14 15
node 1 size: 1946 MB
node 1 free: 1885 MB
node 2 cpus: 2 11
node 2 size: 2011 MB
node 2 free: 1912 MB
node 3 cpus: 3
node 3 size: 2010 MB
node 3 free: 1980 MB
node distances:
node 0 1 2 3
0: 10 21 31 4
From: Wim ten Have
Add libvirtd NUMA cell domain administration functionality to
describe underlying cell id sibling distances in full fashion
when configuring HVM guests.
Schema updates are made to docs/schemas/cputypes.rng enforcing domain
administration to follow the syntax below the numa cell id and
docs/schemas/basictypes.rng to add "numaDistanceValue".
A minimum value of 10 representing the LOCAL_DISTANCE as 0-9 are
reserved values and can not be used as System Locality Distance Information.
A value of 20 represents the default setting of REMOTE_DISTANCE
where a maximum value of 255 represents UNREACHABLE.
Effectively any cell sibling can be assigned a distance value where
practically 'LOCAL_DISTANCE <= value <= UNREACHABLE'.
[below is an example of a 4 node setup]
Whenever a sibling id the cell LOCAL_DISTANCE does apply and for any
sibling id not being covered a default of REMOTE_DISTANCE is used
for internal computations.
Signed-off-by: Wim ten Have
---
Changes on v1:
- Add changes to docs/formatdomain.html.in describing schema update.
Changes on v2:
- Automatically apply distance symmetry maintaining cell <-> sibling.
- Check for maximum '255' on numaDistanceValue.
- Automatically complete empty distance ranges.
- Check that sibling_id's are in range with cell identifiers.
- Allow non-contiguous ranges, starting from any node id.
- Respect parameters as ATTRIBUTE_NONNULL fix functions and callers.
- Add and apply topology for LOCAL_DISTANCE=10 and REMOTE_DISTANCE=20.
Changes on v3
- Add UNREACHABLE if one locality is unreachable from another.
- Add code cleanup aligning function naming in a separated patch.
- Add numa related driver code in a separated patch.
- Remove from numaDistanceValue schema/basictypes.rng
- Correct doc changes.
---
docs/formatdomain.html.in | 63 +-
docs/schemas/basictypes.rng | 7 ++
docs/schemas/cputypes.rng | 18
src/conf/numa_conf.c| 200 +++-
4 files changed, 284 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 8ca7637..c453d44 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1529,7 +1529,68 @@
- This guest NUMA specification is currently available only for QEMU/KVM.
+ This guest NUMA specification is currently available only for
+ QEMU/KVM and Xen. Whereas Xen driver also allows for a distinct
+ description of NUMA arranged sibling cell
+ distances Since 3.6.0.
+
+
+
+ Under NUMA h/w architecture, distinct resources such as memory
+ create a designated distance between cell and
+ siblings that now can be described with the help of
+ distances. A detailed description can be found within
+ the ACPI (Advanced Configuration and Power Interface Specification)
+ within the chapter explaining the system's SLIT (System Locality
+ Distance Information Table).
+
+
+
+...
+
+ ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ...
+
+...
+
+
+ Under Xen driver, if no distances are given to describe
+ the SLIT data between different cells, it will default to a scheme
+ using 10 for local and 20 for remote distances.
Events configuration
diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng
index 1ea667c..1a18cd3 100644
--- a/docs/schemas/basictypes.rng
+++ b/docs/schemas/basictypes.rng
@@ -77,6 +77,13 @@
+
+
+ 10
+ 255
+
+
+
diff --git a/docs/schemas/cputypes.rng b
On Fri, Sep 08, 2017 at 01:45:06PM +, Relph, Richard wrote:
> A few answers in line…
>
> On 9/8/17, 8:16 AM, "Daniel P. Berrange" wrote:
>
> On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> > Hi All,
> >
> > (sorry for the long message)
> >
> > CPUs from AMD EPYC family supports Secure Encrypted Virtualization (SEV)
> > feature - the feature allows running encrypted VMs. To enable the
> feature,
> > I have been submitting patches to Linux kernel [1], Qemu [2] and OVMF
> [3].
> > We have been making some good progress in getting patches accepted
> upstream
> > in Linux and OVMF trees. SEV builds upon SME (Secure Memory Encryption)
> > feature -- SME support just got pulled into 4.14 merge window. The base
> > SEV patches are accepted in OVMF tree -- now we have SEV aware guest
> BIOS.
> > I am getting ready to take off "RFC" tag from remaining patches to get
> them
> > reviewed and accepted.
> >
> > The boot flow for launching an SEV guest is a bit different from a
> typical
> > guest launch. In order to launch SEV guest from virt-manager or other
> > high-level VM management tools, we need to design and implement new
> > interface between libvirt and qemu, and probably add new APIs in libvirt
> > to be used by VM management tools. I am new to the libvirt and need some
> > expert advice while designing this interface. A pictorial representation
> > for a SEV guest launch flow is available in SEV Spec Appendix A [4].
> >
> > A typical flow looks like this:
> >
> > 1. Guest owner (GO) asks the cloud provider to launch SEV guest.
> > 2. VM tool asks libvirt to provide its Platform Diffie-Hellman (PDH)
> key.
> > 3. libvirt opens /dev/sev device to get its PDH and return the blob to
> the
> >caller.
>
> What sort of size are we talking about for the PDH ?
>
> The PDH blob is described in reference 4. It’s 0x824 bytes long… a bit over
> 2K bytes.
> PDH is “Platform Diffie-Hellman” key, public portion.
>
> There's a few ways libvirt could report it
>
> 1. As an XML element in the host capabilities XML
> 2. As an XML element in the emulator capabilities XML
> 3. Via a newly added host API
>
> > 4. VM tool gives its PDH to GO.
> > 5. GO provides its DH key, session-info and guest policy.
>
> Are steps 4 & 5 strictly required to be in this order, or is it
> possible
>
> Steps 4 and 5 must occur in that order. The data sent by the GO in the
> “session info” is encrypted and integrity protected with keys that the
> GO derives from the GO private Diffie-Hellman key and the PDH public
> Diffie-Hellman key.
>
> What are the security requirements around the DH key, session info
> and guest policy ? Are any of them sensitive data which needs to be
> kept private from untrustworthy users. Also are all three of these
> items different for every guest launched, or are some of them
> likely to be the same for every guest ?
>
> The PDH is not sensitive. It is relatively static for the platform.
> (It only changes when the platform owner chooses to change the apparent
> identity of the platform that will actually run the virtual machine.)
> The 128-byte session info data is encrypted and integrity protected by
> the GO. It need not be additionally encrypted or integrity protected.
> It should vary for EVERY guest launch.
> The 4-byte guest policy must be sent in the clear as some components
> may want to observe the policy bits. It may change from guest to guest,
> but there will likely only be a few common values.
Given this, and the pretty small data sizes, I think this info could
in fact all be provided inline in the XML config - either hex or base64
encoded for the binary blobs.
> > 8. libvirt launches the guest with "-S"
>
> All libvirt guests get launched with -S, to give libvirt chance to do some
> setup before starting vCPUs. Normally vCPUs are started by default, but
> the VIR_DOMAIN_START_PAUSED flag allows the mgmt app to tell libvirt to
> leave vCPUS paused.
>
> Alternatively, if libvirt sees presencese of 'sev' config for the guest,
> it could automatically leave it in PAUSED state regardless of the
> VIR_DOMAIN_START_PAUSED flag.
>
> While using the LAUNCH_MEASURE and LAUNCH_SECRET operations is expected
> to be the common case, they are optional. I would recommend requiring
> the upstream software to explicitly set the VIR_DOMAIN_START_PAUSED flag,
> if only to minimize the dependencies…
Ok.
> > 9. While creating the SEV guest qemu does the following
> > i) create encryption context using GO's DH, session-info and guest
> policy
> > (LAUNCH_START)
> > ii) encrypts the guest bios (LAUNCH_UPDATE_DATA)
> > iii) calls LAUNCH_MEASUREMENT to get the encrypted bios measurement
> > 10. By some inte
On Mon, 4 Sep 2017 08:49:33 +0200
Martin Kletzander wrote:
> On Fri, Sep 01, 2017 at 04:31:50PM +0200, Wim ten Have wrote:
> >On Thu, 31 Aug 2017 16:36:58 +0200
> >Martin Kletzander wrote:
> >
> >> On Thu, Aug 31, 2017 at 04:02:38PM +0200, Wim Ten Have wrote:
> >> >From: Wim ten Have
> >> >
> >
> >> I haven't seen the previous versions, so sorry if I point out something
> >> that got changed already.
> >
> >There was a v1 and v2 cycle by Jim and Daniel 2 month back.
> >Due to personal issues whole got delayed at my end where i am
> >catching up.
> >
> >> >Add libvirtd NUMA cell domain administration functionality to
> >> >describe underlying cell id sibling distances in full fashion
> >> >when configuring HVM guests.
> >> >
> >> >[below is an example of a 4 node setup]
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >> Are all those required? I don't see the point in requiring duplicate
> >> values.
> >
> >Sorry I am not sure I understand what you mean by "duplicate values"
> >here. Can you elaborate?
> >
>
> Sure. For simplicity let's assume 2 cells:
>
>
>
>
>
>
>
>
>
>
>
>
>
The fields are not a necessity. And to reduce even more we could also
remove LOCAL_DISTANCES as they make a constant factor where;
(cell_id == sibling_id)
So, although the presentation of a guest domain may heavily,
giving this a look it seems far from attractive to me. I am not sure
if this is what we want and should do.
Let me go forward sending out "PATCH v4" addressing other comments and
reserve this idea for "PATCH v5".
Regards,
- Wim.
> >> >Changes under this commit concern all those that require adding
> >> >the valid data structures, virDomainNuma* functional routines and the
> >> >XML doc schema enhancements to enforce appropriate administration.
> >>
> >> I don't understand the point of this paragraph.
> >
> >Let me rephrase this paragraph in future version.
> >
> >> >These changes are accompanied with topic related documentation under
> >> >docs/formatdomain.html within the "CPU model and topology" extending the
> >> >"Guest NUMA topology" paragraph.
> >>
> >> This can be seen from the patch.
> >
> >Agree, so I'll address this in future version too.
> >
> >> >For terminology we refer to sockets as "nodes" where access to each
> >> >others' distinct resources such as memory make them "siblings" with a
> >> >designated "distance" between them. A specific design is described under
> >> >the ACPI (Advanced Configuration and Power Interface Specification)
> >> >within the chapter explaining the system's SLIT (System Locality Distance
> >> >Information Table).
> >>
> >> The above paragraph is also being added in the docs.
> >
> >True so I'll scratch this part of the commit message.
> >
> >> >These patches extend core libvirt's XML description of a virtual machine's
> >> >hardware to include NUMA distance information for sibling nodes, which
> >> >is then passed to Xen guests via libxl. Recently qemu landed support for
> >> >constructing the SLIT since commit 0f203430dd ("numa: Allow setting NUMA
> >> >distance for different NUMA nodes"), hence these core libvirt extensions
> >> >can also help other drivers in supporting this feature.
> >>
> >> This is not true, libxl changes are in separate patch.
> >
> >Like the previous comments and replies, I'll rearrange the commit
> >messages and rephrase them to be more specific to the patch.
> >
> >> There's a lot of copy-paste from the cover-letter...
> >
> >There is indeed room for improvement.
> >
> >> >These changes alter the docs/schemas/cputypes.rng enforcing
> >> >domain administration to follow the syntax below per numa cell id.
> >> >
> >> >These changes also alter docs/schemas/basictypes.rng to add
> >> >"numaDistanceValue" which is an "unsignedInt" with a minimum value
> >> >of 10 as 0-9 are reserved values and can not be used as System
> >> >Locality Distance Information Table data.
> >> >
> >> >Signed-off-by: Wim ten Have
> >> >---
> >> >Changes on v1:
> >> >- Add changes to docs/formatdomain.html.in describing schema update.
> >> >Changes on v2:
> >> >- Automatically apply distance symmetry maintaining cell <-> sibling.
> >> >- Check for maximum '255' on numaDistanceValue.
> >> >- Automatically complete empty distance ranges.
> >> >- Check that sibling_id's are in range with cell identifiers.
> >> >- Allow non-contiguous ranges, starting from any node id.
> >> >- Respect parameters as ATTR
A few answers in line…
On 9/8/17, 8:16 AM, "Daniel P. Berrange" wrote:
On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> Hi All,
>
> (sorry for the long message)
>
> CPUs from AMD EPYC family supports Secure Encrypted Virtualization (SEV)
> feature - the feature allows running encrypted VMs. To enable the feature,
> I have been submitting patches to Linux kernel [1], Qemu [2] and OVMF [3].
> We have been making some good progress in getting patches accepted
upstream
> in Linux and OVMF trees. SEV builds upon SME (Secure Memory Encryption)
> feature -- SME support just got pulled into 4.14 merge window. The base
> SEV patches are accepted in OVMF tree -- now we have SEV aware guest BIOS.
> I am getting ready to take off "RFC" tag from remaining patches to get
them
> reviewed and accepted.
>
> The boot flow for launching an SEV guest is a bit different from a typical
> guest launch. In order to launch SEV guest from virt-manager or other
> high-level VM management tools, we need to design and implement new
> interface between libvirt and qemu, and probably add new APIs in libvirt
> to be used by VM management tools. I am new to the libvirt and need some
> expert advice while designing this interface. A pictorial representation
> for a SEV guest launch flow is available in SEV Spec Appendix A [4].
>
> A typical flow looks like this:
>
> 1. Guest owner (GO) asks the cloud provider to launch SEV guest.
> 2. VM tool asks libvirt to provide its Platform Diffie-Hellman (PDH) key.
> 3. libvirt opens /dev/sev device to get its PDH and return the blob to the
>caller.
What sort of size are we talking about for the PDH ?
The PDH blob is described in reference 4. It’s 0x824 bytes long… a bit over 2K
bytes.
PDH is “Platform Diffie-Hellman” key, public portion.
There's a few ways libvirt could report it
1. As an XML element in the host capabilities XML
2. As an XML element in the emulator capabilities XML
3. Via a newly added host API
> 4. VM tool gives its PDH to GO.
> 5. GO provides its DH key, session-info and guest policy.
Are steps 4 & 5 strictly required to be in this order, or is it
possible
Steps 4 and 5 must occur in that order. The data sent by the GO in the “session
info” is encrypted and integrity protected with keys that the GO derives from
the GO private Diffie-Hellman key and the PDH public Diffie-Hellman key.
What are the security requirements around the DH key, session info
and guest policy ? Are any of them sensitive data which needs to be
kept private from untrustworthy users. Also are all three of these
items different for every guest launched, or are some of them
likely to be the same for every guest ?
The PDH is not sensitive. It is relatively static for the platform. (It only
changes when the platform owner chooses to change the apparent identity of the
platform that will actually run the virtual machine.)
The 128-byte session info data is encrypted and integrity protected by the GO.
It need not be additionally encrypted or integrity protected. It should vary
for EVERY guest launch.
The 4-byte guest policy must be sent in the clear as some components may want
to observe the policy bits. It may change from guest to guest, but there will
likely only be a few common values.
eg, would the same guest policy blob be used for every guest, with
only session info changing ?
Also what sort of size are we talking about for each of these
data items, KBs, 10's of KB, 100's of KBs or larger ?
The security and data size can influence our design approach from
the libvirt POV.
> 6. VM tool somehow communicates the GO provided information to libvirt.
Essentially we have two choices
1. inline in the guest XML config description passed to libvirt
when defining the guest XML
2. out of band, ahead of time, via some other API prior to defining
the guest XML, which is then referenced in guest XML. THis could
be done using the virSecret APIs, where we create 3 secrets, one
each for DH key, session-info and guets policy. The UUID of the
secret could be specified in the guest XML. This has flexibility
of allowing the same secrets ot be used for many guests (if this
is valid for SEV)
> 7. libvirt adds "sev-guest" object in its xml file with all the
information
>obtained from #5
>
>(currently my xml file looks like this)
>
>
>
value='sev-guest,id=sev0,policy=,dh-key-file=,session-file=/>
>
>
>
> 8. libvirt launches the guest with "-S"
All libvirt guests get launched with -S, to give libvirt chance to do some
setup before starting vCPUs. Normally vCPUs are started by def
On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> Hi All,
>
> (sorry for the long message)
>
> CPUs from AMD EPYC family supports Secure Encrypted Virtualization (SEV)
> feature - the feature allows running encrypted VMs. To enable the feature,
> I have been submitting patches to Linux kernel [1], Qemu [2] and OVMF [3].
> We have been making some good progress in getting patches accepted upstream
> in Linux and OVMF trees. SEV builds upon SME (Secure Memory Encryption)
> feature -- SME support just got pulled into 4.14 merge window. The base
> SEV patches are accepted in OVMF tree -- now we have SEV aware guest BIOS.
> I am getting ready to take off "RFC" tag from remaining patches to get them
> reviewed and accepted.
>
> The boot flow for launching an SEV guest is a bit different from a typical
> guest launch. In order to launch SEV guest from virt-manager or other
> high-level VM management tools, we need to design and implement new
> interface between libvirt and qemu, and probably add new APIs in libvirt
> to be used by VM management tools. I am new to the libvirt and need some
> expert advice while designing this interface. A pictorial representation
> for a SEV guest launch flow is available in SEV Spec Appendix A [4].
>
> A typical flow looks like this:
>
> 1. Guest owner (GO) asks the cloud provider to launch SEV guest.
> 2. VM tool asks libvirt to provide its Platform Diffie-Hellman (PDH) key.
> 3. libvirt opens /dev/sev device to get its PDH and return the blob to the
> caller.
What sort of size are we talking about for the PDH ?
There's a few ways libvirt could report it
1. As an XML element in the host capabilities XML
2. As an XML element in the emulator capabilities XML
3. Via a newly added host API
> 4. VM tool gives its PDH to GO.
> 5. GO provides its DH key, session-info and guest policy.
Are steps 4 & 5 strictly required to be in this order, or is it
possible
What are the security requirements around the DH key, session info
and guest policy ? Are any of them sensitive data which needs to be
kept private from untrustworthy users. Also are all three of these
items different for every guest launched, or are some of them
likely to be the same for every guest ?
eg, would the same guest policy blob be used for every guest, with
only session info changing ?
Also what sort of size are we talking about for each of these
data items, KBs, 10's of KB, 100's of KBs or larger ?
The security and data size can influence our design approach from
the libvirt POV.
> 6. VM tool somehow communicates the GO provided information to libvirt.
Essentially we have two choices
1. inline in the guest XML config description passed to libvirt
when defining the guest XML
2. out of band, ahead of time, via some other API prior to defining
the guest XML, which is then referenced in guest XML. THis could
be done using the virSecret APIs, where we create 3 secrets, one
each for DH key, session-info and guets policy. The UUID of the
secret could be specified in the guest XML. This has flexibility
of allowing the same secrets ot be used for many guests (if this
is valid for SEV)
> 7. libvirt adds "sev-guest" object in its xml file with all the information
> obtained from #5
>
> (currently my xml file looks like this)
>
>
> value='sev-guest,id=sev0,policy=,dh-key-file=,session-file=/>
>
>
>
> 8. libvirt launches the guest with "-S"
All libvirt guests get launched with -S, to give libvirt chance to do some
setup before starting vCPUs. Normally vCPUs are started by default, but
the VIR_DOMAIN_START_PAUSED flag allows the mgmt app to tell libvirt to
leave vCPUS paused.
Alternatively, if libvirt sees presencese of 'sev' config for the guest,
it could automatically leave it in PAUSED state regardless of the
VIR_DOMAIN_START_PAUSED flag.
> 9. While creating the SEV guest qemu does the following
> i) create encryption context using GO's DH, session-info and guest policy
> (LAUNCH_START)
> ii) encrypts the guest bios (LAUNCH_UPDATE_DATA)
> iii) calls LAUNCH_MEASUREMENT to get the encrypted bios measurement
> 10. By some interface we must propagate the measurement all the way to GO
> before libvirt starts the guest.
Again, what kind of size data are we talking about for athe "measurement"
blob ? a KB, 10's of KB, or more ?
My first gut instinct would be for QEMU to emit a QMP event when it has
the measurement available. The event could include the actual data blob,
or we can could add an explicit QMP command to fetch the data blob.
Libvirt could listen for this QEMU event, and in turn emit an event from
libvirt with the same data, which the mgmt tool can finally give to the
GO.
> 11. GO verifies the measurement and if measurement matches then it may
> give a secret blob -- which must be injected into the guest before
> libvirt starts the VM. If verification failed, GO will request cloud
> provider to destroy the VM.
So w
On Fri, Sep 08, 2017 at 11:06:08AM +0200, Martin Kletzander wrote:
> On Thu, Sep 07, 2017 at 03:48:13PM +0200, Erik Skultety wrote:
> > So we refer to terms 'persistent' and 'transient' across the whole man
> > page, without explicitly stating that domain created via the 'create'
> > command is in fact transient and will vanish once destroyed.
> >
> > Signed-off-by: Erik Skultety
> > ---
> > tools/virsh.pod | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/tools/virsh.pod b/tools/virsh.pod
> > index c13f96f22..14a01e9ba 100644
> > --- a/tools/virsh.pod
> > +++ b/tools/virsh.pod
> > @@ -652,6 +652,11 @@ of open file descriptors which should be pass on into
> > the guest. The
> > file descriptors will be re-numbered in the guest, starting from 3. This
> > is only supported with container based virtualization.
> >
> > +Note that a domain created using this command is transient (temporary),
> > meaning
> > +that such a domain simply disappears once shut off or destroyed and any
> > +subsequent attempts to B it will fail. See B command on how
> > to
> > +make a domain persistent.
> > +
>
> Not really. With this command you can also start existing domain, just
> with a different configuration. Given that the example below shows
> exactly that usage, I think someone might get a bit confused. Would you
> mind rewriting it to accommodate all variants?
I pushed 2/2 and sent a v2 of this one, rewording things a bit.
Thanks,
Erik
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
So we refer to the terms 'persistent' and 'transient' across the whole
man page, without describing it further, but more importantly, how the
create command affects it, i.e. explicitly stating that domain created
via the 'create' command are going to be transient or persistent,
depending on whether there is an existing persistent domain with a
matching and , in which case it will remain persistent, but
will run using a one-time configuration, otherwise it's going to be
transient and will vanish once destroyed.
Signed-off-by: Erik Skultety
---
tools/virsh.pod | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 01453be60..c4c76fcb1 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -640,9 +640,14 @@ sessions, such as in a case of a broken connection.
Create a domain from an XML . Optionally, I<--validate> option can be
passed to validate the format of the input XML file against an internal RNG
-schema (identical to using L tool). An easy way to create
-the XML is to use the B command to obtain the definition of a
-pre-existing guest. The domain will be paused if the I<--paused> option is
used
+schema (identical to using L tool). Domains created using
+this command are going to be either transient (temporary ones that will vanish
+once destroyed) or existing persistent domains that will run with one-time use
+configuration, leaving the persistent XML untouched (this can come handy during
+an automated testing of various configurations all based on the original XML).
+See the B section for usage demonstration.
+
+The domain will be paused if the I<--paused> option is used
and supported by the driver; otherwise it will be running. If I<--console> is
requested, attach to the console after creation.
If I<--autodestroy> is requested, then the guest will be automatically
@@ -656,9 +661,24 @@ is only supported with container based virtualization.
B
- virsh dumpxml > domain.xml
- vi domain.xml (or make changes with your other text editor)
- virsh create domain.xml
+ 1) prepare a template from an existing domain (skip directly to 3a if writing
+one from scratch)
+
+ # virsh dumpxml > domain.xml
+
+ 2) edit the template using an editor of your choice and:
+a) DO CHANGE! and ( can also be removed), or
+b) DON'T CHANGE! either or
+
+ # $EDITOR domain.xml
+
+ 3) create a domain from domain.xml, depending on whether following 2a or 2b
+respectively:
+a) the domain is going to be transient
+b) an existing persistent domain will run with a modified one-time
+ configuration
+
+ # virsh create domain.xml
=item B I [I<--validate>]
--
2.13.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi All,
(sorry for the long message)
CPUs from AMD EPYC family supports Secure Encrypted Virtualization (SEV)
feature - the feature allows running encrypted VMs. To enable the feature,
I have been submitting patches to Linux kernel [1], Qemu [2] and OVMF [3].
We have been making some good progress in getting patches accepted upstream
in Linux and OVMF trees. SEV builds upon SME (Secure Memory Encryption)
feature -- SME support just got pulled into 4.14 merge window. The base
SEV patches are accepted in OVMF tree -- now we have SEV aware guest BIOS.
I am getting ready to take off "RFC" tag from remaining patches to get them
reviewed and accepted.
The boot flow for launching an SEV guest is a bit different from a typical
guest launch. In order to launch SEV guest from virt-manager or other
high-level VM management tools, we need to design and implement new
interface between libvirt and qemu, and probably add new APIs in libvirt
to be used by VM management tools. I am new to the libvirt and need some
expert advice while designing this interface. A pictorial representation
for a SEV guest launch flow is available in SEV Spec Appendix A [4].
A typical flow looks like this:
1. Guest owner (GO) asks the cloud provider to launch SEV guest.
2. VM tool asks libvirt to provide its Platform Diffie-Hellman (PDH) key.
3. libvirt opens /dev/sev device to get its PDH and return the blob to the
caller.
4. VM tool gives its PDH to GO.
5. GO provides its DH key, session-info and guest policy.
6. VM tool somehow communicates the GO provided information to libvirt.
7. libvirt adds "sev-guest" object in its xml file with all the information
obtained from #5
(currently my xml file looks like this)
8. libvirt launches the guest with "-S"
9. While creating the SEV guest qemu does the following
i) create encryption context using GO's DH, session-info and guest policy
(LAUNCH_START)
ii) encrypts the guest bios (LAUNCH_UPDATE_DATA)
iii) calls LAUNCH_MEASUREMENT to get the encrypted bios measurement
10. By some interface we must propagate the measurement all the way to GO
before libvirt starts the guest.
11. GO verifies the measurement and if measurement matches then it may
give a secret blob -- which must be injected into the guest before
libvirt starts the VM. If verification failed, GO will request cloud
provider to destroy the VM.
12. After secret blob is injected into guest, we call LAUNCH_FINISH
to destory the encryption context.
13. libvirt issues "continue" command to resume the guest boot.
Please note that the measurement value is protected with transport
encryption key (TIK) and it changes on each run. Similarly the secret blob
provided by GO does not need to be protected using libvirt/qemu APIs. The
secret is protected by TIK. From qemu and libvirt point of view these are
blobs and must be passed as-is to the SEV FW.
Questions:
a) Do we need to add a new set of APIs in libvirt to return the PDH from
libvirt and VM tool ? Or can we use some pre-existing APIs to pass the
opaque blobs ? (this is mainly for step 3 and 6)
b) do we need to define a new xml tag to for memory-encryption ? or just
use the qemu:args tag ? (step 6)
c) what existing communicate interface can be used between libvirt and qemu
to get the measurement ? can we add a new qemu monitor command
'get_sev_measurement' to get the measurement ? (step 10)
d) how to pass the secret blob from libvirt to qemu ? should we consider
adding a new object (sev-guest-secret) -- libvirt can add the object through
qemu monitor.
[1] https://marc.info/?l=kvm&m=150092661105069&w=2
[2] https://marc.info/?l=qemu-devel&m=148901186615642&w=2
[3] https://lists.01.org/pipermail/edk2-devel/2017-July/012220.html
[4] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
Thanks
Brijesh
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Sep 07, 2017 at 03:48:14PM +0200, Erik Skultety wrote:
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1368753
Signed-off-by: Erik Skultety
---
tools/virsh.pod | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 14a01e9ba..8ab93faf2 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -636,13 +636,15 @@ the I<--force> flag may be specified, requesting to
disconnect any existing
sessions, such as in a case of a broken connection.
=item B I [I<--console>] [I<--paused>] [I<--autodestroy>]
-[I<--pass-fds N,M,...>]
+[I<--pass-fds N,M,...>] [I<--validate>]
-Create a domain from an XML . An easy way to create the XML
- is to use the B command to obtain the definition of a
-pre-existing guest. The domain will be paused if the I<--paused> option
-is used and supported by the driver; otherwise it will be running.
-If I<--console> is requested, attach to the console after creation.
+Create a domain from an XML . Optionally, I<--validate> option can be
+passed to validate the format of the input XML file against an internal RNG
+schema (identical to using L tool). An easy way to create
+the XML is to use the B command to obtain the definition of a
+pre-existing guest. The domain will be paused if the I<--paused> option is
used
+and supported by the driver; otherwise it will be running. If I<--console> is
+requested, attach to the console after creation.
If I<--autodestroy> is requested, then the guest will be automatically
destroyed when virsh closes its connection to libvirt, or otherwise
exits.
@@ -663,10 +665,12 @@ B
vi domain.xml (or make changes with your other text editor)
virsh create domain.xml
-=item B I
+=item B I [I<--validate>]
-Define a domain from an XML . The domain definition is registered
-but not started. If domain is already running, the changes will take
+Define a domain from an XML . Optionally, the format of the input XML
+file can be validated against an internal RNG schema with I<--validate>
+(identical to using L tool). The domain definition is
+registered but not started. If domain is already running, the changes will
take
effect on the next boot.
I though we made this the default. It looks like we did that only for
cmdEdit. In that case,
Reviewed-by: Martin Kletzander
=item B I [[I<--live>] [I<--config>] |
--
2.13.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Sep 07, 2017 at 03:48:13PM +0200, Erik Skultety wrote:
So we refer to terms 'persistent' and 'transient' across the whole man
page, without explicitly stating that domain created via the 'create'
command is in fact transient and will vanish once destroyed.
Signed-off-by: Erik Skultety
---
tools/virsh.pod | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index c13f96f22..14a01e9ba 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -652,6 +652,11 @@ of open file descriptors which should be pass on into the
guest. The
file descriptors will be re-numbered in the guest, starting from 3. This
is only supported with container based virtualization.
+Note that a domain created using this command is transient (temporary), meaning
+that such a domain simply disappears once shut off or destroyed and any
+subsequent attempts to B it will fail. See B command on how to
+make a domain persistent.
+
Not really. With this command you can also start existing domain, just
with a different configuration. Given that the example below shows
exactly that usage, I think someone might get a bit confused. Would you
mind rewriting it to accommodate all variants?
B
virsh dumpxml > domain.xml
--
2.13.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Sep 07, 2017 at 03:47:51PM +0200, Erik Skultety wrote:
Since commit @ae2163f8, only active client connections or running
domains are allowed to inhibit daemon shutdown. The man page however
wasn't updated appropriately.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325066
Signed-off-by: Erik Skultety
Reviewed-by: Martin Kletzander
---
daemon/libvirtd.pod | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/daemon/libvirtd.pod b/daemon/libvirtd.pod
index 9f5a17d9c..8d3fbd13d 100644
--- a/daemon/libvirtd.pod
+++ b/daemon/libvirtd.pod
@@ -56,10 +56,8 @@ Use this name for the PID file, overriding the default value.
=item B<-t, --timeout> I
-Exit after timeout period (in seconds) elapse with no client connections
-or registered resources. Be aware that resources such as autostart
-networks will result in never reaching the timeout, even when there are
-no client connections.
+Exit after timeout period (in seconds), provided there are neither any client
+connections nor any running domains.
=item B<-v, --verbose>
--
2.13.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
