RE: [libvirt] Using Xen config files
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@redhat.com] Sent: Wednesday, August 20, 2008 9:49 AM To: Matthew Donovan Cc: libvir-list@redhat.com 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
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/
On Wed, Aug 20, 2008 at 04:44:04PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 20, 2008 at 11:35:17AM -0400, Matthew Donovan wrote:
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?
Yep, that debug suggests the libvirt part of creation has completed OK. I think if anything is going wrong, its going to be in XenD's arena. I'd recommend looking in /var/log/xen for any further hints of trouble Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Daniel P. Berrange -
Matthew Donovan -
Richard W.M. Jones