On 8/30/2011 9:14 AM, Eric Blake wrote:
On 08/29/2011 08:09 PM, Kevins Thoughts 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
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.
