RE: [libvirt] Using Xen config files
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(a)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/