[libvirt] Using Xen config files

[Richard W.M. Jones]

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 at 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/