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/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list