Thanks for the quick reply! I set the LIBVIRT_DEBUG flag to 1 and ran it again. (The output is below.) One other thing I can think to mention is that I'm using version 0.4.4-2, installed with yum. Maybe I should try compiling and installing from source? Thanks again! -matthew [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) > -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@xxxxxxxxxx] > Sent: Wednesday, August 20, 2008 9:49 AM > To: Matthew Donovan > Cc: libvir-list@xxxxxxxxxx > Subject: Re: [libvirt] Using Xen config files > > On Wed, Aug 20, 2008 at 08:35:46AM -0400, Matthew Donovan wrote: > > I am trying to programmatically start Xen guest VMs (HVM) > with libvirt (on > > Fedora Core 8) and I'm having some trouble with it. I've > included my code > > below. Essentially, the domain seems to get created > correctly but it > > doesn't seem to run. > > > > I don't receive any error messages from the libvirt > > functions but the VM does not get any CPU time (as shown > with "xm list"). > > > > [root@grape ~]$ xm list > > Name ID Mem VCPUs > State > > Time(s) > > Domain-0 0 1462 2 > r----- > > 1313.5 > > fc8.conf 7 128 1 > ------ > > 0.0 > > > > Can someone explain what I'm doing wrong here? I've tried > to get this > > working with linux and windows guests with the same results. > > That's really strange. Your program looks correct to me (but see my > comment about error handling below). One thing you can do is to run > your program after first setting the environment variable > LIBVIRT_DEBUG=1 which will cause all calls to libvirt to be printed > out. Just to make sure you are actually calling the functions that > you think you are calling. > > > I've seen references on this mailing list to libvirt's > ability to handle Xen > > configuration files but I haven't seen anything in the API > documentation or > > public header files that refer to it. Is there a public > interface to > > specifying a configuration file? > > No there isn't. This ability refers to old versions of Xen which used > /etc/xen. We have a driver that can parse files from here and present > those as inactive ("defined" but not running) domains, eg. when you > do "virsh list". > > For all other uses, use the libvirt XML configuration format. The > advantage is that it will keep working with other types of > virtualization. > > > domain = virDomainDefineXML (con, fedora); > > if (!domain) { > > virErrorPtr err = virGetLastError (); > > printf ("virDomainDefineXML failed: %s\n", > > err->message); > > By the way, this error reporting is wrong. Confusingly there are two > levels of errors stored by virterror, a global error and a > per-connection error. The global error is only used where you don't > have a virConnectPtr object (almost the only time is just after > virConnectOpen fails, when conn == NULL). The rest of the time you > should use virConnGetLastError: > > http://libvirt.org/html/libvirt-virterror.html#virConnGetLastError > > Rich. > > -- > Richard Jones, Emerging Technologies, Red Hat > http://et.redhat.com/~rjones > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://et.redhat.com/~rjones/virt-top > -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list