11:44 a.m.
commit fa6fab3af05e06688bbd80259d96d03ada37611a
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Fri Jul 3 11:42:25 2015 -0500
Domains Chapter
Provisioning section
- Finished the Provisioning section.
- Added examples 15-19.
en-US/Guest_Domains.xml | 165 +++++++++++++----------------------
en-US/extras/Domains-Example-15.xml | 6 ++
en-US/extras/Domains-Example-16.py | 21 +++++
en-US/extras/Domains-Example-17.xml | 4 +
en-US/extras/Domains-Example-18.xml | 5 +
en-US/extras/Domains-Example-19.py | 25 +++++
6 files changed, 122 insertions(+), 104 deletions(-)
---
diff --git a/en-US/Guest_Domains.xml b/en-US/Guest_Domains.xml
index cbf1ba9..a841cf2 100644
--- a/en-US/Guest_Domains.xml
+++ b/en-US/Guest_Domains.xml
@@ -465,140 +465,97 @@
</section>
<section
id="libvirt_application_development_guide_using_python-Guest_Domains-Lifecycle-Provisioning-Kernel">
- <title>Direct kernel boot provisioning</title>
+ <title>Direct Kernel Boot Provisioning</title>
<para>
- Paravirtualization technologies emulate a fairly restrictive
- set of hardware, often making it impossible to use the provisioning
- options just outlined. For such scenarios it is often possible to
- boot a new guest domain directly from an kernel and initrd image
- stored on the host file system. This has one interesting advantage,
- which is that it is possible to directly set kernel command line
- boot arguments, making it very easy to do fully automated
- installation. This advantage can be compelling enough that this
- technique is used even for fully virtualized guest domains with
- CD-ROM drive/PXE support.
+ Paravirtualization technologies emulate a fairly restrictive
+ set of hardware, often making it impossible to use the provisioning
+ options just outlined. For such scenarios it is often possible to
+ boot a new guest domain directly from an kernel and initrd image
+ stored on the host file system. This has one interesting advantage,
+ which is that it is possible to directly set kernel command line
+ boot arguments, making it very easy to do fully automated
+ installation. This advantage can be compelling enough that this
+ technique is used even for fully virtualized guest domains with
+ CD-ROM drive/PXE support.
</para>
<para>
- The one complication with direct kernel booting is that provisioning
- becomes a two step process. For the first step, it is necessary to
- configure the guest XML configuration to point to a kernel/initrd.
+ The one complication with direct kernel booting is that provisioning
+ becomes a two step process. For the first step, it is necessary to
+ configure the guest XML configuration to point to a kernel/initrd.
</para>
- <programlisting>
- <![CDATA[
- <os>
- <type arch='x86_64' machine='pc'>hvm</type>
- <kernel>/var/lib/libvirt/boot/f11-x86_64-vmlinuz</kernel>
- <initrd>/var/lib/libvirt/boot/f11-x86_64-initrd.img</initrd>
-
<cmdline>method=http://download.fedoraproject.org/pub/fedora/linux/rele...
console=ttyS0 console=tty</cmdline>
- </os>
- ]]>
- </programlisting>
+ <example>
+ <title>Kernel Boot Provisioning XML</title>
+ <programlisting language="Python"><xi:include
href="extras/Domains-Example-15.xml" parse="text"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+ </example>
<para>
- Notice how the kernel command line provides the URL of download
- site containing the distro install tree matching the kernel/initrd.
- This allows the installer to automatically download all its resources
- without prompting the user for install URL. It could also be used to
- provide a kickstart file for completely unattended installation.
- Finally, this command line also tells the kernel to activate both
- the first serial port and the VGA card as consoles, with the latter
- being the default. Having kernel messages duplicated on the serial
- port in this manner can be a useful debugging avenue. Of course
- valid command line arguments vary according to the particular kernel
- being booted. Consult the kernel vendor/distributor's
documentation
- for valid options.
+ Notice how the kernel command line provides the URL of download
+ site containing the distro install tree matching the kernel/initrd.
+ This allows the installer to automatically download all its
resources
+ without prompting the user for install URL. It could also be used to
+ provide a kickstart file for completely unattended installation.
+ Finally, this command line also tells the kernel to activate both
+ the first serial port and the VGA card as consoles, with the latter
+ being the default. Having kernel messages duplicated on the serial
+ port in this manner can be a useful debugging avenue. Of course
+ valid command line arguments vary according to the particular kernel
+ being booted. Consult the kernel vendor/distributor's
documentation
+ for valid options.
</para>
<para>
- The last XML configuration detail before starting the guest, is to
- change the 'on_reboot' element action to be 'destroy'.
This ensures
- that when the guest installer finishes and requests a reboot, the
- guest is instead powered off. This allows the management application
- to change the configuration to make it boot off, just installed, the
- hard disk again. The provisioning process can be started now by
- creating a transient guest with the first XML configuration
+ The last XML configuration detail before starting the guest, is to
+ change the 'on_reboot' element action to be
'destroy'. This ensures
+ that when the guest installer finishes and requests a reboot, the
+ guest is instead powered off. This allows the management application
+ to change the configuration to make it boot off, just installed, the
+ hard disk again. The provisioning process can be started now by
+ creating a transient guest with the first XML configuration
</para>
- <programlisting>
- <![CDATA[
- const char *xml = "<domain>....</domain>";
- virDomainPtr dom;
-
- dom = virDomainCreateXML(conn, xml);
- if (!dom) {
- fprintf(stderr, "Unable to boot transient guest configuration");
- return;
- }
- ]]>
- </programlisting>
+ <example>
+ <title>Kernel Boot Provisioning</title>
+ <programlisting language="Python"><xi:include
href="extras/Domains-Example-16.py" parse="text"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+ </example>
<para>
- Once this guest shuts down, the second phase of the provisioning
- process can be started. For this phase, the 'OS' element will
- have the kernel/initrd/cmdline elements removed, and replaced
- by either a reference to a host side bootloader, or a BIOS
- boot setup. The former is used for Xen paravirtualized guests,
- while the latter is used for fully virtualized guests.
+ Once this guest shuts down, the second phase of the provisioning
+ process can be started. For this phase, the 'OS' element
will
+ have the kernel/initrd/cmdline elements removed, and replaced
+ by either a reference to a host side bootloader, or a BIOS
+ boot setup. The former is used for Xen paravirtualized guests,
+ while the latter is used for fully virtualized guests.
</para>
<para>
- The phase 2 configuration for a Xen paravirtualized guest
- would thus look like:
+ The phase 2 configuration for a Xen paravirtualized guest
+ would thus look like:
</para>
- <programlisting>
- <![CDATA[
- <bootloader>/usr/bin/pygrub</bootloader>
- <os>
- <type arch='x86_64' machine='pc'>xen</type>
- </os>
- ]]>
- </programlisting>
+ <programlisting language="Python"><xi:include
href="extras/Domains-Example-17.xml" parse="text"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
<para>
while a fully-virtualized guest would use:
</para>
- <programlisting>
- <![CDATA[
- <bootloader>/usr/bin/pygrub</bootloader>
- <os>
- <type arch='x86_64' machine='pc'>hvm</type>
- <boot dev='hd'/>
- </os>
- ]]>
- </programlisting>
+ <programlisting language="Python"><xi:include
href="extras/Domains-Example-18.xml" parse="text"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
<para>
- With the second phase configuration determined, the guest can
- be recreated, this time using a persistent configuration
+ With the second phase configuration determined, the guest can
+ be recreated, this time using a persistent configuration
</para>
- <programlisting>
- <![CDATA[
- const char *xml = "<domain>....</domain>";
- virDomainPtr dom;
-
- dom = virDomainCreateXML(conn, xml);
- if (!dom) {
- fprintf(stderr, "Unable to define persistent guest
configuration\n");
- return;
- }
-
- if (virDomainCreate(dom) < 0) {
- fprintf(stderr, "Unable to boot persistent guest\n");
- return;
- }
+ <example>
+ <title>Kernel Boot Provisioning for a Persistent Guest
Domain</title>
+ <programlisting language="Python"><xi:include
href="extras/Domains-Example-19.py" parse="text"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+ </example>
- fprintf(stderr, "Guest provisoning complete, OS is running\n");
- ]]>
- </programlisting>
- </section>
- </section>
- </section>
+ </section>
+ </section>
+ </section>
<section
id="libvirt_application_development_guide_using_python-Guest_Domains-Lifecycle-Stopping">
<title>Stopping</title>
diff --git a/en-US/extras/Domains-Example-15.xml b/en-US/extras/Domains-Example-15.xml
new file mode 100644
index 0000000..4cdbed9
--- /dev/null
+++ b/en-US/extras/Domains-Example-15.xml
@@ -0,0 +1,6 @@
+<os>
+ <type arch='x86_64' machine='pc'>hvm</type>
+ <kernel>/var/lib/libvirt/boot/f11-x86_64-vmlinuz</kernel>
+ <initrd>/var/lib/libvirt/boot/f11-x86_64-initrd.img</initrd>
+
<cmdline>method=http://download.fedoraproject.org/pub/fedora/linux/rele...
console=ttyS0 console=tty</cmdline>
+</os>
diff --git a/en-US/extras/Domains-Example-16.py b/en-US/extras/Domains-Example-16.py
new file mode 100644
index 0000000..a76ecb2
--- /dev/null
+++ b/en-US/extras/Domains-Example-16.py
@@ -0,0 +1,21 @@
+# Example-14.py
+from __future__ import print_function
+import sys
+import libvirt
+
+xmlconfig = '<domain>........</domain>'
+
+conn = libvirt.open('qemu:///system')
+if conn == None:
+ print('Failed to open connection to qemu:///system', file=sys.stderr)
+ exit(1)
+
+dom = conn.createXML(xmlconfig, 0)
+if dom == None:
+ print('Unable to boot transient guest configuration.', file=sys.stderr)
+ exit(1)
+
+print('Guest '+dom.name()+' has booted', file=sys.stderr)
+
+conn.close()
+exit(0)
diff --git a/en-US/extras/Domains-Example-17.xml b/en-US/extras/Domains-Example-17.xml
new file mode 100644
index 0000000..71f15f1
--- /dev/null
+++ b/en-US/extras/Domains-Example-17.xml
@@ -0,0 +1,4 @@
+<bootloader>/usr/bin/pygrub</bootloader>
+<os>
+ <type arch='x86_64' machine='pc'>xen</type>
+</os>
diff --git a/en-US/extras/Domains-Example-18.xml b/en-US/extras/Domains-Example-18.xml
new file mode 100644
index 0000000..ad83460
--- /dev/null
+++ b/en-US/extras/Domains-Example-18.xml
@@ -0,0 +1,5 @@
+<bootloader>/usr/bin/pygrub</bootloader>
+<os>
+ <type arch='x86_64' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+</os>
diff --git a/en-US/extras/Domains-Example-19.py b/en-US/extras/Domains-Example-19.py
new file mode 100644
index 0000000..7ee682e
--- /dev/null
+++ b/en-US/extras/Domains-Example-19.py
@@ -0,0 +1,25 @@
+# Example-18.py
+from __future__ import print_function
+import sys
+import libvirt
+
+xmlconfig = '<domain>........</domain>'
+
+conn = libvirt.open('qemu:///system')
+if conn == None:
+ print('Failed to open connection to qemu:///system', file=sys.stderr)
+ exit(1)
+
+dom = conn.createXML(xmlconfig, 0)
+if dom == None:
+ print('Unable to define persistent guest configuration.', file=sys.stderr)
+ exit(1)
+
+if dom.create(dom) < 0:
+ print('Can not boot guest domain.', file=sys.stderr)
+ exit(1)
+
+print('Guest '+dom.name()+' has booted', file=sys.stderr)
+
+conn.close()
+exit(0)