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/