# qemu-kvm manually vs. libvirt/virsh [resolved]

## dvh

I have used qemu-img to create a disk image file (qcow), and then used qemu-kvm, booting from cdrom, to install a new arch (lots faster to install than gentoo for a test) system into the disk image file.  I can boot and run the new VM using the image file with its embedded grub loader using equm-kvm from the command line, like this:

```

qemu-kvm -enable-kvm -hda /opt/a32.qcow -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 -m 512 -name a32-kvm
```

this works fine, including the setup of a bridged nework.  following the boot, I can easily ssh into the VM and work from there.

I want to try to manage this VM (and others like it) using libvirt, virsh.  I created a .xml config file (a32.xml) IAW the libvirt doumentation, but I am having trouble getting the VM to run when I use

```

virsh create a32.xml
```

here is the .xml

```

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

  <name>a32</name>

  <memory>524288</memory>

  <vcpu>1</vcpu>

  <os>

    <type arch='x86_64'>hvm</type>

    <boot dev='hd'/>

  </os>

  <clock offset='utc'/>

  <on_poweroff>destroy</on_poweroff>

  <on_reboot>restart</on_reboot>

  <on_crash>restart</on_crash>

  <devices>

    <disk type='file' device='disk'>

      <driver name='qemu' type='raw'/>

      <source file='/opt/a32.qcow'/>

      <target dev='hda'/>

    </disk>

    <disk type='file' device='cdrom'>

      <source file='/home/dvh/Downloads/archlinux-2010.05-core-i686.iso'/>

      <target dev='hdc'/>

      <readonly/>

    </disk>

    <interface type='bridge'>

      <source bridge='br0'/>

      <mac address='52:54:00:7f:46:85'/>

      <target dev='tap0'/>

      <script path='/etc/qemu-ifup'/>

    </interface>

    <input type='mouse' bus='ps2'/>

    <graphics type='vnc' port='5904'/>

    <video>

      <model type='vga'/>

    </video>

  </devices>

</domain>

```

when I use virsh to start this a32.xml, the new domain is created, but the console reports that the disk is not bootable.  but I know that it is bootable, because it works fine when starting with the qemu-kvm command as above.  IF I change the boot device to be 'cdrom' the VM starts fine (boots into the .iso install screen), and I can use the install process (from the .iso) to see the named disk image at hda, so I know that the disk image file is indeed found and accessible.

There must be some nuance about the libvirt .xml file that I am missing.  why would my image file be bootable when booting using qemu-kvm directly on the command line, but NOT bootable when I use virsh to boot the VM?

-dvhLast edited by dvh on Thu Aug 26, 2010 12:51 am; edited 1 time in total

----------

## Hu

 *dvh wrote:*   

> I have used qemu-img to create a disk image file (qcow)
> 
> ```
> 
>       <driver name='qemu' type='raw'/>
> ...

 I have no experience with virsh, but that looks inconsistent to me.  Are you sure that you should specify type=raw here?

If that does not solve it, I suggest comparing the command line that virsh generates for qemu with the command line you use to start it by hand.

----------

## dvh

Thanks for the reply, Hu.  I am not at all sure if I should or should not specify 'raw'...just trying to follow some examples I found online.  WRT the command line...I did do some of that.  after virsh starts the VM, using "ps aux" I can see the command line it uses.  it does not seem to rely on ANY defaults, but instead provides a value for what seems like EVERY possible parameter.  the command line wraps 4 times.  so the difference could be any of about 5o things.

I will try to remove the 'raw' selection and see what happens.  any idea what I might substitute, or maybe just remove it?

-dvh

----------

## dvh

I removed the "type='raw'" qualifier...result is no better.  virsh generated command line still contains "type='raw'", so I am assuming that this is a default which virsh imposes.  did some more research, and found this:

```
<driver name='qemu' type='qcow2'/>
```

.  tried this and...SOME SUCCESS.  instead of being non-bootable, I see the grub boot screen, and when I select the row and boot, it begins booting, decompresses the kernel, states "Booting the kernel", then hangs.

...but thanks to your suggestion, Hu, I have made some progress.  now back to try to solve this next issue...

-dvh

----------

## dvh

here is the command line that virsh generates...

```
 /usr/bin/qemu-system-x86_64 -S -M pc-0.12 -enable-kvm -

m 512 -smp 1,sockets=1,cores=1,threads=1 -name a32 -uuid d8ccbd67-e734-fa5b-a463-7beb7de2f827 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/a32.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -no-acpi -boot c -drive file=/opt/a32.qcow,if=none,id=drive-ide0-0-0,boot=on,format=qcow2 -device ide-drive,bus=ide.0,unit=0,

drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/home/dvh/Downloads/archlinux-2010.05-core-i686.iso,if=none,media=cdrom,id=

drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device rtl813

9,vlan=0,id=net0,mac=52:54:00:7f:46:85,bus=pci.0,addr=0x3 -net tap,fd=36,vlan=0,name=hostnet0 -usb -vnc 127.0.0.1:4 -vga

 std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

```

and here is my qemu-kvm manually created command

```

qemu-kvm -enable-kvm -hda /opt/a32.qcow -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 -m 512 -name a32-kvm -vnc 127.0.0.1:4 -vga std
```

as you can see, the autogenerated command from virsh is far more fully populated than my manual version.

but where the hang is occurring, it would seem like control has been passed to the bootloader code within the target in either case, so it would seem like only what is in the target filesystem should be of interest...and it works fine with the second command, but not the first...very strange.

maybe it has something to do with the actual command that is used (qemu-system-x86_64 vs. qemu-kvm)?  I thought I understood that these were generally equivalent.  is that not true?

again, any help would be appreciated.

-dvh

----------

## idella4

dvh,

you're missing out on using the full power of libvirt.

emerge virtinst.  then use the import mode.

```

