How to boot up from CDROM(ISO image) to install the guest OS using virsh

Question

UPDATE on Oct. 4th, 2017: See my answer below. The credit goes to DanielB as I wouldn't have solved the problem without Daniel's help, so I'll accept his answer instead of my own.

---

I'm a novice in libvirt as well as system administration so excuse me if I'm asking stupid questions, though I've tried to do as much homework as possible beforehand.

My question is: How to boot up from CDROM to install the guest OS right after creating a VM using virsh?

I'm working on Ubuntu Desktop 14.04, virsh 1.2.2.

When I used 'virt-install' and passed the ISO file path as its '--cdrom' argument, I could successfully bring up the virt-viewer window which allowed me to go through the guest OS installation.

As I know I can also create a VM using an XML definition, I dumped the XML definition of the VM which I created using 'virt-install'. I then expected that the 'virt-viewer' window would be brought up automatically when I started the VM so I could install the guest OS. But it didn't.

Below is the XML definition of my VM.

If I enable the loader line, as I marked as "suspicious" below, I would get an error message of "error: internal error: cannot load AppArmor profile 'libvirt-1092d51d-3b66-46a2-bf9b-71e13dc91799'". I did that because I was trying the example given in libvirt's document here.

However, if I disable the "loader" line, and ran virsh create def_domain_test.xml, the domain can be created successfully and is shown as 'running', but the virt-viewer window is not brought up, so I can't install the guest OS on the VM.

Could anyone help me on that? I don't understand why 'virt-install' can bring up the virt-viewer but my XML definition can't. I probably mis-configured the domain XML definition but I couldn't figure out which specific part I was wrong even if I'd tried to read as much documentation as possible.

Feel free to ask for more details if needed.

<!-- Let's call this file 'def_domain_test.xml' -->
<domain type='kvm'>
  <name>vm_c2</name>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
    <!-- Next line is suspicious! -->
    <!-- <loader readonly='yes' secure='no' type='rom'>/usr/lib/xen-4.4/boot/hvmloader</loader> -->
    <boot dev='cdrom'/>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>

    <!-- Here is the hard drive that doesn't have OS installed. -->
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/home/me/me/testing/vm/pool/mvs_vol_c2'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

    <!-- Here is the Ubuntu ISO. -->
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/home/me/me/testing/vm/ubuntu-14.04.5-server-amd64.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='network'>
      <source network='default'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Answer 1

Thanks for DanielB's help! The '--debug' argument of virt-install does reveal the information I need to solve this problem.

First of all, in the XML definition, I don't need the <loader> line. The <os> section should be:

<os>
  <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
  <boot dev='cdrom'/>
  <boot dev='hd'/>
</os>

The two <boot> tags already specify the order of booting.

Secondly, virt-install's debug output suggests the desired way to bring up virt-viewer:

• Run: virt-viewer --connect=qemu:///system --wait vm_c2
  • Optionally, you can add '--debug' and '--verbose' to virt-viewer to see more output.
  • At this moment, the viewer window should be brought up and a message is shown: Waiting for guest domain to be created.
• Run: virsh create --file def_domain_test.xml.
  • The viewer would now be activated and display the output of the VM.

Here is one caveat which caused me to get stuck at the beginning: You don't have to start virt-viewer prior to the VM. However, if you start VM first and then the viewer, the viewer screen may be a whole black one which may confuse you and make you think nothing is happening there. In this case, click the viewer window to let it get the input focus, then press 'Enter' key and you may get it refreshed and see what is there actually. (Resizing the window doesn't force it to refresh.)

FYI: If you output the virt-viewer's debug messages, you may see a message like this:

(virt-viewer:6296): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics

This doesn't seem to cause me any problems, but maybe it's the hint of other problems if virt-viewer doesn't work correctly for you.

Answer 2

virsh is a very low level tool whose commands direct map to individual libvirt API calls. A installation done by virt-install will make many API calls to accomplish its job. So just taking the final XML of the installed guest and passing it to virsh define is not equivalant.

For a start, virt-install will usually change the XML - it first creates a transient guest will an XML doc suitable for booting off the CDROM, and after that completes it'll change the XML to boot off the disk instead. virt-install will manually launch virt-viewer to display the console, which is not something virsh does.

That particular <loader> line should never be used with KVM - it is only relevant for Xen - by using that you've told KVM to run Xen paravirt code as its BIOS instead of SeaBIOS - this will certainly crash & burn.

If you use the '--debug' arg to virt-install you'll see details of what it does at each step. You could also set LIBVIRT_LOG_FILTERS=1:libvirt and LIBVIRT_LOG_OUTPUTS=1:stderr if you want to see details of every libvirt API call made.