On Wed, Aug 20, 2008 at 11:35:17AM -0400, Matthew Donovan wrote:
Thanks for the quick reply!
I set the LIBVIRT_DEBUG flag to 1 and ran it again. (The output is below.)
[...]
[root@grape ~]$ gcc -g virt_test.c -lvirt && ./a.out
DEBUG: libvirt.c: virInitialize (register drivers)
DEBUG: xen_internal.c: xenHypervisorInit (Using new hypervisor call: 30001
)
DEBUG: xen_internal.c: xenHypervisorInit (Using hypervisor call v2, sys ver3
dom ver5
)
DEBUG: libvirt.c: virConnectOpen (name=xen:///)
DEBUG: libvirt.c: do_open (name "xen:///" to URI components:
scheme xen
opaque (null)
authority (null)
server (null)
user (null)
port 0
path /
)
DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...)
DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 1 (QEMU) ...)
DEBUG: libvirt.c: do_open (driver 1 QEMU returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 2 (Xen) ...)
DEBUG: xen_unified.c: xenUnifiedOpen (Trying hypervisor sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated hypervisor sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Trying XenD sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated XenD sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Trying XS sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated XS sub-driver)
DEBUG: libvirt.c: do_open (driver 2 Xen returned SUCCESS)
DEBUG: libvirt.c: do_open (network driver 0 Test returned DECLINED)
DEBUG: libvirt.c: do_open (network driver 1 QEMU returned DECLINED)
DEBUG: remote_internal.c: doRemoteOpen (proceeding with name = xen:///)
DEBUG: libvirt.c: do_open (network driver 2 remote returned SUCCESS)
DEBUG: libvirt.c: do_open (storage driver 0 Test returned DECLINED)
DEBUG: libvirt.c: do_open (storage driver 1 storage returned DECLINED)
DEBUG: libvirt.c: do_open (storage driver 2 remote returned SUCCESS)
DEBUG: libvirt.c: virDomainDefineXML (conn=0x96fe478, xml=<domain
type='xen'><name>fc8.conf</name><os><type>hvm</type><loader>/usr/lib/xen/boo
t/hvmloader</loader><boot
dev='hd'/></os><memory>1024</memory><vcpu>1</vcpu><on_poweroff>destroy</on_p
oweroff><on_reboot>restart</on_reboot><on_crash>restart</on_crash><features>
<pae/><acpi/><apic/></features><clock
sync="localtime"/><devices><emulator>/usr/lib/xen/bin/qemu-dm</emulator><int
erface type='bridge'><source bridge='xenbr0'/><script
path='vif-bridge'/></interface><disk
type='block'><source
dev='/dev/vgvms/fc8'/><target dev='hda'/></disk><disk
type='block'
device='cdrom'><source dev='/dev/cdrom'/><target
dev='hdc'/><readonly/></disk><graphics
type='vnc'/></devices></domain>)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x96fe478, name=fc8.conf)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9702a18)
DEBUG: libvirt.c: virDomainCreate (domain=0x9702a18)
DEBUG: libvirt.c: virDomainGetInfo (domain=0x9702a18, info=0xbfa2b658)
state = 0
DEBUG: libvirt.c: virConnectClose (conn=0x96fe478)
DEBUG: hash.c: virUnrefConnect (unref connection 0x96fe478 xen:/// 2)
It certainly looks OK, and it seems like the domain should run after
virDomainCreate. Have you tried adding a delay of 30 seconds just to
check if the domain is starting up slowly?
Dan & Dan, any ideas?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat
http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/