sudo virt-install -n myvm -r 350 --connect=qemu:///system -v --import --disk path=/path/to/myvm -w bridge=virbr0[or whatever] --vnc 

```

and to make it even more luxurious, emerge virt-manager to house a vnc console

----------

## Hu

 *dvh wrote:*   

> 
> 
> ```
> -no-acpi
> ```
> ...

 This can change the guest's behavior in noticeable ways.  Usually, ACPI is a good thing to leave enabled, unless you have specific problems with it that cannot be fixed. *dvh wrote:*   

> but where the hang is occurring, it would seem like control has been passed to the bootloader code within the target in either case, so it would seem like only what is in the target filesystem should be of interest...and it works fine with the second command, but not the first...very strange.

 Not necessarily.  From what you said, the kernel may not have reached the point where it begins reading the filesystem, in which case differences in the virtual hardware are still a candidate.

 *dvh wrote:*   

> maybe it has something to do with the actual command that is used (qemu-system-x86_64 vs. qemu-kvm)?  I thought I understood that these were generally equivalent.  is that not true?

 

```
#!/bin/sh

exec /usr/bin/qemu-system-x86_64 --enable-kvm "$@"
```

----------

## dvh

idella4:  thanks for the virt-install tip.  I had tried this --import feature with virt-install, but the VM generated did not boot.  But I had not tried it since I learned (from a tip above from Hu) that I had the wrong image file format.  so I tried your suggested command again, and it still did not work (VM hanging at boot).  I examined the .xml generated by virt-install, and it had included the format='raw' by default, I guess.  used virsh edit to change that parameter, and WOW, I have a VM that boots, runs, and is manageable using the libvirt tools.  Great.

I thought I might add to your command line to say:

```

virt-install -n a32-kvm -r 1024 --connect=qemu:///system -v --import --disk path=/opt/a32.qcow,format=qcow2 -w bridge=br0 --vnc --prompt
```

 (notice the format= option I tried) so that I would not need to had edit the xml, but that made no difference, so I must have some error in the syntax.

Hu:  I am not altogether certain why my VM boots successfully now, but I do notice that the auto-generated .xml contains this:

```
<features>

    <acpi/>

    <apic/>

    <pae/>

  </features>
```

 which I am thinking has now changed my setting for acpi...and that could have made the difference.

lastly, Idella4, I looked at using virt-manager, but it wants to pull in a whole load of gnome stuff, which I don't want.  Is there a way to use this tool without gnome?  I use the more minimal fluxbox.

anyway, thank you both for all of your help.

----------

## idella4

dvh

 *Quote:*   

> 
> 
> I thought I might add to your command line to say:
> 
> 

 

Yep, that's the way to do it.  You managed one thing that has defeated me constantly, and that's using virsh edit.  When I use it, it comes out boasting it changed nothing.  I make a file in xml and edit it external to libvirt.  Si you took my tip, you plugged into the full power of libvirt.  

 libvirt is quite quirky and does stipulate defaults but works quite well with qemu kvm.  I spend all my time troubleshooting it in xen which has lead to some bug submssions.  It's pretty complex. 

virt-manager you probably can do without from what you have written.  I have no idea how to avoid gnome packages.  There's another similar package that I can't remember offhand bit it probably does the same thing.

If you consider resolved could you insert [resolved] by your thread title.

----------

## dvh

I have used "virsh edit", but I have also just used vi to edit the .xml.  I had some strange behavior with virsh edit, where it would seem to complete the edits, but if I did a "cat" of the .xml, it looked like I had not made any changes.  sometimes it worked fine, and other times it did not.  I just chalked it up to me using the *tools* incorrectly.  maybe there is a real issue.

-dvh

----------

## newtonian

Had the same problem after using 

```
virsh domxml-from-native qemu-argv demo.args > myvm.xml
```

changing this:

```
    <driver name='qemu' type='raw'/> 
```

to this: 

```
    <driver name='qemu' type='qcow2'/> 
```

did the trick.

Here's my complete working KVM libvirt config for reference:

```
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

  <name>myvm</name>

  <uuid>90eb4382-5f3f-f852-f0bb-8f70cd7b3e2a</uuid>

  <memory>4182016</memory>

  <currentMemory>4182016</currentMemory>

  <vcpu>4</vcpu>

  <os>

    <type arch='x86_64'>hvm</type>

  </os>

  <features>

    <acpi/>

    <pae/>

  </features>

  <clock offset='utc'/>

  <on_poweroff>destroy</on_poweroff>

  <on_reboot>restart</on_reboot>

  <on_crash>destroy</on_crash>

  <devices>

    <emulator>/usr/bin/kvm</emulator>

    <disk type='file' device='disk'>

    <driver name='qemu' type='qcow2'/> 

      <source file='/mnt/images/myvm.img'/>

      <target dev='hda' bus='ide'/>

      <address type='drive' controller='0' bus='0' unit='0'/>

    </disk>

    <controller type='ide' index='0'/>

    <interface type='ethernet'>

      <mac address='00:00:00:00:21:78'/>

    </interface>

    <input type='mouse' bus='ps2'/>

    <graphics type='vnc' port='5900'/>

    <video>

      <model type='vga'/>

    </video>  

  </devices>

</domain>

```

Cheers,

----------

