On 8/30/2011 9:14 AM, Eric Blake wrote:
<clip>
1) The "-S" is keeping the system from booting This is intentional. Libvirt has to make some changes via the monitor, since qemu does not expose all functionality from the command line, so
On 08/29/2011 08:09 PM, Kevins Thoughts wrote: libvirt blindly starts qemu with -S, makes subsequent monitor changes, and then released the vcpus via monitor command (unless you used the VIR_DOMAIN_START_PAUSED flag to keep things paused). There is no XML to control this, nor does there need to be, given the existence of virDomainCreateWithFlags().
Alas, for whatever reason, the vcpus do not appear to be being released. XML below...
2) the "if=none" needs to be "if=virtio" Have you tried 'virsh domxml-from-native qemu-argv /path/to/args' for a shell-style command line containing the qemu command you want to run? It's not perfect, but may give you some hints on this regard.
No I haven't, thanks for that suggestion.
Meanwhile, according to the documentation,<target dev=... bus='virtio'/> inside your<drive> xml appears to be the right way to request a virtio drive. Paste the actual XML you are trying to use, so we can offer suggestions relative to your questions.
Actually, I did read the documentation and agree - at least that was my best guess, but its not working. The generated command being invoked has "-drive file=/kvms/test1.img,if=none,boot=on" specified. Here is the XML file created by the command: virt-install --name "Test" --ram 1024 --vcpus=2 --cpu host --description "Test VM" --import --file test1.img --os-type=linux --os-variant=virtio26 --network bridge=br0,model=virtio --graphics=none --autostart --prompt <Test.xml> <domain type='kvm'> <name>Test</name> <uuid>b0784171-0662-80ce-caad-c9e3c7fe0952</uuid> <description>Test VM</description> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>2</vcpu> <os> <type arch='x86_64' machine='pc-0.13'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <cpu match='exact'> <model>Opteron_G3</model> <vendor>AMD</vendor> <feature policy='require' name='skinit'/> <feature policy='require' name='vme'/> <feature policy='require' name='mmxext'/> <feature policy='require' name='fxsr_opt'/> <feature policy='require' name='cr8legacy'/> <feature policy='require' name='ht'/> <feature policy='require' name='3dnowprefetch'/> <feature policy='require' name='3dnowext'/> <feature policy='require' name='wdt'/> <feature policy='require' name='extapic'/> <feature policy='require' name='pdpe1gb'/> <feature policy='require' name='osvw'/> <feature policy='require' name='cmp_legacy'/> <feature policy='require' name='3dnow'/> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/kvms/test1.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <interface type='bridge'> <mac address='52:54:00:f3:28:7b'/> <source bridge='br0'/> <model type='virtio'/> <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> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> </domain>
Does the documentation help? http://libvirt.org/formatdomain.html#elementsNICS
Looks like I could perhaps add a "<target dev='tap5'/>" to the bridge interface section. The documentation refers to using "tun" devices, and I use "tap" devices, but perhaps that's close enough.