Found it! I added serial and console devices to the XML and it appears to be running. It's not working completely as expcted but it's doing more than it was. Thanks for your help. -matthew

-----Original Message----- From: Richard W.M. Jones [mailto:rjones@redhat.com] Sent: Wednesday, August 20, 2008 11:44 AM To: Matthew Donovan Cc: libvir-list@redhat.com Subject: Re: [libvirt] Using Xen config files

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>/u sr/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_cr ash><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/