- Devel - libvirt List Archives

[Libvir] [PATCH] Fixed integer wraparound in python binding
by Daniel P. Berrange 15 Nov '06

15 Nov '06

The attached patch fixes a problem with integrate wraparound in the python bindings. THe problem is thus: - the memory & max-memory fields in the virDomainInfo struct are of type 'unsigned long'. - The python bindings, however, then stick this into a python 'Int' which is signed. Now, on 64-bit this is not an issue. For DomU guests on 32-bit it is not an issue either, but for Dom0 XenD sets the max-memory field to be 2^32-1 whcih causes wraparound when converting to python int. This patch simply switches the python binding over to using a python Long which is 64 bits on all platforms. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Support non-bridged network configs
by Daniel P. Berrange 15 Nov '06

15 Nov '06

The current code for parsing/serializing VIFs only really deals with the default bridged networking config for Xen. So if one uses network-route or network-nat it completely breaks. There is also no support for dealing with IP address in the XML / SEXPR. The attached patch fixes both of these issues, so we should be able to deal with any of the standard Xen networking configs. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Patch to attach/detach virtual devices on a running domain
by michel.ponceau＠bull.net 14 Nov '06

14 Nov '06

About your comments on virDomainXMLDevID() added in xml.c : 4/ For disks, it gets the target dev attribute, attached to a source either physical (if <disk type='block'>, <source dev=...>) or file (if <disk type='file'>, <source file=...>). Do you mean that it does not work in second case? 5/ In current xml.c (Libvirt-0.1.8), xs_directory() is directly accessed from virDomainGetXMLDevices() and virDomainGetXMLInterfaces(), xs_read() is directly accessed from virDomainGetXMLDeviceInfo(). Is this to be also changed, and "#include <xs.h>" removed from xml.c? Daniel Veillard <veillard(a)redhat.com> 14/11/2006 16:05 Veuillez répondre à veillard Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Patch to attach/detach virtual devices on a running domain On Tue, Nov 14, 2006 at 03:34:05PM +0100, michel.ponceau(a)bull.net wrote: > This patch adds to Libvirt-0.1.8 the two functions described in my > preceding mail. It has been tested in our Bull environment. There have been no negative comments to the interfaces proposed, so I guess we can assume that is okay, I'm still a bit vary of using XML for the Detach operation, but this avoid having to add the concept of device object at the API level right now, and keep things a bit simpler. Okay, here is a few remarks on the content of the patch: 1/ DOS end of lines in the patch, in general it's safer to do the diffs and code changes on a Unix box to avoid troubles :-) 2/ The public functions call directly the xenDaemon... implementation routines, that's not proper, everything need to go though the driver indirection, i.e. the driver structures need to be extended and the new functions need to be registered that way 3/ // type of code comments are banned in my code, sorry :-) 4/ virDomainXMLDevID() seems a bit weak, for example it seems to work only on disk registered though a physical device, though I think there is a need for (un)registering file based domU devices. For vif I wonder if the test on the mac address is really the only way to select the proper device, that's probably sufficient. 5/ virDomainXMLDevID does direct acces to xs_directory() and xs_read(), that's not proper it should not call xenStore directly that need to be cleaned up, define one high level function exported from xs_internal.[ch] and call that but no direct access should be done that leads to unmaintainable code. and a couple of tiny things left and right, which I can take care of. Basically 1/ 2/ 3/ are not blockers, I can fix those, for 4/ the limitations need at least to be documented, better fixed. 5/ really need to be fixed. I'm not against starting to work now to integrate that patch but I need 5 (and preferably 4/) to be fixed, if you agree I will work on the other points in parallel,

2 1

[Libvir] Conflict between libvirt 0.1.8 and Xen 3.0.3
by Philippe Berthault 14 Nov '06

14 Nov '06

There is a conflit between libvirt 0.1.8 and the latest release 3.0.3 of Xen. With Xen 3.0.3 release, the virsh vcpuinfo command (or virDomainGetVcpus API) always returns the 0 as physical CPU used by any vCPU. Example: #: xm vcpu-list VM1 Name ID VCPUs CPU State Time(s) CPU Affinity VM1 4 0 0 -b- 50.3 0 VM1 4 1 0 -b- 17.3 any cpu VM1 4 2 1 -b- 34.2 1 VM1 4 3 1 -b- 21.8 any cpu #: virsh vcpuinfo VM1 VCPU: 0 CPU: 0 ... VCPU: 1 CPU: 0 ... VCPU: 2 CPU: 0 ... VCPU: 3 CPU: 0 The same libvirt release 0.1.8 used with an older release of Xen gives a correct result. I currently investigate the problem but perhaps anyone has an idea of the origin of this problem.

2 1

[Libvir] announce: gnome-applet-vm 0.1.2
by Karel Zak 13 Nov '06

13 Nov '06

I have just pushed out a new 0.1.2 version of the VM Applet. The changes/features are: - removed dependence on dbus libs - improved collaboration with virt-manager (you have use the latest version of virt-manager) - fixed few minor bugs Web page: http://people.redhat.com/kzak/gnome-applet-vm/ TODO for next release(s): - finalize support for more hypervisors (the applet should be able to monitor cluster of VM machines on more hosts in same time) - alarm on important changes (domain create, destrory, ...) - keep track of important changes I welcome your feedback! Send me your comments, ideas for enhancements or bug reports. Karel -- Karel Zak <kzak(a)redhat.com>

1 0

[Libvir] Libvirt dependencies
by Karthik V 13 Nov '06

13 Nov '06

I'm trying to write a Java wrapper around some libvirt functions using Java Native Interface (JNI). To try this out, I tried writing JNI code that invokes the getDomainInfo() function in the example program info1.c (given with the distribution). While trying to execute the Java wrapper that invokes this C function, I encounter this error: Inconsistency detected by ld.so: dl-deps.c: 559: _dl_map_object_deps: Assertion`map->l_searchlist.r_list[0] == map' failed! I suspect this is due to some missing library that libvirt depends on. As part of the JNI code compilation, I'm supposed to create a shared library that includes all the dependent libraries. Currently, I'm using this command line to do that: ld -shared -f /usr/local/lib/libvirt.so -lxenstore -lpthread -lz LibvirtWrapper.o -o libjava-libvirt.so Here, I assume that libvirt.so and libxenstore are the only dependencies. Can someone tell me if I'm missing some other library in the above command line?

3 2

Re: [Libvir] First virConnectOpen() failed
by Glen Deem 10 Nov '06

10 Nov '06

Thanks, Daniel, I can see virsh nodeinfo (custom) passes now, but I still get the same error: when running under my user account: PASS: virshtest confdata/fc4.conf OK PASS: test_conf.sh First virConnectOpen() failed FAIL: reconnect when running as root: PASS: virshtest confdata/fc4.conf OK PASS: test_conf.sh First lookup for domain 0 failed FAIL: reconnect I suspect there is something wrong with my Xen installation. What to you think? Thanks, Glen Daniel Veillard wrote: > On Thu, Nov 09, 2006 at 03:41:55PM -0500, Glen Deem wrote: >> Hi all, >> >> I've compiled libvirt from the head, running tests failed with: >> >> first virConnectOpen() failed >> >> I've traced it to a failure of xs_daemon_open_readonly() that returns 0. > > it was a test problem when running as non-root, fixed in CVS yesterday :-) > > Daniel >

2 1

[Libvir] Failed to find domain 0 error
by Raja 10 Nov '06

10 Nov '06

Dear friends, i installed libvirt 0.1.8 on my xen 3.0.3 witout any trouble. I also installed the python bindings. I am able to run the python script (basic.py) to get information about domain0 but running info1 in examples in docs does not work. When i run it , i get " Failure to find domain0 "as output. I am running info1 in domain0. Why is this?. is this a bug?. Please help me. Thanks, Raja ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

2 1

[Libvir] virt-manager 0.2.6 release
by Daniel P. Berrange 10 Nov '06

10 Nov '06

I'm pleased to announce the 0.2.6 release of 'Virtual Machine Manager' aka 'virt-manager' is available for download: http://virt-manager.et.redhat.com/download.html The release focus has been on major bug fixing. This is also the first release in which (partial) translations are available for the UI in approximately 20 languages - thanks to the Fedora i18n team for excellant progress on this. It is now possible to control the virt-manager UI with command line arguments as well as the DBus API & DBus activation is no longer used by default which fixes interaction with GNOME keyring & AT-SPI accesibility. Numerous UI issues were fixed / clarified, particularly in the graphical console and new VM creation wizard. There are updated screenshots of the UI on the project website: http://virt-manager.et.redhat.com/screenshots.html As ever, report bugs against the 'virt-manager' component in the Red Hat Bugzilla server. Work is also underway to address the frequently requested feature of management for inactive domains. Since this is not supported by XenD on any current release we're aiming to add support for loading config files straight out of /etc/xen into libvirt & virt-manager. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] First virConnectOpen() failed
by Glen Deem 09 Nov '06

09 Nov '06

Hi all, I've compiled libvirt from the head, running tests failed with: first virConnectOpen() failed I've traced it to a failure of xs_daemon_open_readonly() that returns 0. What would be a problem, please? xend is running, I see dom0 and can create domUs etc... I use Debian unstable Xen packages. Thanks in advance, Glenn P.S. I'm not a Xen expert, kind of intermediate/advanced user.

2 1

[Libvir] compatibility issues
by Raja 07 Nov '06

07 Nov '06

Dear friends, i tried using libvirt on xen3.0 on a debian machine. When i invoked make, i got a lot of error messages. i went through some posts and i found out that libvirt was not compatible with certain versions of xen. I would like to know as to which versions of xen support libvirt so taht i can start working on them.. Thanks, Raja --------------------------------- Sponsored Link Talk more and pay less. Vonage can save you up to $300 a year on your phone bill. Sign up now.

2 1

[Libvir] Configure error - Could not find libxml2 anywhere
by Karthik V 07 Nov '06

07 Nov '06

Hi All, I'm new to libvirt, and am having trouble running configure script. This is the error - checking for library containing xs_read... -lxenstore checking libxml2 no ... checking for libxml2 libraries >= 2.5.0... checking libxml2 xml2-config ... configure: error: Could not find libxml2 anywhere (see config.log for details). I've verified that I have libxml2 installed - debian:~/libvirt-0.1.8# dpkg -l | grep libxml ii libxml2 2.6.16-7 GNOME XML library Can someone help me fix this problem? Thanks Karthik

2 6

[Libvir] virt-manager command line options
by Karel Zak 26 Oct '06

26 Oct '06

We need a way how call virt-manager methods without D-BUS. This patch adds new --show-* command line options. The --show-* options need to be used together with the --connect option. Daniel, I also added an OptionValueError exception. It's not perfect solution, but I'm not sure what's your favourite way for error messages in virt-manager when GTK is not initialized yet. # virt-manager --help usage: virt-manager.py [options] options: -h, --help show this help message and exit -c URI, --connect=URI Connect to hypervisor at URI --no-dbus Disable DBus service for controlling UI --show-domain-creator Create a new virtual machine --show-domain-editor=UUID Edit a domain configuration --show-domain-performance=UUID Show a domain performance --show-domain-console=UUID Show a domain console --show-host-summary Show a host summary Karel # HG changeset patch # User Karel Zak <kzak(a)redhat.com> # Node ID 3aab017160416137fe3033e13a206303287e5dd9 # Parent 127d61c9062e0ed5662f412f5edbb6c7dbd5582f add command line option diff -r 127d61c9062e -r 3aab01716041 src/virt-manager.py.in --- a/src/virt-manager.py.in Thu Oct 19 13:48:03 2006 -0400 +++ b/src/virt-manager.py.in Wed Oct 25 23:24:24 2006 +0200 @@ -70,7 +70,7 @@ dbus.glib.threads_init() dbus.glib.threads_init() import dbus.service -from optparse import OptionParser +from optparse import OptionParser, OptionValueError appname = "::PACKAGE::" appversion = "::VERSION::" @@ -102,21 +102,74 @@ from virtManager.remote import vmmRemote gtk.window_set_default_icon_from_file(icon_dir + "/" + appname + "-icon.svg") +# maps --show-* to engine methods +def show_engine(engine, show, uri, uuid): + if show=='creator': + engine.show_create(uri) + elif show=='editor': + engine.show_details_config(uri, uuid) + elif show=='performance': + engine.show_details_performance(uri, uuid) + elif show=='console': + engine.show_console(uri, uuid) + elif show=='summary' or uri: + engine.show_manager(uri) + else: + engine.show_connect() + +# maps --show-* to remote manager methods +def show_remote(managerObj, show, uri, uuid): + if show=='creator': + managerObj.show_domain_creator(uri) + elif show=='editor': + managerObj.show_domain_editor(uri, uuid) + elif show=='performance': + managerObj.show_domain_performance(uri, uuid) + elif show=='console': + managerObj.show_domain_console(uri, uuid) + elif show=='summary' or uri: + managerObj.show_host_summary(uri) + else: + managerObj.show_connect() + +# Generic OptionParser callback for all --show-* options +# This routine stores UUID to options.uuid for all --show-* options +# where is metavar="UUID" and also sets options.show +def opt_show_cb(option, opt_str, value, parser): + if option.metavar=="UUID": + setattr(parser.values, "uuid", value) + s = str(option) + show = s[s.rindex('-')+1:] + setattr(parser.values, "show", show) + # Run me! def main(): optParser = OptionParser() - optParser.add_option("-c", "--connect", dest="uri", help="Connect to hypervisor at URI", metavar="URI") - optParser.add_option("--no-dbus", action="store_true", dest="nodbus", help="Disable DBus service for controlling UI") + optParser.set_defaults(uuid=None) + optParser.add_option("-c", "--connect", dest="uri", + help="Connect to hypervisor at URI", metavar="URI") + optParser.add_option("--no-dbus", action="store_true", dest="nodbus", + help="Disable DBus service for controlling UI") + optParser.add_option("--show-domain-creator", action="callback", + callback=opt_show_cb, dest="show", help="Create a new virtual machine") + optParser.add_option("--show-domain-editor", type="string", metavar="UUID", + action="callback", callback=opt_show_cb, help="Edit a domain configuration") + optParser.add_option("--show-domain-performance", type="string", metavar="UUID", + action="callback", callback=opt_show_cb, help="Show a domain performance") + optParser.add_option("--show-domain-console", type="string", metavar="UUID", + action="callback", callback=opt_show_cb, help="Show a domain console") + optParser.add_option("--show-host-summary", action="callback", + callback=opt_show_cb, help="Show a host summary") (options, args) = optParser.parse_args() + + if options.show and options.uri==None: + raise OptionValueError("can't use --show-* options without --connect") config = vmmConfig(appname, appversion, gconf_dir, glade_dir, icon_dir) engine = vmmEngine(config) if options.nodbus: - if options.uri != None: - engine.show_manager(options.uri) - else: - engine.show_connect() + show_engine(engine, options.show, options.uri, options.uuid) else: bus = None try: @@ -135,19 +188,14 @@ def main(): managerProxy = bus.get_object("com.redhat.virt.manager", "/com/redhat/virt/manager") managerObj = dbus.Interface(managerProxy, "com.redhat.virt.manager") - if options.uri != None: - managerObj.show_host_summary(options.uri) - else: - managerObj.show_connect() + show_remote(managerObj, options.show, options.uri, options.uuid) + # yes, we exit completely now - remote service is in charge return except: logging.warning("Could not connection to session bus, disabling DBus service " + \ str(sys.exc_info()[0]) + " " + str(sys.exc_info()[1])) - if options.uri != None: - engine.show_manager(options.uri) - else: - engine.show_connect() + show_engine(engine, options.show, options.uri, options.uuid) gtk.main() if __name__ == "__main__":

2 1

[Libvir] Include actual error info in python exceptions
by Daniel P. Berrange 25 Oct '06

25 Oct '06

The current python bindings throw a generic libvirtError exception object whose message merely consists of the name of the method which failed. This isn't really all that useful to the caller, since they know exactly which method failed - its the one they just called! The attached patch adds a binding for virConGetLastError & virGetLastError & pulls this info into the libvirtError object being thrown. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Ensure errors are reported against virConnect object
by Daniel P. Berrange 25 Oct '06

25 Oct '06

In xend_internal.c there are a large number of places where errors are being reported without supplying an associated virConnectPtr object. So for example when calling virDomainCreateLinux, some errors get associated with the connection object, while others get attached to the global error object. The attached patch fixes up all places in xend_internal.c which have an virConnectPtr object available to always pass this object into the the error reporting funcs. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Make python binding release GIL when using threads
by Daniel P. Berrange 24 Oct '06

24 Oct '06

In the virt-manager app I'm using the python bindings to libvirt for all operations. For long running operations such as creating new domains, or saving/restoring domains I fork a background thread to do the call, so that the main UI / status refresh can carry on working. Except this wasn't working. The main thread was being blocked for the entire duration of the background thread. After a lot of nasty debug sessions I discovered that the main thread was being blocked in the GTK event loop attempting to aquire the Python GIL (Global Interpreter Lock). The only way this could be occurring is if the background thread doing the libvirt call held the GIL. And indeed after looking at the source for the libvirt python bindings it appears we never release the GIL when calling into the libvirt C apis, so for the entire duration of virDomainCreateLinux the python interpreter is completely stopped. Clearly this sucks because virDomainCreateLinux can take a very long time. I read up a little on python threading & looked at how PyGTK deals with this & have come up with a patch to make libvirt release the GIL when entering a C call & re-aquire it on completion. Indeed, since PyGTK & GTK are both LGPL, I just copied their C macros straight over. The patch appears to work - the python interpreter is no longer deadlocked when calling virDomainCreateLinux (or any other libvirt calls). Unfortuntely the virtmanager app still deadlocks, because it turns out XenD itself serializes all SEXPR HTTP requests, but once this is fixed the whole thing is fully parallelized & works without blocking the app. Attached the patch - I've not done much python threading before so let me know if i missed anything / messed stuff up. NB, I also hacked up the error handling callback so it re-acquires the lock before calling back into the python. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Release of libvirt-0.1.8
by Daniel Veillard 16 Oct '06

16 Oct '06

There have been a number of bug raised and fixed since the 0.1.7 release: * Bug for system with page size != 4k * vcpu number initialization (Philippe Berthault) * don't label crashed domains as shut off (Peter Vetere) * fix virsh man page (Noriko Mizumoto) * blktapdd support for alternate drivers like blktap (Daniel Berrange) * memory leak fixes (xend interface and XML parsing) (Daniel Berrange) * compile fix * mlock/munlock size fixes (Daniel Berrange) * improve error reporting The new package is available as usual at ftp://libvirt.org/libvirt/ thanks to everybody who helped by reporting or fixing bugs ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Potential problem on NUMA machines
by Philippe Berthault 13 Oct '06

13 Oct '06

In the virNodeInfo structure, it's assumed that all nodes of multiprocessor systems have the same number of sockets. But on NUMA machines, it's not mandatory that all SMP nodes have the same number of sockets. So there is a potential problem when computing the number of processors by using the informations returned in the virNodeInfo structure. This problem exists also in Xen (in the "xm info" command) but both Xen and libvirt are wrong.

2 1

[Libvir] virDomainGetInfo returns a false result on IA64 systems
by Philippe Berthault 12 Oct '06

12 Oct '06

The maxMem and memory fields of the virDomainInfo structure are false on IA64 systems. The problem is in xen_internal.c at lines 1530,1531: info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * 4; info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo) * 4; It's assumed that page size is 4 KB (* 4) but this isn't correct on a IA64 system where the page size is variable. I haven't checked but I suppose this bug exists also with the virDomainGetMaxMemory and virDomainSetMaxMemory functions. Regards.

3 4

[Libvir] Bug correction in virDomainGetVcpus() function
by Philippe Berthault 12 Oct '06

12 Oct '06

In the virXen_getvcpusinfo() function of xen_internal.c source file, the vcpu number stored in the virVcpuInfo structure is the xen domain id instead of the vcpu id. Here the patch of the correction. --- libvirt-0.1.7/src/xen_internal.c 2006-09-29 10:18:17.000000000 +0200 +++ libvirt-0.1.8/src/xen_internal.c 2006-10-12 11:29:40.000000000 +0200 @@ -1012,7 +1012,7 @@ ret = xenHypervisorDoV2Dom(handle, &op); if (ret < 0) return(-1); - ipt->number = id; + ipt->number = vcpu; if (op.u.getvcpuinfo.online) { if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING; if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED; @@ -1054,7 +1054,7 @@ ret = xenHypervisorDoV1Op(handle, &op); if (ret < 0) return(-1); - ipt->number = id; + ipt->number = vcpu; if (op.u.getvcpuinfo.online) { if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING; if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED; @@ -1078,7 +1078,7 @@ ret = xenHypervisorDoV0Op(handle, &op); if (ret < 0) return(-1); - ipt->number = id; + ipt->number = vcpu; if (op.u.getvcpuinfo.online) { if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING; if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED;

2 1

[Libvir] [PATCH] libvirt incorrectly reports crashed domains as shutoff
by Peter Vetere 11 Oct '06

11 Oct '06

Hi, I've noticed that libvirt seems to report crashed domains as shutoff. Here's an example: [root@XXXXX ~]# virsh list Id Name State ---------------------------------- 0 Domain-0 running 27 test03 blocked 34 test01 shut off 36 onetwentyeight blocked [root@XXXXX ~]# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 356 1 r----- 3655.4 onetwentyeight 36 128 1 -b---- 16.7 test01 34 256 1 ----c- 7.4 test03 27 256 1 -b---- 231.7 The reason is because xen_internal.c does not interpret the additional shutdown flags when it checks the domain's state. Attached is a patch which correctly checks these flags and reports the crashed state. I wasn't sure of the best way to react to the other shutdown flags, so I just defaulted to "SHUTOFF" for everything else. Pete

3 2

[Libvir] Supporting new Xen 3.0.3 blktap backend for file devices
by Daniel P. Berrange 06 Oct '06

06 Oct '06

When defining a guest's block device in the libvirt XML we currently allow the dev to be backed by either a file or block device in the host system. This is done by specifying the 'type' attribute when defing the block device XML. eg <disk type='file'> Or <disk type='block'> This is all fine & dandy for Xen 3.0.2, but in 3.0.3 we now have a choice of drivers for the 'file' backed block devices. We can either use the traditional loopback mounted system, or the new blktap system. To complicate things further still, blktap itself has man different drivers - one uses a raw file with Async-IO, another uses the QCow sparse format with AIO, and all sort of other possibilities are available... This means the easy option of just making all file devices use blktap in 3.0.3 is not practical. This in turns means we need to come up with a way to express the new driver methods in libvirt XML. There are a few options I can think of : - Allow more values in the 'type' attribute, eg file, block, blktap:aio, blktap:qcow, etc. This feels wrong because the blktap:* entries are really still 'file' types. - Introduce a new attribute 'driver' where you can specify 'loop', 'blktap:aio', 'blktap:qcow', etc - Introduce a new element 'driver' where you can specify the same <disk type="file"> <driver type='blktap:aio'/> </disk> - Same as above, but normalize the driver type further <disk type="file"> <driver type='blktap' backend='aio' /> </disk> My preference is probably option 3 or 4. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 7

Re: [Libvir] Xen Routed
by Daniel P. Berrange 04 Oct '06

04 Oct '06

On Wed, Oct 04, 2006 at 08:09:27AM -0600, Nick Devito wrote: > On Wed, 2006-10-04 at 14:06 +0100, Daniel P. Berrange wrote: > > On Tue, Oct 03, 2006 at 07:15:23PM -0700, Sargun Dhillon wrote: > > > Does the XML file format support routed? > > > If so, what would the <interface> clause look like? > > > > I'm not familiar with the way routed networking is setup with Xen. If you > > can provide the example VIF device config params from /etc/xen/<some guest> > > which are needed for routing I'll check if they map through to libvirt > > XML format in neccessary manner. > > > Xen routed requires the ip= configuration variable, and, I think thats > it. I don't see any reason why it shouldn't work correctly. Ok, looking at the XML parsing routines we don't currently support the 'ip' property. Fortunately, it looks as if one of Michel Ponceau's patches from a thread last week ought to solve this problem, so we ought to be able to get this working for next release. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Xen Routed
by Sargun Dhillon 04 Oct '06

04 Oct '06

Does the XML file format support routed? If so, what would the <interface> clause look like? -- Sargun Dhillon President Atarack Communications, Inc. (925)-202-9485

2 1

[Libvir] Problem with hypercall
by Jim Fehlig 02 Oct '06

02 Oct '06

Stumbled across a problem trying to list domains with libvirt-0.1.5. Using virsh I get errors such as xen81:/tests/jim # virsh list Id Name State ---------------------------------- 0 Domain-0 running libvir: Xen Daemon error : GET operation failed: No such domain 16 xm shows xen81:/tests/jim # xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 2048 4 r----- 815825.8 vm1 1 512 2 -b---- 0.3 I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST hypercall differs slightly from the buffer in xen/dom0_ops.h. Attached is a patch against current cvs that works for me, but I'm not familiar with this part of the code so not sure if this is the proper fix. I'm using xen 3.0.2 that shipped with SLES10. Regards, Jim

3 8

[Libvir] Proposal for virtual devices described in XML
by michel.ponceau＠bull.net 02 Oct '06

02 Oct '06

Proposal modified after comments from Daniel P. Berrange: /* Create a virtual device attachment to backend */ int virDomainAttachDevice(virDomainPtr domain, char *xml); /* Destroy a virtual device attachment to backend */ int virDomainDetachDevice(virDomainPtr domain, char *xml); /* @domain: pointer to domain object * @xml: pointer to XML description of one device * Returns 0 in case of success, -1 in case of failure. */ The XML would be in same form as the part of domain description for a single device, either <disk.../disk> or <interface.../interface>. In Detach function, the device is identified by its target name for "disk", and its MAC address for "interface". When the MAC address has not been assigned by Libvirt user at device creation, it must be retrieved from Xen using virDomainGetXMLDesc function.

1 0

[Libvir] Release of libvirt-0.1.7
by Daniel Veillard 29 Sep '06

29 Sep '06

Is available on ftp://libvirt.org/libvirt/ It's 0.1.6 with the fixes for the 2 bugs that Daniel Berrange fixed yesterday: - failure of domain info when using the hypervisor on 32 bits with 3.0.3 - the memory corrption which can happen when reading vCPU info from xend Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

Re: [Libvir] Proposal for virtual devices described in XML
by michel.ponceau＠bull.net 28 Sep '06

28 Sep '06

When specified at device creation, vifname is put in XenStore directory /local/domain/0/backend/vif/<domID>/<vif_number>. All vifnames used in a domain are returned by Get "/xend/domain/<domID>?detail=1" and converted into XML "target" by virDomainGetXMLDesc. For convenience, we could force the vifname, either at domain creation or in Attach, and ignore any "target" in "interface", except for Detach. The vifname value could be the sequence number of network device creation in domain (for Xen, it would be equal to vif number). Veuillez répondre à "Daniel P. Berrange" <berrange(a)redhat.com> Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Proposal for virtual devices described in XML On Wed, Sep 27, 2006 at 05:21:33PM +0200, michel.ponceau(a)bull.net wrote: > After comments from Daniel P. Berrange and from Bull people, my proposal > is reduced to following 2 functions: > > /* Create a virtual device attachment to backend */ > int virDomainAttachDevice(virDomainPtr domain, char *xml); This is definitely a good way forward - it lets us re-use the existing code for parsing device descriptions very easily. > /* Destroy a virtual device attachment to backend */ > int virDomainDetachDevice(virDomainPtr domain, char *xml); > /* @domain: pointer to domain object > * @xml: pointer to XML description of one device > * Returns 0 in case of success, -1 in case of failure. */ I was wondering whether we need to have the full XML block passed in for detaching devices. Perhaps it is sufficient to just pass i nthe target name of the device. Then again, some implementations may prefer to have the full XML blob available to allow greater sanity checking when detaching, so its probably worth while. > The XML would be in same form as the part of domain description for a > single device, either <disk.../disk> or <interface.../interface>. Very nice. > The device is identified by its target name. This attribute is optional > for "interface" in domain description, but would become mandatory in > Attach/Detach description. It is not yet processed in Libvirt-0.1.6 source > xml.c (function virDomainParseXMLIfDesc). I have successfully tried the attached patch, which tranlates "target" > into Xen "vifname". (It processes "ip" attribute in same way, but my try > failed, maybe because address value was invalid for Xen). I'm not sure I like the idea of having to explicitly set a vif name for every guest NIC we define - principally because there's no straightforward way for a user of this API to determine what VIF names are already in use, vs free. It also seems XenD does not tell us what the vifname for running domains are - although I think the info is in xenstore somewhere. I can see why we need the vifname to detach the device though. If we can find a way to fill in the vifname when dumping the XML, then this would let a caller uniquely identify an existing device, without us requireing that vifnames are used when creating a domain/attaching a new device (& thus let Xen still auto-allocate them) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Proposal for virtual devices described in XML
by michel.ponceau＠bull.net 28 Sep '06

28 Sep '06

My try of "ip" attribute failed because of a bug in patch. With this corrected file, it works as well as "target". Pour : libvir-list(a)redhat.com cc : Objet : Proposal for virtual devices described in XML After comments from Daniel P. Berrange and from Bull people, my proposal is reduced to following 2 functions: /* Create a virtual device attachment to backend */ int virDomainAttachDevice(virDomainPtr domain, char *xml); /* Destroy a virtual device attachment to backend */ int virDomainDetachDevice(virDomainPtr domain, char *xml); /* @domain: pointer to domain object * @xml: pointer to XML description of one device * Returns 0 in case of success, -1 in case of failure. */ The XML would be in same form as the part of domain description for a single device, either <disk.../disk> or <interface.../interface>. The device is identified by its target name. This attribute is optional for "interface" in domain description, but would become mandatory in Attach/Detach description. It is not yet processed in Libvirt-0.1.6 source xml.c (function virDomainParseXMLIfDesc). I have successfully tried the attached patch, which tranlates "target" into Xen "vifname". (It processes "ip" attribute in same way, but my try failed, maybe because address value was invalid for Xen).

1 0

[Libvir] virDomainDestroy not synchronous?
by Lon Hohberger 28 Sep '06

28 Sep '06

i686 libvirt-0.1.5-3 xen-3.0.2-33 Code: domain_desc = virDomainGetXMLDesc(vdp, 0); response = virDomainDestroy(vdp); if (response == 0 && domain_desc) { /* sleep(3); */ virDomainCreateLinux(vp, domain_desc, 0); free(domain_desc); } If I add the 'sleep()', the domain dies and virDomainCreateLinux() fails with the following error: libvir: Xen Daemon error : POST operation failed: No such domain futon1 Failed to get devices for domain futon1 That really doesn't bother me, and it's likely my fault anyway (it's not a fully configured domain; it's a dom-U sitting in the anaconda install screen). Of course, it's moot if we get a guaranteed synchronous reboot flag for virDomainReboot()... hint hint ;) What bothers me is that if I *don't* put the sleep in, the domain never actually gets destroyed. In this particular case, the domain is still sitting at the anaconda install screen; all I have to do is reconnect using xm console. If I only do a virDomainDestroy(), the domain gets destroyed. So, it looks like like the virDomainCreateLinux() cancels the destroy request before it can be completed. This makes it look like that the destroy request is not synchronous, and/or the result of the operation is not guaranteed (only that the request was made). Is it supposed to work this way, or is this a bug/problem? -- Lon

4 7

[Libvir] Proposal for virtual devices described in XML
by michel.ponceau＠bull.net 27 Sep '06

27 Sep '06

After comments from Daniel P. Berrange and from Bull people, my proposal is reduced to following 2 functions: /* Create a virtual device attachment to backend */ int virDomainAttachDevice(virDomainPtr domain, char *xml); /* Destroy a virtual device attachment to backend */ int virDomainDetachDevice(virDomainPtr domain, char *xml); /* @domain: pointer to domain object * @xml: pointer to XML description of one device * Returns 0 in case of success, -1 in case of failure. */ The XML would be in same form as the part of domain description for a single device, either <disk.../disk> or <interface.../interface>. The device is identified by its target name. This attribute is optional for "interface" in domain description, but would become mandatory in Attach/Detach description. It is not yet processed in Libvirt-0.1.6 source xml.c (function virDomainParseXMLIfDesc). I have successfully tried the attached patch, which tranlates "target" into Xen "vifname". (It processes "ip" attribute in same way, but my try failed, maybe because address value was invalid for Xen).

2 1

[Libvir] Flag to virDomainReboot to immediately reboot a domain?
by Lon Hohberger 22 Sep '06

22 Sep '06

Hi, For fencing Xen domains, I would like the ability to guarantee an immediate reboot of a domain without notifying the OS inside. Basically, I would like something equivalent to pressing the reset button on a physical machine. There's a currently unused "flags" option to virDomainReboot which would allow such an addition without breaking the ABI. Doing getXMLDesc/Destroy/Create introduces a race condition in clusters: What if outside management software notices notices the VM is missing and decides to start it up on *another* host node before we bring up the VM again using the Create call? An immediate reboot should eliminate the race (even though it's a very small window), and probably will not add any complexity. For now, 'reboot' is done as above, and 'off' is a simple Destroy call. 'On' is not possible to implement for various reasons, the most obvious of which is that the caller does not know any of the configuration information about particular domUs (except for their names). -- Lon

1 0

[Libvir] Release of libvirt-0.1.6
by Daniel Veillard 22 Sep '06

22 Sep '06

Available at ftp://libvirt.org/libvirt/ Mostly a few bug fixes, preparing the upcoming xen-3.0.3, and localization support were added in the last 2 weeks: * Support for localization of strings using gettext (Daniel Berrange) * Support for new Xen-3.0.3 cdrom and disk configuration (Daniel Berrange) * Support for setting VNC port when creating domains with new xend config files (Daniel Berrange) * Fix bug when running against xen-3.0.2 hypercalls (Jim Fehlig) * Fix reconnection problem when talking directly to http xend thanks to everybody who helped testing, improving and fixing it ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] gettext i18n support for libvirt
by Daniel P. Berrange 21 Sep '06

21 Sep '06

Attached is an updated version of my previous patch to add gettext support to libvirt. It should be pretty self-explanatory - basically wrapping all strings with _(..) or gettext_noop(...) where appropriate. I also took the opportunity to make some of the messages more consistent with each other. (To cut down size, I'm not including the actual libvirt.pot file ) Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 5

[Libvir] problem with virConnectClose in libvirt 0.1.5
by Philippe Berthault 21 Sep '06

21 Sep '06

After closing libvirt with virConnectClose, it's possible to open libvirt again in the same program with virConnectOpen but following operations on domains systematically fail. In example: conn = virConnectOpen(NULL); dom = virDomainLookupByID(conn, id); virDomainFree(dom); virConnectClose(conn); ... conn = virConnectOpen(NULL); dom = virDomainLookupByID(conn, id); ==> ERROR The second virDomainLookupByID call fails because of the do_connect() function in xend_internal.c source file. In this function, the connect() API returns ENOENT on the second virDomainLookupByID() call. ENOENT return code isn't documented in the man of connect API ! I suppose that some cleaning are missing when virConnectClose is called or in the opposite, too cleaning is done. Regards.

2 2

[Libvir] New style CDROM config in Xen 3.0.3
by Daniel P. Berrange 14 Sep '06

14 Sep '06

So in a recent change to xen-unstable.hg the way CDROM devices are configured for HVM guests changed. They are now treated as regular IDE devices, and a CDROM is signified by presence of ':cdrom' suffix on the device name http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00369.html libvirt obviously needs to support both this new style config, and the old (<= 3.0.2) style configs. Thus I requested addition of 'xend_config_format' attribute in the /xend/node SEXPR data from XenD. Christian recently committed this patch, so we can now support both CDROM style configs in libvirt. I am attaching a patch to implement this support - basically it touches xend_internal.c to fix XML->SEXPR conversion, and xml.c to fix SEXPR->XML conversion. Then this is corresponding additions to the unit tests to validate the new code, and also validate that I didn't break existing code. I am attaching the patches, but I don't intend to commit them to libvirt just yet because I don't actually have the new 3.0.3 xend running on my test systems fully yet. If anyone is using 3.0.3 any testing would be appreciated, otherwise I aim to test this towards end of next week. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 2

[Libvir] Configuration and building libvirt.
by Michel Gauthier 13 Sep '06

13 Sep '06

We want to configure and build libvirt library (0.1.4 for instance) from tar.gz file on a IA32 platform with RHEL4U2 distro without installing and build all Xen modules. The steps are the following: tar -xzvf libvirt-0.1.4.tar.gz cd libvirt-0.1.4 ./configure --prefix=/usr make make install Unfortunatly, the "./configure --prefix=/usr " aborts with: checking for library containing xs_read... no configure: error: Xen store library not found (see attached file) corresponding to lines: dnl search for the Xen store library AC_SEARCH_LIBS(xs_read, [xenstore], [], [AC_MSG_ERROR([Xen store library not found])]) in the configure file. We have then transfered the libxenstore.so file into /usr/lib directory of our machine, but the result is the same. (NB: We had previously transferred all Xen public C header files into /usr/include/xen directory) 1- Could you tell us what are the Xen files strictly necessary to achieve this operation? 2- Is this operation also possible with a IA64 building environment on our IA32 platform? Regards.

3 2

[Libvir] [PATCH] Support setting vnc port
by Jeremy Katz 12 Sep '06

12 Sep '06

We display the vncport, but never used it when creating the Xen sexpr. Attached fixes that. It also adds support for "port=-1" implying "use the first unused port"[1] Jeremy [1] The xen and qemu "vncunused" parameter

2 2

[Libvir] Proposal for virtual devices
by michel.ponceau＠bull.net 07 Sep '06

07 Sep '06

I previously made a proposal for block devices. It was rejected because it was VBD-specific and Xen-specific. Here is a proposal for transparent interface with Xen or other. The virtual device attributes (VDA) are transferred from/to application without considering their meaning, except backend domain, previously requested to be the name for user, while it is the ID for Xen. typedef struct virVDA { /* virtual device attribute */ char name[16]; char value[64]; } virVDA; int virDomainGetVdevs(virDomainPtr domain, char *type, virVDA *attr, int maxattr); * @type: pointer to device type, "disk", "network" ... * @attr: pointer to an array of virVDA structures * @maxattr: number of structures in attr array * Return: (number of VDAs per device)<<16 + (number of devices), if success; * -1 if failure. For "disk" type, Xen provides the following VDA names: "virtual-device" (virtual device number) "backend-id" (backend domain ID) "state" "backend" (backend device or file) "ring-ref" "event-channel" This function changes "backend-id" to "bkdom-name" and translates value ID into name. int virDomainCreateVdev(virDomainPtr domain, char *type, virVDA *attr, int nbattr); * @type: pointer to device type, "disk", "network" ... * @attr: pointer to an array of virVDA structures * @nbattr: number of structures in attr array For "disk" type, Xen requires the following VDA names: "uname" (backend device, value either "phy:<>" or "file:<>" "dev" (virtual device number) "mode" (value "ro" for read-only, or "rw" for read/write) "backend" (backend domain ID) This function translates "backend" user value (name) into ID. int virDomainDestroyVdev(virDomainPtr domain, char *type, char *ref); * @type: pointer to device type, "disk", "network" ... * @ref: pointer to virtual device reference (number for Xen...)

2 1

[Libvir] libvirt-0.1.5 release
by Daniel Veillard 05 Sep '06

05 Sep '06

With the recent Xen hypervisor breakage, I think it was urgent to push a new release for testing even if some parts are still in development and not finished. So expect a new release in a couple of weeks. In the meantime 0.1.5 is available at: ftp://libvirt.org/libvirt/ * Support for new hypercalls change in Xen changeset 86d26e6ec89b * bug fixes: - virParseUUID() was wrong, netwoking for paravirt guests (Daniel Berrange) - virsh on non-existent domains (Daniel Berrange) - string cast bug when handling error in python (Pete Vetere) - HTTP 500 xend error code handling (Pete Vetere and Daniel Berrange) * improvements: - test suite for SEXPR <-> XML format conversions (Daniel Berrange) - virsh output regression suite (Daniel Berrange) - new environ variable VIRSH_DEFAULT_CONNECT_URI for the default URI when connecting (Daniel Berrange) - graphical console support for paravirt guests (Jeremy Katz) - parsing of simple Xen config files (with Daniel Berrange) - early work on defined (not running) domains (Daniel Berrange) - virsh output improvement (Daniel Berrange) Thanks for everyone who helped out, please check that everything is working with the new hypervisor code, I could not test all entry points, I am on the road ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] [Patch 3/4]: Xen inactive domains: stop xend/xs/xen using inactive domains
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The existing xend, xs, xen, proxy driver backends all assume that if they're given a virDomainPtr object, the handle member is non-zero (ie its a running domain). With the addition of inactive domain support this assumption is no longer value. Thus this patch modifies all these drivers, so that if the handle is -1, then they return without doing any work. This lets the operation be correctly delegated to the new driver for inactive domains. In addition, the XenD driver assumed that if XenD returns a 404 when looking up a domain based on its name, this was a fatal error condition. Since inative domains are not known to XenD, this assumption is also now false. The attached patch modifies xend_internal so that if a 404 is returned, the error is not propagated to the libvirt error handlers. Instead the methods in question simply return -1, and control continues to the new backend for managing inactive domains. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] [Patch 2/4]: Xen inactive domains: hash file
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The management of inactive domains uses the hashtable APIs for managing its list of config files. In doing so it needed some extra capabilities. This patch adds 3 new routines: - virHashForEach - iterate over all values in the hashtable invoking a callback for each one. Modifying the hashtable from the callback is forbidden, or bad stuff will happen. - virHashRemoteSet - iterate over all values in the hashtable invoking a callback for each one. If the callback returns non zero, the element will be removed. - virHashSearch - iterate over all values in the hashtable invoking a callback for each one. The first entry for which the callback returnbs non-zero will be returned. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] [Patch 1/4] Xen inactive domains: config file APIs
by Daniel P. Berrange 04 Sep '06

04 Sep '06

This patch adds an extra API to the config file management API. This API lets you add a new config parameter to the file. Previously you could only modify existing values, not define extra ones. It also exposes an API for creating a new empty config file record, which is needed if you're creating a brand new config file, rathre than processing an existing one. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] [Pach 4/4]: Xen inactive domains: new XM driver
by Daniel P. Berrange 04 Sep '06

04 Sep '06

This patch adds a new driver xm_internal.c which manages inactive domains whose config files are found in /etc/xen. On certain operations the driver will scan /etc/xen for new domains - the scanning is throttled to only occur at most every 10 seconds. When scanning any new domains are loaded into memory, and any domains deleted off disk are removed. This driver can start new domains, define domains, get/set memory, max memory, vcpus, can dump XML, and list inactive domains. The list of inactive domains is filtered to remove any domains which are running. This driver is still work in progress. There is more work needed to report error exact conditions via libvirt error APIs, and the code for serializing from XML -> XM config file is not yet complete. The code for serializing from XM config files into XML is pretty much complete although needs more testing. All the APIs can be tested via the commands added to virsh for inactive domains last week. eg list --inactive, start, define, undefine I'll post another update of this patch tomorrow which should be more complete Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] [Patch 0/4] Xen inactive domain
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The following series of patches add support for managing inactive domains with Xen. Based on DV's recent xm config file reader, it processes all domains in /etc/xen (skipping known bogus files, xmexmaple*, xend-config.sxp). It can do all the operations you'd expect for managing inactive domains. Create a new domain, start a domain, list domains, delete a domain, change cpu / memory, get XML for domain. The impact on existing driver backends is very small - the only place which needed changing is the XenD code which lookups existing domains - making it be quiet if it get s a 404 error from XenD - this is to be expected if the domain is inactive. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Semantics for ListDomains/ ListDefinedDomains
by Daniel P. Berrange 03 Sep '06

03 Sep '06

So I was thinking a little about lifecycle support for passive domains in libvirt and wanted to clarify the intended semantics of the two methods: virConnectListDomains virConnectListDefinedDomains Am I correct in thinking that virConnectListDefinedDomains will list a domain if-and-only-if its state == 'shutoff', and that virConnectListDomains will list a domain if-and-only-if its state != 'shutoff' ie, when I start a defined domain with 'virDomainCreate', it will be removed from the 'ListDefinedDomains' set and added to the 'ListDomains' set. Likewise when shutting down it'll move back the other way. Or will the virConnectListDefinedDomains call always list a domain with a config file, even if it is running ? I realize this is a little hypothetical since XenD doesn't have lifecycle management yet, but it matters to the test backend, and any potential QEMU / UML backend, and the future XenD XML-RPC backend Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

4 9

[Libvir] Libvirt / Xen incompatible versions.
by Michel Gauthier 01 Sep '06

01 Sep '06

We've just installed the last advanced version of Xen on our IA64 platform. Unfortunatly, the build of the 0.1.4 version of libvirt with this version of Xen is not successful. The C header file of Xen /usr/include/xen/dom0_ops.h used by libvirt in xen_internal.c has been modified. The dom0_getdomaininfo_t structure is no more decared in this header file. Are you aware of this problem? What is the latest version of Xen on which libvirt has been successfully built and tested? Thanks.

2 1

[Libvir] [QEMU 3/3] the qemu driver & daemon
by Daniel P. Berrange 31 Aug '06

31 Aug '06

Attached is the patch for the qemu driver & daemon process Since there is no scalable way to determine active standalone QEMU instances, or access their monitor connection, the backend implements a management daemon - called 'qemud' - which takes care of managing the complete lifecycle of QEMU virtual machines. The libvirt driver is a thin shim which talks to qemud via a UNIX domain socket - the wire protocol is modelled after the protocol used for libvirt_proxy, but obviously contains alot more functions since its full read/write, not just read-only. There is intended to be one qemud instance per UNIX user - the so called 'session' instance, and optionally one system global instance runing as root (or a system daemon account?) - the so called 'system' instance. When using libvirt, the URIs for each are 'qemu:///session' and 'qemu:///system' respectively. The UNIX socket for session instances is $HOME/.qemud and is chmod 0700 - no support is provided for users connecting to each other's instances. Although we could trivially extend to create a read-only socket $HOME/.qemud-ro if desired. The system instance is currently not finished but intended to run in /var/run/qemud or some such. The backend code is in src/qemu_internal.h, src/qemu_internal.c, the daemon code is in qemud/* with qemud/protocol.h defining the network wire protocol. This latter header file is also included by src/qemu_internal.c - qemud.c - the main daemon management code - handles all network I/O and forking / cleanup of QEMU processes. The implementation is poll() based & completely non-blocking. All requests/replies from a single client are, however, serialized. - dispatch.c - takes care of serializing/de-serializing requests/replies from/to libvirt - called from qemud.c when a complete message is available. - driver.c - the implementation of each request from libvirt - called from dispatch.c - config.c - manages reading & writing of XML files for inactive domains in the $HOME/.qemud.d/*.xml. Also takes care of generating a suitable command line for execing qemu. In terms of hardware, there is support for - harddisk - floppy, cdrom, harddisk - graphics - VNC - memory - virtual CPUs In particular no support for - networking - sound - non-native CPU types - boot order But its enough to demonstrate the practice. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 5

[Libvir] Added gettext translation support
by Daniel P. Berrange 31 Aug '06

31 Aug '06

The attached patch adds support for translating all text strings in libvirt and virsh using gettext. It also fixes up many error messages, and updates others to use a consistent style - so we don't have lots of slightly differenet translations of the same thing. It also adds an 'autoclean.sh' which deletes all autotools generated junk so you can more easily generate useful patches using diff against a pristine source tree. The patch adds a placeholder en_GB.po file (with no changes). It is expected that real translations for a large number of languages will be completed over course of next couple of months Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] [QEMU 2/3] add commands for inactive domains to virsh
by Daniel P. Berrange 30 Aug '06

30 Aug '06

The attached patch adds new commands to virsh, and modifies the list command. * 'list' is given two additional parameters '--inactive' to tell it to list inactive instances, instead of active instances, and --all to tell it to list both active & instance domains. NB inactive domains will show with an ID of -1 and state 'shut off'. * 'define' defines an inactive domain - instructing the backend to save the XML definition in some persist location. The domain is not started. * 'undefine' removes an inactive domain - the persist config file managed by the backend is deleted. The domain must not be running when this is run. * 'start' starts up an inactive domain which was previously defined via the 'define' command. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 5

[Libvir] [QEMU 1/3] hook up driver methods for inactive domains
by Daniel P. Berrange 30 Aug '06

30 Aug '06

The attached patch prepares the driver method API to support inactive domains. The following methods are hooked up: * virConnectListDefinedDomains * virConnectNumOfDefinedDomains * virDomainDefineXML * virDomainUndefine * virDomainCreate It sets all existing drivers to have NULL in these fields. The existing code in virDomainDefineXML was ripped out since it was found to be more trouble than it was worth - the backend driver needed to repeat most of the logic anyway - so better just to delegate the whole lot. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 3

[Libvir] generator.py -- why?
by pvetere＠redhat.com 29 Aug '06

29 Aug '06

Hi all. So, I found a bug in the python bindings that I'd really like to fix, but when I sat down to do so I quickly found myself mired in a swampy mess of code generation: generator.py. :-) Now, I feel compelled to ask -- why don't we just have a static libvirt.py file that is WYSIWYG? The generator.py program alone is longer than the file it generates, and having a static file would not only make the code easier to read, but would also make bug fixing much simpler. But, I'm sure there's got to be a good reason for it. :-) Here's a program that produces the bug I tried to address: import libvirt def get_domain(dom_name): conn = libvirt.openReadOnly(None) domain = conn.lookupByName(dom_name) return domain d = get_domain("mydomain") print d.info() This is a fairly typical "factory" pattern I could imagine people using. The problem is that the connection object falls out of scope after the get_domain routine ends, and is therefore garbage collected. This leaves the "d" domain object with no valid connection, resulting in a "libvir: Xen error : failed Xen syscall ioctl 3166208" error. The simple solution would be for the connection object to pass a reference to itself into each domain object it creates. The domain objects would then maintain the reference until they are destroyed. I valiantly tried to follow the table-based patterns used in generator.py to fix this problem, but I found myself inventing somewhat arbitrary rules just to force the code I wanted it to output. And hence, $SUBJECT. :-) Pete

4 7

[Libvir] [QEMU 0/3] QEMU support for libvirt
by Daniel P. Berrange 28 Aug '06

28 Aug '06

The following series of patches add support for QEMU to libvirt. The patches are: - libvirt-drivers-qemu.patch - hook up methods for inactive domains - libvirt-virsh-qemu.patch - hook up inactive domain methods to virsh - libvirt-backend-qemu.patch - the main QEMU backend The patches will be explained further in each email which follows. NB, the first two patches are ready for inclusion, but the last one needs more error handling, and another audit of the networking code to check in particular buffer sizes. For testing I used Damn Small Linux, and QEMU 0.8.1 from Fedora Core 5 (the one with VNC support) wget http://distro.ibiblio.org/pub/linux/distributions/damnsmall/current/dsl-3.0… Here is a suitable config file: <domain type='qemu'> <name>dsl</name> <uuid>fff64701-45b9-11cb-88e3-afbfe5370493</uuid> <memory>131072</memory> <vcpu>20</vcpu> <devices> <disk type='file' device='cdrom'> <source file='/home/berrange/dsl-3.0.1.iso'/> <target dev='hdc'/> </disk> <graphics type='vnc' port='5906'/> </devices> </domain> An example session with virsh: [berrange@aubergine ~]$ export VIRSH_DEFAULT_CONNECT_URI=qemu:///session [berrange@aubergine ~]$ virsh list Id Name State ---------------------------------- [berrange@aubergine ~]$ virsh define $HOME/dsl.xml Domain dsl defined from /home/berrange/dsl.xml [berrange@aubergine ~]$ virsh list --all Id Name State ---------------------------------- -1 dsl shut off [berrange@aubergine ~]$ virsh dominfo dsl Id: -1 Name: dsl UUID: fff64701-45b9-11cb-88e3-afbfe5370493 OS Type: linux State: shut off CPU(s): 20 Max memory: 131072 kB Used memory: 131072 kB [berrange@aubergine ~]$ virsh start dsl Domain dsl started [berrange@aubergine ~]$ virsh list --all Id Name State ---------------------------------- 1 dsl running [berrange@aubergine ~]$ virsh dumpxml dsl <domain type='qemu' id='1'> <name>dsl</name> <uuid>fff64701-45b9-11cb-88e3-afbfe5370493</uuid> <memory>131072</memory> <vcpu>20</vcpu> <devices> <disk type='file' device='cdrom'> <source file='/home/berrange/dsl-3.0.1.iso'/> <target dev='hdc'/> <readonly/> </disk> <graphics type='vnc' port='5906'/> </devices> </domain> [berrange@aubergine ~]$ virsh destroy dsl Domain dsl destroyed [berrange@aubergine ~]$ virsh list --all Id Name State ---------------------------------- -1 dsl shut off I'm also happy to report that it is also possible to use virt-manager with the QEMU support - just enter qemu:///session as the URI. That said you can't use the VM creation wizard, but it should be easy to hook that up. The fact that virt-manager works without modification is a really great proof of the value of libvirt abstract driver backend API concept - validating the decision not to make a Xen specific API. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Support graphical console for PV Xen guests
by Jeremy Katz 26 Aug '06

26 Aug '06

With the paravirt framebuffer patches for Xen, we can support having a graphical console for PV as well as HVM guests. The attached adds support to libvirt by breaking out the <graphics> parsing into its own function that can be used by both PV and HVM guests. It also adds support for looking at the appropriate sexpr for the vnc/sdl console for PV guests. One thing that is potentially not okay is that I've changed sexpr_node to take a format string instead of just a const char *, but since it's not public API and doesn't actually change anything for callers I think it should be fine. If not, let me know and I can change it. Jeremy

2 3

[Libvir] RFC: A more convenient 'virsh create' command
by Daniel P. Berrange 26 Aug '06

26 Aug '06

The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course) QEMU for example makes it very easy to launch a new VM: qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso Taking inspiration from this syntax we could allow: virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions. Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create - This isn't so critical for Xen, because people are already used to writing config files before creating the domain, but when we get a QEMU backend i think such a convenient method for defining new VMs will be neccessary to encourage users to use virsh instead of manually calling 'qemu'. Even for Xen users it would make shell script easier though :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 5

[Libvir] Allow default hypervisor URI to be set via ENV variable
by Daniel P. Berrange 25 Aug '06

25 Aug '06

When using a non-Xen backend with virsh, it gets pretty tedious always passing '--default test:///some/big/path' - particularly if you're never using Xen on that machine. Thus I figured it would be useful to allow the default Xen URI to be overridden via an environment variable. [berrange@localhost src]$ unset VIRSH_DEFAULT_CONNECT_URI [berrange@localhost src]$ ./virsh list failed to find libvirt_proxy libvir: error : no support for hypervisor lt-virsh: error: failed to connect to the hypervisor [berrange@localhost src]$ export VIRSH_DEFAULT_CONNECT_URI=test:///default [berrange@localhost src]$ ./virsh list Id Name State ---------------------------------- 0 Domain-0 running This will be even more useful when other real hypervisors are available for libvirt. The patch also removes the assumption in virsh that there is >= 1 guest domains - sure Xen always has a Domain-0, but its not guarenteed that other non-Xen HVs have a permanent Domain-0 Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 3

[Libvir] New virt-manager release v0.2.0
by Daniel P. Berrange 25 Aug '06

25 Aug '06

I'm pleased to announce the availabilty of another snapshot / development release of virt-manager, version 0.2.0. The major new capabilities in this release include: * First cut of a wiziard for creating both paravirt & fullyvirt guest VMs. aka the gui equivalent of xenguest-install.py You can find out more about this in the new screenshots section: http://virt-manager.et.redhat.com/screenshots/install.html * An embedded serial console viewer - no need to go to the shell and use 'xm console' anymore. This is actually used for the paravirt guest instllation if your XenU kernel does not support the new VNC framebuffer (not yet in xen-unstable) * Hooked up the config dialog for adjusting vcpus & memory for active domains * Extended RFB protocol handler code to support the 'desktop resize' extensions in the VNC widget - so the graphical console has correct size when the guest switches screen resolutions The tar.gz for the release can be found on the download page: http://virt-manager.et.redhat.com/download.html NB, I'm not providing RPMs in my people.redhat.com YUM repo because we're intending to build this release straight into Fedora rawhide. I'll send a followup message when they're avaiable there. NB-2. there is a dependnacy on the 'xeninst' python library which is a new library built from re-factoring xenguest-install.py You can get this from rawhide in the python-xeninst RPM, or direct from the mercurial repository http://hg.et.redhat.com/virt/applications/xeninst--devel Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 3

[Libvir] Adding test suite for sexpr<->xml conversions
by Daniel P. Berrange 24 Aug '06

24 Aug '06

Quite a critical bit of the libvirt code is that which converts between SEXPR and XML, and vica-verca. I've broken this code several times when making changes, so it is way overdue to get some unit test coverage in this area. The attached patch adds such coverage - defining two tests xml2sexprtest and sexpr2xmltest. The tests are pretty simple, in the tests/ directory I just have a bunch of xml & sexpr files - one is the fixed input, the other is the expected output. The test just runs the conversion and compares the actual output with the expected output. Currently I've added two example data files - one for paravirt & one for fully-virt. With this patch you can run tests: $ make check make check-TESTS make[1]: Entering directory `/home/berrange/src/xen/libvirt/tests' XML-2-SEXPR PV config ... OK XML-2-SEXPR FV config ... OK PASS: xml2sexprtest SEXPR-2-XML PV config ... OK SEXPR-2-XML FV config ... OK PASS: sexpr2xmltest ================== All 2 tests passed ================== make[1]: Leaving directory `/home/berrange/src/xen/libvirt/tests' I'm shortly about to start on updating the code to deal with new CDROM configuration format for HVM guests in Xen 3.0.3, and so intend to add further test files during this process (and of course make sure I don't break the existing ones :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 8

[Libvir] [Libvirt] Proposal to add 3 functions for VBDs (Virtual Block Devices)
by michel.ponceau＠bull.net 24 Aug '06

24 Aug '06

After the new VCPU functions, we also need Virtual Block Device management equivalent to Xen commands: 'xm block-list', 'xm block-attach', 'xm block-detach'. I propose to add in Libvirt the following 3 functions: /** * virDomainGetVbdevs: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVbdevInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual block devices of domain, store it in info. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVbdevs(virDomainPtr domain, virVbdevInfoPtr info, int maxinfo) /** * virDomainCreateVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * @mode: read-only (VIR_VBDMD_RO), or read/write (VIR_VBDMD_RW) * @bkendID: ID of domain hosting the backend device (usually 0 for domain0) * @bkend: pointer to backend device path * * Create a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainCreateVbdev(virDomainPtr domain, unsigned int number, int mode, int bkendID, char *bkend) /** * virDomainDestroyVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * * Destroy a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainDestroyVbdev(virDomainPtr domain, unsigned int number) Structure in libvirt.h: /** * virVbdevInfo: information structure for a Virtual Block Device in a domain */ typedef struct _virVbdevInfo virVbdevInfo; struct _virVbdevInfo { unsigned int number; /* virtual device number */ int state; int evtChn; int ringRef; int bkendID; /* ID of domain hosting the backend device */ char bkend[128]; }; typedef virVbdevInfo *virVbdevInfoPtr; /* Virtual Block Device access modes: read-only or read/write */ #define VIR_VBDMD_RO 0 #define VIR_VBDMD_RW 1

4 5

Re: [Libvir] Semantics for ListDomains/ ListDefinedDomains
by Jim Fehlig 24 Aug '06

24 Aug '06

>>> Gareth S Bestor <bestor(a)us.ibm.com> 08/23/06 8:04 PM >>> > At the *very* worst, is there a way you can pipe an arbitrary xm config > file thru xm and have it spit out what it would have done, without actually > doing it? That could be a reliable fallback migration path perhaps. xm create /path/to/config --dryrun Spits out s-expr last time I checked. Jim

1 0

[Libvir] Release of libvirt-0.1.4
by Daniel Veillard 16 Aug '06

16 Aug '06

Okay, there was a lot of new stuff which accumulated in the last month, it was urgent to push a new release. Available at ftp://libvirt.org/libvirt/ and http://libvirt.org/sources/ * bug fixes: - spec file fix (Mark McLoughlin) - error report problem (with Hugh Brock) - long integer in Python bindings (with Daniel Berrange) - XML generation bug for CDRom (Daniel Berrange) - bug when using number() XPath function (Mark McLoughlin) - fix python detection code - remove duplicate initialization errors (Daniel Berrange) * improvements: - UUID in XML description (Peter Vetere) - proxy code cleanup - virtual CPU and affinity support + virsh support (Michel Ponceau, Philippe Berthault, Daniel Berrange) - port and tty informations for console in XML (Daniel Berrange) - added XML dump to driver and proxy support (Daniel Berrange) - extention of boot options with support for floppy and cdrom (Daniel Berrange) - features block in XML to report/ask PAE, ACPI, APIC for HVM domains (Daniel Berrange) - fail side-effect operations when using read-only connection - large improvements to test driver (Daniel Berrange) * documentation: - spelling (Daniel Berrange) - test driver examples. Thanks to everybody who helped for this release ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Re-factor sexpr_uuid method
by Daniel P. Berrange 16 Aug '06

16 Aug '06

The sexpr_uuid method is used to convert from the printable representation of a UUID into the binary format (unsigned char[16]). This patch refactors the main body of the method so that it is usable by other non-XenD driver backends for parsing UUIDs. This new re-factored method will be used by a patch I'll shortly submit for the test driver backend. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Record an error when refusing a read-only operation
by Daniel P. Berrange 16 Aug '06

16 Aug '06

The libvirt.c front-end can be compiled in 'pedantic' mode in which case it explicitly refuses operations with side-effects in read-only connections. When doing so, however, it was not recording any error message so feedback to the user was misleading / obsure. This patch adds an extra error code VIR_ERR_READ_ONLY which is used when an operation is denied due to a read only connection. This patch also passes 'VIR_DRV_OPEN_QUIET' to the 'open' method so tell the XenD driver not complain if it fails to open a HV connection. This is because it was complaining whenever trying to open a test:///default connection. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Major extensio of test backend driver functionality
by Daniel P. Berrange 16 Aug '06

16 Aug '06

Ok, here comes the huge patch for today - a major extension of the test driver backend... As well as the interal hardcoded 'test:///default' hypervisor config you can now provide a path to an arbitrary XML file defining your HV and its domains. An example file to define a moster 128x6GHz CPU box with 128 GB of RAM and two guest domains looks like: <node> <domain file="testdomfv0.xml"/> <domain file="testdomfc4.xml"/> <cpu> <mhz>6000</mhz> <model>i986</model> <active>50</active> <nodes>4</nodes> <sockets>4</sockets> <cores>4</cores> <threads>2</threads> </cpu> <memory>137438953472</memory> </node> The individual domains 'testdomfv0.xml' and 'testdomfc4.xml' are defined using the regular libvirt XML format. The only exception is that the 'type' attribute on the top level '<domain>' tag should be 'test' instead of 'xen' So for example: $ virsh --connect test:///home/berrange/src/xen/libvirt/docs/testnode.xml virsh > nodeinfo CPU model: i986 CPU(s): 50 CPU frequency: 6000 MHz CPU socket(s): 4 Core(s) per socket: 4 Thread(s) per core: 2 NUMA cell(s): 4 Memory size: 137438953472 kB virsh > list Id Name State ---------------------------------- 0 fv0 running 1 fc4 running virsh > dominfo fc4 Id: 1 Name: fc4 UUID: ef861801-45b9-11cb-88e3-afbfe5370493 OS Type: linux State: running CPU(s): 1 CPU time: 1155740835.5s Max memory: 131072 kB Used memory: 131072 kB virsh > Next up, I've written implementations of the set memory, set max memory, set vcpus, dump xml, create linux APIs for the test driver. THe only major areas of functionality lacking in the test driver now are handling of disk and network devices when creating domains, and the VCPU pinning methods. This test backend makes testing the virt-manager application much more reliable - although we still do need some level of testing against a real Xen backend (for example domain creation). Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Add 'setvcpus', 'setmem', 'setmaxmem' to virsh
by Daniel P. Berrange 16 Aug '06

16 Aug '06

The attached patch adds three new commands to virsh: setmem change memory allocation setmaxmem change maximum memory limit setvcpus change number of virtual CPUs It also ensures then when using the 'test' hypervisor driver, it always opens a read-write connection even as non-root. The test hypervisor does not have any distinction between privileged / unprivileged users, so this test for 'uuid == 0' was bogus. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Flags for CPU / system 'features'
by Daniel P. Berrange 15 Aug '06

15 Aug '06

In the XenD config there are various flags which allow CPU / system features to be enabled / disabled for the guest domain. For example, HVM domains can be created with, or without, PAE, ACPI, APIC. The XenD sexpr contains simple boolean flags for these features within the (image (hvm ....)) block. IMHO, although these 3 particular features may be only be relevant for HVM, it does not make sense to restrict the expression of features to only HVM domains. Thus I propose a top level '<features>' block within the '<domain>' XML doc. This block would contain tags named after each feature to be enabled. Presence of the named tag enables the feature, ommision disables it (thus all features are disabled by default - matching current behaviour). As an example, to enable ACPI, PAE & APIC: <domain type='xen' id='55'> <name>too</name> <uuid>b5d70dd275cdaca517769660b059d8bc</uuid> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> </os> <memory>409600</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <features> <acpi/> <apic/> <pae/> </features> <devices> ...snipped from example.. </devices> </domain> More flags could trivially be added over time. The attached patch implements this proposal. My only thought, is 'features' a good name for this ? Only other name I came up with was 'capabilities' but this is harder to spell :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Fix handling of HVM boot parameters
by Daniel P. Berrange 15 Aug '06

15 Aug '06

Jeremy mentioned that it looked like libvirt wasn't able to create an HVM domain configured to boot off cdrom, so I took a closer look at the code and indeed the code dealing with <boot> section was both incomplete, and just plain broken. Incomplete in so much as it never included details of the ISO file backing the CDROM, and broken in so much as it was doing string comparisons against the wrong variables. Digging further found lots more work relating to creation of HVM domains so I've had a go at writing a patch to resolve matters. * Parsing of UUID from SEXPR assumed that the UUID fetched would always have four '-' in the usual places. Well, when you run 'dumpxml' from virsh the <uuid> element has the UUID encoded without any '-' chars. If you feed this back into 'virsh create' and then once again run 'dumpxml' parsing will fail & libvirt throws errors. So this patch allows for parsing of UUID's without '-'. * The XML document size was limited to 1k - we just 'malloc(1000)'. While this was enough for common cases, if someone creates lots of disk or network devices this would overflow and libvirt return an error. So I increased it to 4k which ought to be enough for forseeable future - in any case my previous patch to fetch XML via the proxy is limited to 4k in size too. Now onto the fine details... When converting SEXPR into XML current code is doing the following: (boot a) -> <boot dev='/dev/fd0'/> (boot c) -> <boot dev='hda'/> (boot d) -> <boot dev='/dev/cdrom'/> This is rather inconsistent - the 'hda' is intended to map to an entry in <devices> block. The '/dev/fd0' and '/dev/cdrom' entries did not map to anything. Meanwhile, when converting from XML to SXEXPR it is doing the following <boot dev='hda'/> -> (boot a) <boot dev='hdd'/> -> (boot d) <boot dev='*'/> -> (boot c) Obviously this sucks because these processes should be matching each other. Secondly, the (image (hvm....)) SEXPR has three entries for defining the ISO / disk image file backing the CDROM / Floppy devices. These were just being ignored, rather than turned into <disk> entries within the <devices> block. Similarly there was no way to express a <disk> entry for CDROM/Floppy in the XML when creating a domain. The upshot of all this is that although the last release of libvirt included HVM support it was basically unusable for domain creation unless you were using HD to boot. The XML returned was also incorrect. Now the good news. Since it was sooo broken, we can fix without worrying about XML compatability since there is no way any application could be relying on it in its current state. Now before I discuss the solution, one final point. The Xen IOMMU model allows specifiying the boot device in terms of 'a', 'c', 'd' which has the meaning: a - first connected floppy device c - first connected harddrive d - first connected cdrom In particular it does *not* allow for expressing boot device in terms of an explicit disk device - you can't say boot off 'hdb' or 'hdc'. So the current libvirt code which tries to fake such semantics is doomed to failure. This isn't really too bad IMHO - VMware has these same semantics, so does QEMU and so do normal bare metal BIOS This in the patch I have attached I have implemented the following mapping: (boot a) <-> <boot dev='fd'/> (boot c) <-> <boot dev='hd'/> (boot d) <-> <boot dev='cdrom'/> The other part of the patch is to deal with definition of the floppy and cdrom device backing files. For this I have done the following: (image (hvm (fda /root/diskboot.img))) <devices> <disk type='file'> <source file='/root/diskboot.img'/> <target dev='fda'/> </disk> </devices> And similar for 'fdb'. Then for cdroms: (image (hvm (cdrom /root/image.iso))) <devices> <disk type='file'> <source file='/root/image.iso'/> <target dev='cdrom'/> </disk> </devices> The patch has a little bit of logic such that when converting the <devices> block backinto an SEXPR it filters out the disk entries with a dev of 'fda', 'fdb' and 'cdrom' since they need to end up in a different part of the SEXPR. Finally, although PV guests automatically get a serial console created for them (and i don't think you can turn it off), HVM guests need to have a serial console explicitly requested. Since I recently added support in the DumpXML method for including details of serial console like this: <devices> <console tty="/dev/pts/5"/> </devices> I decided to leverage this same structure when creating HVM domains. So if you have: <devices> <console/> </devices> Then the SEXPR sent to XenD will include (image (hvm (serial pty))) Which enables allocation of PseudoTTY for the HVM's serial console. I have tested that with this patch I can successfully create a HVM domain which boots off a floppy, harddrive or cdrom. Furthermore if you then dump the XML of this domain,the XML you get back will match the XML you fed in (with the obvious exception of domain ID, and the Pseudo TTY path). If you have been monitoring xen-devel mailing lists you'll be aware that in 3.0.3 the way CDROM devices are configured is changing: http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00369.html Although the patch attached does not support the config outlined in that mail, I'm pretty confident that a small incremental patch will be able to support it without breaking compatability with the changes I've outlined in this mail. The only tricky bit will be that we need to detect whether libvirt is running against a 3.0.2 or 3.0.3 version of XenD to decide how to convert XML -> SEXPR & vica verca. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

4 16

[Libvir] Guest Identification
by Juan Walker 11 Aug '06

11 Aug '06

Hi, I'm trying to find a good way to correlate a domain to the machine it's running on. Can I use libvir or some other method on a domU to get some information that uniquely identifies it? Perhaps something that I can get from the XML running on dom0? I'm thinking of using the MAC address because I imagine that those things should be unique at least per hypervisor, but I'm not sure if that would work across physical boxes. The solution would be to use libvir to get the list of domains and then get the xml which includes the mac address. Then every domain on my network would hit a server and report its mac address, and then I could make a tree that links the dom0's to the domU's. I'm wondering if there's a better way to do this. Any suggestions would be greatly appreciated. Thanks for your help.

3 4

[Libvir] Patch to fix duplicate pause/destroy/shutdown calls
by Daniel P. Berrange 10 Aug '06

10 Aug '06

I spent a while chasing an issue where running 'virsh destroy foo' on an HVM domain would result in an error being returned by the HV ioctl. What I eventually discovered is that the code was doing a destroy op via XenD and then also doing it via the hypervisor backend. It didn't typically show as a problem for PV domains because it seems they took longer to destroy - so were still around by the time the HV destroy was was called. I tracked this issue down to the main dispatch methods in src/libvirt.c which would indeed call both the XenD and HV driver backends for pause destroy & shutdown methods. The patch attached simply returns as soon as one of the driver methods returns a success return code. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Add port number to <graphics> tag
by Daniel P. Berrange 09 Aug '06

09 Aug '06

We recently added the '<graphics>' tag to the XML description for HVM machines. Any apps using this info though would have to hardcode the assumption that Xen's QEMU listens on Domain-ID + 5900. Hardcoding the port numbers in the first place is already a really questionable decision, so we should avoid that propagating out to application code. Thus, the attached patch changes: <graphics type="vnc"/> So that it now looks like <graphics type="vnc" port="5905"/> The hardcoded 'Domain-ID + 5900' craziness is now at least isolated in libvirt, so provided apps take the port number from the XML they will be immune from changes in port numbering scheme. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 15

[Libvir] Here the patch for virtual CPU functions.
by Philippe Berthault 07 Aug '06

07 Aug '06

The patch (vcpus.diff) is joined with this mail. To apply the patch, untar the libvirt-0.1.3.tar.gz archive (if not already done). Then in libvirt-0.1.3 directory, do ./configure --prefix=/usr if not already done, and after this: patch -p1 < vcpus.diff make make install From the initial patch of Michel Ponceau (not delivered), I've just modify the virDomainGetVcpus function and added some useful macro for bit manipulation in cpu bit maps. TODO: These vcpus functions permits to dynamically change the vcpu/cpu relation after the domain has been started but nothing has been done regarding static cpus attribution in the XML configuration file of a domain. Philippe Berthault. --- libvirt-0.1.3/include/libvirt/libvirt.h 2006-07-11 18:05:07.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/include/libvirt/libvirt.h 2006-08-02 16:42:51.000000000 +0200 @@ -289,6 +289,106 @@ const char **names, int maxnames); int virDomainCreate (virDomainPtr domain); +/////////////////////////////////////////////////////////////////////////// + +/** + * virVcpuInfo: structure for information about a virtual CPU in a domain. + */ + +typedef enum { + VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ + VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ + VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource */ +} virVcpuState; + +typedef struct _virVcpuInfo virVcpuInfo; +struct _virVcpuInfo { + unsigned int number; /* virtual CPU number */ + int state; /* value from virVcpuState */ + unsigned long long cpuTime; /* CPU time used, in nanoseconds */ + int cpu; /* real CPU number, or -1 if offline */ +}; +typedef virVcpuInfo *virVcpuInfoPtr; + +int virDomainSetVcpus (virDomainPtr domain, + unsigned int nvcpus); + +int virDomainPinVcpu (virDomainPtr domain, + unsigned int vcpu, + unsigned char *cpumap, + int maplen); + +/** + * USE_CPU: + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) (IN/OUT) + * @cpu: the physical CPU number + * + * This macro is to be used in conjonction with virDomainPinVcpu() API. + * USE_CPU macro set the bit (CPU usable) of the related cpu in cpumap. + */ + +#define USE_CPU(cpumap,cpu) (cpumap[(cpu)/8] |= (1<<((cpu)%8))) + +/** + * UNUSE_CPU: + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) (IN/OUT) + * @cpu: the physical CPU number + * + * This macro is to be used in conjonction with virDomainPinVcpu() API. + * USE_CPU macro reset the bit (CPU not usable) of the related cpu in cpumap. + */ + +#define UNUSE_CPU(cpumap,cpu) (cpumap[(cpu)/8] &= ~(1<<((cpu)%8))) + +int virDomainGetVcpus (virDomainPtr domain, + virVcpuInfoPtr info, + int maxinfo, + unsigned char *cpumaps, + int maplen); + +/** + * CPU_USABLE: + * @cpumaps: pointer to an array of cpumap (in 8-bit bytes) (IN) + * @maplen: the length (in bytes) of one cpumap + * @vcpu: the virtual CPU number + * @cpu: the physical CPU number + * + * This macro is to be used in conjonction with virDomainGetVcpus() API. + * CPU_USABLE macro returns a non zero value (true) if the cpu + * is usable by the vcpu, and 0 otherwise. + */ + +#define CPU_USABLE(cpumaps,maplen,vcpu,cpu) \ + (cpumaps[((vcpu)*(maplen))+((cpu)/8)] & (1<<((cpu)%8))) + +/** + * COPY_CPUMAP: + * @cpumaps: pointer to an array of cpumap (in 8-bit bytes) (IN) + * @maplen: the length (in bytes) of one cpumap + * @vcpu: the virtual CPU number + * @cpumap: pointer to a cpumap (in 8-bit bytes) (OUT) + * This cpumap must be previously allocated by the caller (ie: malloc(maplen)) + * + * This macro is to be used in conjonction with virDomainGetVcpus() and + * virDomainPinVcpu() APIs. COPY_CPUMAP macro extract the cpumap of the specified + * vcpu from cpumaps array and copy it into cpumap to be used later by virDomainPinVcpu() API. + */ +#define COPY_CPUMAP(cpumaps,maplen,vcpu,cpumap) \ + memcpy(cpumap, &(cpumaps[(vcpu)*(maplen)]), (maplen)) + + +/** + * GET_CPUMAP: + * @cpumaps: pointer to an array of cpumap (in 8-bit bytes) (IN) + * @maplen: the length (in bytes) of one cpumap + * @vcpu: the virtual CPU number + * + * This macro is to be used in conjonction with virDomainGetVcpus() and + * virDomainPinVcpu() APIs. GET_CPUMAP macro returns a pointer to the cpumap + * of the specified vcpu from cpumaps array. + */ +#define GET_CPUMAP(cpumaps,maplen,vcpu) &(cpumaps[(vcpu)*(maplen)]) + #ifdef __cplusplus } --- libvirt-0.1.3/src/xen_internal.h 2006-07-03 17:09:24.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xen_internal.h 2006-08-02 16:53:42.000000000 +0200 @@ -44,6 +44,18 @@ unsigned long memory); int xenHypervisorCheckID (virConnectPtr conn, int id); +int xenHypervisorSetVcpus (virDomainPtr domain, + unsigned int nvcpus); +int xenHypervisorPinVcpu (virDomainPtr domain, + unsigned int vcpu, + unsigned char *cpumap, + int maplen); +int xenHypervisorGetVcpus (virDomainPtr domain, + virVcpuInfoPtr info, + int maxinfo, + unsigned char *cpumaps, + int maplen); + #ifdef __cplusplus } #endif --- libvirt-0.1.3/src/xen_internal.c 2006-07-03 17:09:24.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xen_internal.c 2006-08-03 13:52:28.000000000 +0200 @@ -18,7 +18,7 @@ #include <fcntl.h> #include <sys/mman.h> #include <sys/ioctl.h> - +#include <limits.h> #include <stdint.h> /* required for dom0_getdomaininfo_t */ @@ -838,4 +838,138 @@ return (0); } +/////////////////////////////////////////////////////////////////////////////// + +/** + * xenHypervisorSetVcpus: + * @domain: pointer to domain object + * @nvcpus: the new number of virtual CPUs for this domain + * + * Dynamically change the number of virtual CPUs used by the domain. + * + * Returns 0 in case of success, -1 in case of failure. + */ + +int +xenHypervisorSetVcpus(virDomainPtr domain, unsigned int nvcpus) +{ + dom0_op_t op; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->conn->handle < 0) + || (nvcpus < 1)) + return (-1); + op.cmd = DOM0_MAX_VCPUS; + op.u.max_vcpus.domain = (domid_t) domain->handle; + op.u.max_vcpus.max = nvcpus; + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + return 0; +} + +/** + * xenHypervisorPinVcpu: + * @domain: pointer to domain object + * @vcpu: virtual CPU number + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) + * @maplen: length of cpumap in bytes + * + * Dynamically change the real CPUs which can be allocated to a virtual CPU. + * + * Returns 0 in case of success, -1 in case of failure. + */ + +int +xenHypervisorPinVcpu(virDomainPtr domain, unsigned int vcpu, + unsigned char *cpumap, int maplen) +{ + dom0_op_t op; + uint64_t *pm = (uint64_t *)&op.u.setvcpuaffinity.cpumap; + int j; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->conn->handle < 0) + || (cpumap == NULL) || (maplen < 1) || (maplen > (int)sizeof(cpumap_t)) + || (sizeof(cpumap_t) & 7)) + return (-1); + op.cmd = DOM0_SETVCPUAFFINITY; + op.u.setvcpuaffinity.domain = (domid_t) domain->handle; + op.u.setvcpuaffinity.vcpu = vcpu; + memset(pm, 0, sizeof(cpumap_t)); + for (j = 0; j < maplen; j++) + *(pm + (j / 8)) |= cpumap[j] << (8 * (j & 7)); + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + return 0; +} +/** + * virDomainGetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @info: pointer to an array of virVcpuInfo structures (OUT) + * @maxinfo: number of structures in info array + * @cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) + * If cpumaps is NULL, then no cupmap information is returned by the API. + * It's assumed there is <maxinfo> cpumap in cpumaps array. + * The memory allocated to cpumaps must be (maxinfo * maplen) bytes + * (ie: calloc(maxinfo, maplen)). + * One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. + * @maplen: number of bytes in one cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * + * Extract information about virtual CPUs of domain, store it in info array + * and also in cpumaps if this pointer is'nt NULL. + * + * Returns the number of info filled in case of success, -1 in case of failure. + */ +int +xenHypervisorGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) +{ + dom0_op_t op; + uint64_t *pm = (uint64_t *)&op.u.getvcpuinfo.cpumap; + virVcpuInfoPtr ipt; + int nbinfo, mapl, i; + unsigned char *cpumap; + int vcpu, cpu; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->conn->handle < 0) + || (info == NULL) || (maxinfo < 1) + || (sizeof(cpumap_t) & 7)) + return (-1); + if (cpumaps != NULL && maplen < 1) + return -1; + + /* first get the number of virtual CPUs in this domain */ + op.cmd = DOM0_GETDOMAININFO; + op.u.getdomaininfo.domain = (domid_t) domain->handle; + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + nbinfo = (int)op.u.getdomaininfo.max_vcpu_id + 1; + if (nbinfo > maxinfo) nbinfo = maxinfo; + + if (cpumaps != NULL) + memset(cpumaps, 0, maxinfo * maplen); + + op.cmd = DOM0_GETVCPUINFO; + for (i=0, ipt=info; i < nbinfo; i++, ipt++) { + vcpu = op.u.getvcpuinfo.vcpu = i; + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + ipt->number = i; + if (op.u.getvcpuinfo.online) { + if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING; + if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED; + } + else ipt->state = VIR_VCPU_OFFLINE; + ipt->cpuTime = op.u.getvcpuinfo.cpu_time; + ipt->cpu = op.u.getvcpuinfo.online ? (int)op.u.getvcpuinfo.cpu : -1; + if (cpumaps != NULL && vcpu >= 0 && vcpu < maxinfo) { + cpumap = (unsigned char *)GET_CPUMAP(cpumaps, maplen, vcpu); + mapl = (maplen > (int)sizeof(cpumap_t)) ? (int)sizeof(cpumap_t) : maplen; + for (cpu = 0; cpu < (mapl * CHAR_BIT); cpu++) { + if (*pm & ((uint64_t)1<<cpu)) + USE_CPU(cpumap, cpu); + } + } + } + return nbinfo; +} --- libvirt-0.1.3/src/libvirt.c 2006-07-03 17:09:24.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/libvirt.c 2006-08-02 15:30:29.000000000 +0200 @@ -1648,4 +1648,126 @@ return(-1); } +/////////////////////////////////////////////////////////////////////////// +/** + * virDomainSetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @nvcpus: the new number of virtual CPUs for this domain + * + * Dynamically change the number of virtual CPUs used by the domain. + * Note that this call may fail if the underlying virtualization hypervisor + * does not support it or if growing the number is arbitrary limited. + * This function requires priviledged access to the hypervisor. + * + * Returns 0 in case of success, -1 in case of failure. + */ + +int +virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) +{ + if (domain == NULL) { + TODO + return (-1); + } + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + return (-1); + } + if (domain->conn->flags & VIR_CONNECT_RO) + return (-1); + if (nvcpus < 1) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } +// if (xenHypervisorSetVcpus(domain, nvcpus) == 0) +// return 0; + return xenDaemonDomainSetVcpus(domain, nvcpus); +} + +/** + * virDomainPinVcpu: + * @domain: pointer to domain object, or NULL for Domain0 + * @vcpu: virtual CPU number + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) (IN) + * Each bit set to 1 means that corresponding CPU is usable. + * Bytes are stored in little-endian order: CPU0-7, 8-15... + * In each byte, lowest CPU number is least significant bit. + * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * If maplen < size, missing bytes are set to zero. + * If maplen > size, failure code is returned. + * + * Dynamically change the real CPUs which can be allocated to a virtual CPU. + * This function requires priviledged access to the hypervisor. + * + * Returns 0 in case of success, -1 in case of failure. + */ +int +virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, + unsigned char *cpumap, int maplen) +{ + if (domain == NULL) { + TODO + return (-1); + } + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + return (-1); + } + if (domain->conn->flags & VIR_CONNECT_RO) + return (-1); + if ((vcpu < 1) || (cpumap == NULL) || (maplen < 1)) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } + if (xenHypervisorPinVcpu(domain, vcpu, cpumap, maplen) == 0) + return 0; + return (-1); //xenDaemonDomainPinVcpu(domain, vcpu, cpumap, maplen); +} + +/** + * virDomainGetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @info: pointer to an array of virVcpuInfo structures (OUT) + * @maxinfo: number of structures in info array + * @cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) + * If cpumaps is NULL, then no cupmap information is returned by the API. + * It's assumed there is <maxinfo> cpumap in cpumaps array. + * The memory allocated to cpumaps must be (maxinfo * maplen) bytes + * (ie: calloc(maxinfo, maplen)). + * One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. + * @maplen: number of bytes in one cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * + * Extract information about virtual CPUs of domain, store it in info array + * and also in cpumaps if this pointer is'nt NULL. + * + * Returns the number of info filled in case of success, -1 in case of failure. + */ +int +virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) +{ + int ret; + + if (domain == NULL) { + TODO + return (-1); + } + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + return (-1); + } + if ((info == NULL) || (maxinfo < 1)) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } + if (cpumaps != NULL && maplen < 1) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } + ret = xenHypervisorGetVcpus(domain, info, maxinfo, cpumaps, maplen); + if (ret != -1) return ret; + return xenDaemonDomainGetVcpus(domain, info, maxinfo, cpumaps, maplen); +} --- libvirt-0.1.3/src/xend_internal.h 2006-07-10 12:24:05.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xend_internal.h 2006-08-02 16:54:27.000000000 +0200 @@ -631,6 +631,18 @@ unsigned long xenDaemonDomainGetMaxMemory(virDomainPtr domain); char **xenDaemonListDomainsOld(virConnectPtr xend); +int xenDaemonDomainSetVcpus (virDomainPtr domain, + int vcpus); +int xenDaemonDomainPinVcpu (virDomainPtr domain, + unsigned int vcpu, + unsigned char *cpumap, + int maplen); +int xenDaemonDomainGetVcpus (virDomainPtr domain, + virVcpuInfoPtr info, + int maxinfo, + unsigned char *cpumaps, + int maplen); + #ifdef __cplusplus } #endif --- libvirt-0.1.3/src/libvirt_sym.version 2006-05-29 18:19:30.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/libvirt_sym.version 2006-08-02 15:26:56.000000000 +0200 @@ -47,5 +47,9 @@ virConnResetLastError; virDefaultErrorFunc; virNodeGetInfo; + + virDomainSetVcpus; + virDomainPinVcpu; + virDomainGetVcpus; local: *; }; --- libvirt-0.1.3/src/xend_internal.c 2006-07-10 16:41:54.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xend_internal.c 2006-08-02 16:48:24.000000000 +0200 @@ -2429,6 +2429,156 @@ free(name); return (NULL); } +/////////////////////////////////////////////////////////////////////////// + +/** + * xenDaemonDomainSetVcpus: + * @domain: pointer to domain object + * @nvcpus: the new number of virtual CPUs for this domain + * + * Dynamically change the number of virtual CPUs used by the domain. + * + * Returns 0 for success; -1 (with errno) on error + */ +int +xenDaemonDomainSetVcpus(virDomainPtr domain, int vcpus) +{ + char buf[16]; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) + || (vcpus < 1)) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + snprintf(buf, sizeof(buf), "%d", vcpus); + return xend_op(domain->conn, domain->name, "op", "set_vcpus", "vcpus", + buf, NULL); +} + +/** + * xenDaemonDomainPinCpu: + * @domain: pointer to domain object + * @vcpu: virtual CPU number + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) + * @maplen: length of cpumap in bytes + * + * Dynamically change the real CPUs which can be allocated to a virtual CPU. + * + * Returns 0 for success; -1 (with errno) on error + */ +int +xenDaemonDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, + unsigned char *cpumap, int maplen) +{ + char buf[16], mapstr[sizeof(cpumap_t) * 64] = "["; + int i, j; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) + || (cpumap == NULL) || (maplen < 1) || (maplen > (int)sizeof(cpumap_t))) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + + /* from bit map, build character string of mapped CPU numbers */ + for (i = 0; i < maplen; i++) for (j = 0; j < 8; j++) + if (cpumap[i] & (1 << j)) { + sprintf(buf, "%d,", (8 * i) + j); + strcat(mapstr, buf); + } + mapstr[strlen(mapstr) - 1] = ']'; + snprintf(buf, sizeof(buf), "%d", vcpu); + return xend_op(domain->conn, domain->name, "op", "pincpu", "vcpu", buf, + "cpumap", mapstr, NULL); +} + +/** + * virDomainGetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @info: pointer to an array of virVcpuInfo structures (OUT) + * @maxinfo: number of structures in info array + * @cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) + * If cpumaps is NULL, then no cupmap information is returned by the API. + * It's assumed there is <maxinfo> cpumap in cpumaps array. + * The memory allocated to cpumaps must be (maxinfo * maplen) bytes + * (ie: calloc(maxinfo, maplen)). + * One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. + * @maplen: number of bytes in one cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * + * Extract information about virtual CPUs of domain, store it in info array + * and also in cpumaps if this pointer is'nt NULL. + * + * Returns the number of info filled in case of success, -1 in case of failure. + */ +int +xenDaemonDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) +{ + struct sexpr *root, *s, *t; + virVcpuInfoPtr ipt = info; + int nbinfo = 0, oln; + unsigned char *cpumap; + int vcpu, cpu; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) + || (info == NULL) || (maxinfo < 1)) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + if (cpumaps != NULL && maplen < 1) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + root = sexpr_get(domain->conn, "/xend/domain/%s?op=vcpuinfo", domain->name); + if (root == NULL) + return (-1); + + if (cpumaps != NULL) + memset(cpumaps, 0, maxinfo * maplen); + + /* scan the sexprs from "(vcpu (number x)...)" and get parameter values */ + for (s = root; s->kind == SEXPR_CONS; s = s->cdr) + if ((s->car->kind == SEXPR_CONS) && + (s->car->car->kind == SEXPR_VALUE) && + !strcmp(s->car->car->value, "vcpu")) { + t = s->car; + vcpu = ipt->number = sexpr_int(t, "vcpu/number"); + if (oln = sexpr_int(t, "vcpu/online")) { + if (sexpr_int(t, "vcpu/running")) ipt->state = VIR_VCPU_RUNNING; + if (sexpr_int(t, "vcpu/blocked")) ipt->state = VIR_VCPU_BLOCKED; + } + else ipt->state = VIR_VCPU_OFFLINE; + ipt->cpuTime = sexpr_float(t, "vcpu/cpu_time") * 1000000000; + ipt->cpu = oln ? sexpr_int(t, "vcpu/cpu") : -1; + + if (cpumaps != NULL && vcpu >= 0 && vcpu < maxinfo) { + cpumap = (unsigned char *)GET_CPUMAP(cpumaps, maplen, vcpu); + /* get sexpr from "(cpumap (x y z...))" and convert values to bitmap */ + for (t = t->cdr; t->kind == SEXPR_CONS; t = t->cdr) + if ((t->car->kind == SEXPR_CONS) && + (t->car->car->kind == SEXPR_VALUE) && + !strcmp(t->car->car->value, "cpumap") && + (t->car->cdr->kind == SEXPR_CONS)) { + for (t = t->car->cdr->car; t->kind == SEXPR_CONS; t = t->cdr) + if (t->car->kind == SEXPR_VALUE) { + cpu = strtol(t->car->value, NULL, 0); + if (cpu >= 0) + USE_CPU(cpumap, cpu); + } + break; + } + } + + if (++nbinfo == maxinfo) break; + ipt++; + } + sexpr_free(root); + return nbinfo; +} /** * xenDaemonLookupByUUID:

3 9

[Libvir] New (last ?) virtual cpu functions proposal
by Philippe Berthault 03 Aug '06

03 Aug '06

Here the new virtual cpu functions proposal. What do you think about it ? /** * *virVcpuInfo*: structure for information about a virtual CPU in a domain. */ typedef enum { VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource */ *} virVcpuState*; typedef struct _virVcpuInfo virVcpuInfo; struct _virVcpuInfo { unsigned int number; /* virtual CPU number */ int state; /* value from virVcpuState */ unsigned long long cpuTime; /* CPU time used, in nanoseconds */ int cpu; /* real CPU number, or -1 if offline */ }; typedef virVcpuInfo **virVcpuInfoPtr*; /** * *virDomainSetVcpus*: * @*domain*: pointer to domain object, or NULL for Domain0 * @*nvcpus*: the new number of virtual CPUs for this domain * * Dynamically change the number of virtual CPUs used by the domain. * Note that this call may fail if the underlying virtualization hypervisor * does not support it or if growing the number is arbitrary limited. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int *virDomainSetVcpus* (virDomainPtr domain, unsigned int nvcpus); /** * *virDomainPinVcpu*: * @*domain*: pointer to domain object, or NULL for Domain0 * @*vcpu*: virtual CPU number * @*cpumap*: pointer to a bit map of real CPUs (in 8-bit bytes). * Each bit set to 1 means that corresponding CPU is usable. * Bytes are stored in little-endian order: CPU0-7, 8-15... * In each byte, lowest CPU number is least significant bit. * @*maplen*: number of bytes in cpumap, from 1 up to size of CPU map in * underlying virtualization system (Xen...). * If maplen < size, missing bytes are set to zero. * If maplen > size, failure code is returned. * * Dynamically change the real CPUs which can be allocated to a virtual CPU. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int *virDomainPinVcpu* (virDomainPtr domain, unsigned int vcpu, unsigned char *cpumap, int maplen); /* Macros for bit manipulation in cpumap */ #define *USE_CPU*(cpumap,cpu) (cpumap[(cpu)/8] |= (1<<((cpu)%8))) #define *UNUSE_CPU*(cpumap,cpu) (cpumap[(cpu)/8] &= ~(1<<((cpu)%8))) /** * *virDomainGetVcpus*: * @*domain*: pointer to domain object, or NULL for Domain0 * @*info*: pointer to an array of virVcpuInfo structures * @*maxinfo*: number of structures in info array * @*cpumaps*: pointer to a bit map of real CPUs for all vcpus of this domain. * If cpumaps is NULL, then no cpumap information is returned by the API. * It's assumed there is <maxinfo> cpumap in cpumaps. * The memory allocated to cpumaps must be (maxinfo * maplen) bytes. * One cpumap inside cupmaps have the format described in virDomainPinVcpu API. * @*maplen*: number of bytes in one cpumap, from 1 up to size of CPU map in * underlying virtualization system (Xen...). * * Extract information about virtual CPUs of domain, store it in info array. * * Returns the number of info filled in case of success, -1 in case of failure. */ int *virDomainGetVcpus* (virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, unsigned char *cpumaps, /* may be NULL */ int maplen); /* Macros for bit testing in cpumaps */ #define *CPU_USABLE*(cpumaps,maplen,vcpu,cpu) \ (cpumaps[((vcpu)*(maplen))+((cpu)/8)] & (1<<((cpu)%8))) /* * Macro for copying the cpumap of a vcpu from cupmaps inside a standalone cpumap. * This macro is useful in case of using virDomainPinVcpu() after virDomainGetVcpus(). * cpumap must be previously allocated. */ #define *COPY_CPUMAP*(cpumaps,maplen,vcpu,cpumap) \ memcpy(cpumap, &(cpumaps[(vcpu)*(maplen)]), (maplen))

3 5

[Libvir] Newbie questions!
by Rodrigo Lord 03 Aug '06

03 Aug '06

Hello! I`m trying o use libvirt (or libvir?) what`s the difference? (this is the first question!) So, I compiled libvirt and libvir on my ia64 system(debian sarge 3.1) and download the code exemple of the website http://libvirt.org named info1.c To compile I used: "gcc -o test_dom0 test_dom0.c -lvirt" and ok. But when I try to run, shows the error below: peso@debian-ia64:~/test_libvirt$ ./test_dom0 libvir: error : no support for hypervisor Xen Failed to connect to hypervisor I tryied too to compile using: "gcc -o test_dom0 test_dom0.c -lvir" but doesn`t work too: peso@debian-ia64:~/test_libvirt$ ./test_dom0 Failed to find Domain 0 Thanks!

1 0

[Libvir] Re: Virtual CPU functions
by Philippe Berthault 03 Aug '06

03 Aug '06

I've tried to illustrate an exemple of virDomainGetVcpus API with a 2 dimensional cpumaps array. If you are agree with this, I can modify the patch of Michel Ponceau in this sense before the end of this week. I've proposed the virDomainGetCpus API to be in accordance with the virDomainPinVcpu which is per vpcu and not per domain as virDomainGetVcpus API. The virDomainPinVcpu API is'nt symmetrical with virDomainGetVcpus and must be called N times to perform the CPU mapping of a domain which isn't very satisfying. Another complaint against the virDomainPinVcpu versus virDomainGetVcpus API is that the cpumap parameter hasn't the same meaning in these two APIs. This point requires to duplicate macro for bit manipulations on these maps. Philippe Berthault ______________________________________________________________________ virConnectPtr pConn; virDomainPtr pDomain; virNodeInfo nodeInfo; virDomainInfo domInfo; virVcpuInfoPtr pVcpuInfos; int nbPhysCpus; unsigned char *cpuMaps[]; /* 1st dimension = per virtual cpu, 2nd dimension = per physical cpu */ int oneCpuMapLen; int vcpu, cpu; #define CPU_USABLE(maps,vcpu,cpu) (maps[vcpu][((cpu) / 8)] & (1 >> ((cpu) % 8))) ... virNodeGetInfo(pConn, &nodeInfo); nbPhysCpus = nodeInfo.cpus; /* ? or ? */ nbPhysCpus = nodeInfo.nodes * nodeInfo.sockets * nodeInfo.cores * nodeInfo.threads; virDomainGetInfo(pDomain, &domInfo); pVcpuInfos = malloc(sizeof(virVcpuInfo)*domInfo.nrVirtCpu); oneCpuMapLen = (nbPhysCpus + 7) / 8; cpuMaps = calloc(domInfo.nrVirtCpu, oneCpuMapLen); virDomainGetVcpus(pDomain, pVcpuInfos, domInfo.nrVirtCpu, cpuMaps, oneCpuMapLen); for (vcpu = 0; vcpu < domInfo.nrVirtCpu; vcpu++) { for (cpu = 0; cpu < nbPhysCpus; cpu++) { int byteCpu = cpu / 8; int bitCpu = cpu % 8; int mask = 1 >> bitCpu; /* lowest CPU number is least significant bit as M.Ponceau said */ int cpuUsable = cpuMaps[vcpu][byteCpu] & mask; ... /* or */ int cpuUsable = CPU_USABLE(cpuMaps, vcpu, cpu); ... if (cpuUsable) { printf("The physical cpu #%d is usable by virtual cpu #%d of domain #%s\n", cpu, vcpu, virDomainGetName(pDomain)); } } } ______________________________________________________________________

3 6

[Libvir] Virtual CPUs functions
by Philippe Berthault 01 Aug '06

01 Aug '06

Hello, I'm working on the vpcu patch of Michel Ponceau because he is in vacation for a long time. Michel has proposed to add 3 APIs to libvirt: - virDomainSetVcpus - virDomainPinVcpu - virDomainGetVcpus I've seen in libvirt mail archives that there was a problem with the virDomainGetVcpus API because the virCpuInfo structure contains a CPU map for only 256 physical CPUs. Your proposition to remove cpumap field from virCpuInfo structure and add it as parameter to the virDomainGetVcpus API isn't valid for the following reason: The virDomainGetVcpus API fills an array of virCpuInfo structures (one virCpuInfo for one VCPU) but cpumap is for one VCPU, not for all VCPUs at whole. Your proposition can work only if cpumap is a array of array of characters and if maplen is also an array of integers. This is very complicated solution and not elegant. I've also seen that you make a mistake in your proposition because you compute the cpuMapLen from the number of virtual CPUs but the cpumap is related to physical CPUs, not virtual CPUs. So, in conclusion, I propose, as you, to remove cpumap field of the virCpuInfo structure but to add an API to retrieve the CPU map of one VCPU. Such API would be: int virDomainGetCpus(virDomainPtr domain, unsigned int vcpu, unsigned char *cpumap, int maplen); The name is ...GetCpus (not 'Vcpus') because this API get the physical CPU map, not the virtual CPU map. Regards, Philippe Berthault.

2 1

Réf. : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by jean-paul.pigache＠bull.net 31 Jul '06

31 Jul '06

I hope I will find a way to post the patches prepared by Michel Ponceau before the end of the week. Jean-Paul "Daniel P. Berrange" <berrange(a)redhat.com> Envoyé par : libvir-list-bounces(a)redhat.com 29/07/2006 09:35 Veuillez répondre à "Daniel P. Berrange" Pour : Jim Fehlig <jfehlig(a)novell.com> cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Fri, Jul 28, 2006 at 03:18:17PM -0600, Jim Fehlig wrote: > Has any progress been made on this proposal? I don't see anything in > current CVS. This functionality would be useful for Xen-CIM project. IIRC Michel Ponceau might have started on some prototype code, but he didn't post it to the list yet & is apparently on vacation for another couple of weeks (according to his email auto-responder). If no one else has started work on it in the meantime, I'm planning to get working on it when I return from vacation Aug 4th since I also need it for the virt-manager application. Regards, Dan. > michel.ponceau(a)bull.net wrote: > > > >Corrections on proposal: > >1) PinVcpus > >Replace: > > * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > >* @maplen: length of cpumap, in 8-bit bytes > >by: > > * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). > > * Each bit set to 1 means that corresponding CPU is usable. > > * Bytes are stored in little-endian order: CPU0-7, 8-15... > > * In each byte, lowest CPU number is least significant bit. > > * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in > > * underlying virtualization system (Xen...). > > * If maplen < size, missing bytes are set to zero. > > * If maplen > size, failure code is returned. > > > >2) GetVcpu > >Add 4rth argument: > > * @maplen: number of bytes in cpumap field of virVcpuInfo > >virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int > >maxinfo, int maplen) > > > >3) Structure VcpuInfo > >Suppress: #define VIR_MAX_CPUS 256 > >Replace: > > unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. > >by: > > unsigned char cpumap[]; /* Bit map of usable real CPUs. > > Variable length: it may be less or greater than size of CPU > >map in > > underlying virtualization system (Xen...). > > > >4) Accessor macros: to be defined later. > > > >Veuillez répondre à veillard(a)redhat.com > > > >Pour : michel.ponceau(a)bull.net > >cc : libvir-list(a)redhat.com > >Objet : Re: Proposal : add 3 functions to Libvirt API, for > >virtual CPUs > > > >On Fri, Jun 30, 2006 at 04:00:45PM +0200, michel.ponceau(a)bull.net wrote: > >> For our administration, we need the following actions, while concerned > >> domain is running: > >> 1) Change the number of virtual CPUs. > >> 2) Change the pinning (affinity) of a virtual CPU on real CPUs. > >> 3) Get detailed information for each virtual CPU. > >> Currently there is no Libvirt function provided for that. We suggest to > >> add the following 3 functions (in libvirt.c): > >> /** > >> * virDomainSetVcpus: > >> * @domain: pointer to domain object, or NULL for Domain0 > >> * @nvcpus: the new number of virtual CPUs for this domain > >> * > >> * Dynamically change the number of virtual CPUs used by the domain. > >> * Note that this call may fail if the underlying virtualization > >> hypervisor > >> * does not support it or if growing the number is arbitrary limited. > >> * This function requires priviledged access to the hypervisor. > >> * > >> * Returns 0 in case of success, -1 in case of failure. > >> */ > >> int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) > > > > okay > > > >> /** > >> * virDomainPinVcpu: > >> * @domain: pointer to domain object, or NULL for Domain0 > >> * @vcpu: virtual CPU number > >> * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > >> * @maplen: length of cpumap, in 8-bit bytes > >> * > >> * Dynamically change the real CPUs which can be allocated to a virtual > >> CPU. > >> * This function requires priviledged access to the hypervisor. > >> * > >> * Returns 0 in case of success, -1 in case of failure. > >> */ > >> int virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, > >> unsigned char *cpumap, int maplen) > > > > Can you explain more clearly what is the format of cpumap ? An example > >would be welcome, and that would be needed for the doc and maybe testing. > >What would happen if maplen is < or > than the number of CPU divided > >by 8 ? > > > >> /** > >> * virDomainGetVcpus: > >> * @domain: pointer to domain object, or NULL for Domain0 > >> * @info: pointer to an array of virVcpuInfo structures > >> * @maxinfo: number of structures in info array > >> * > >> * Extract information about virtual CPUs of a domain, store it in info > >> array. > >> * > >> * Returns the number of info filled in case of success, -1 in case of > >> failure. > >> */ > >> int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int > >> maxinfo) > > > > Hum ... now the problem with that API entry point is that we 'burn' the > >maximum 256 processors in the ABI, i.e. if we ever need to go past 256 > >client and servers need to be recompiled. Maybe this is not a real problem > >in practice but that's annoying. Is there existing APIs doing this kind > >of things (in POSIX for example), and what hard limit did they use ? > > Maybe > > int virDomainGetVcpusNr(virDomainPtr domain, int nr, virVcpuInfoPtr info, > > int maxCPU); > >Where the maxCPU is defined by the client as the number of real CPU > >it defined in its virVcpuInfoPtr and then an iteration over the virtual > >CPU defined in the domain is possible too. > >Of course if the domain uses many virtual CPUs this would become expensive > >but somehow I don't see that being the common use, I would rather guess > >the domains created use a few CPUs even if instantiated on a very > >large machine. > >This > > > > > >> with the following structure (in libvirt.h): > >> /** > >> * virVcpuInfo: structure for information about a virtual CPU in a > >domain. > >> */ > >> #define VIR_MAX_CPUS 256 > > > > Hum, there is already NUMA machines with more than 256 processors, > >it's annoying to define an API limit when you know it is already > >breakable. > > > >> typedef enum { > >> VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ > >> VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ > >> VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on > >resource > >> */ > >> } virVcpuState; > >> > >> typedef struct _virVcpuInfo virVcpuInfo; > >> struct _virVcpuInfo { > >> unsigned int number; /* virtual CPU number */ > >> int state; /* value from virVcpuState */ > >> unsigned long long cpuTime; /* CPU time used, in nanoseconds */ > >> int cpu; /* real CPU number, or -1 if offline */ > >> unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real > >CPUs. > >> Each bit set to 1 means that corresponding CPU is > >usable. > >> Bytes are stored in little-endian order: CPU0-7, 8-15... > >> In each byte, lowest CPU number is least significant > >bit > >> */ > >> }; > >> typedef virVcpuInfo *virVcpuInfoPtr; > > > > Hum, maybe some accessors should be provided in the API, letting the > >client > >code handle access and having to take care of indianness issues > >doesn't feel > >very nice. Something like the FD_CLR/FD_ISSET/FD_SET/FD_ZERO equivalents > >when using the select() POSIx call. > > > >> I have successfully tried those functions via Xen hypervisor, except > >for > >> the first (SetVcpus) where hypervisor operation DOM0_MAX_VCPUS fails > >> (maybe it is not possible on a running domain ?). That function was > >> successful via Xen daemon. > > > >Maybe that operation requires more than one hypervisor call to > >actually enable > >the processors. The simpler would be to look at the code in xend about > >what's > >needed there, maybe the kernel need to be made aware of that and I > >would expect > >this to be a xenstore operation. > >At least we know we can fallback to xend if the hypervisor call > >doesn't work > >directly. > >I don't know if virDomainGetVcpus should really be mutated into > >virDomainGetVcpusNr, I would certainly like to be able to keep that API > >extensible for more than 256 CPUs. Maybe I'm just too cautious there, > > > > I would really like feedback from others on this issue ! > >In the meantime sending the current set of patches you developped could > >allow to look closely at the 2 calls that I feel okay with. > > > > thanks and sorry it took so long ! > > > >Daniel > > > >-- > >Daniel Veillard | Red Hat http://redhat.com/ > >veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > >http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > > > >------------------------------------------------------------------------ > > > >-- > >Libvir-list mailing list > >Libvir-list(a)redhat.com > >https://www.redhat.com/mailman/listinfo/libvir-list > > > > -- > Libvir-list mailing list > Libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

1 0

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 29 Jul '06

29 Jul '06

Corrections on proposal: 1) PinVcpus Replace: * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) * @maplen: length of cpumap, in 8-bit bytes by: * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). * Each bit set to 1 means that corresponding CPU is usable. * Bytes are stored in little-endian order: CPU0-7, 8-15... * In each byte, lowest CPU number is least significant bit. * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in * underlying virtualization system (Xen...). * If maplen < size, missing bytes are set to zero. * If maplen > size, failure code is returned. 2) GetVcpu Add 4rth argument: * @maplen: number of bytes in cpumap field of virVcpuInfo virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, int maplen) 3) Structure VcpuInfo Suppress: #define VIR_MAX_CPUS 256 Replace: unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. by: unsigned char cpumap[]; /* Bit map of usable real CPUs. Variable length: it may be less or greater than size of CPU map in underlying virtualization system (Xen...). 4) Accessor macros: to be defined later. Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Fri, Jun 30, 2006 at 04:00:45PM +0200, michel.ponceau(a)bull.net wrote: > For our administration, we need the following actions, while concerned > domain is running: > 1) Change the number of virtual CPUs. > 2) Change the pinning (affinity) of a virtual CPU on real CPUs. > 3) Get detailed information for each virtual CPU. > Currently there is no Libvirt function provided for that. We suggest to > add the following 3 functions (in libvirt.c): > /** > * virDomainSetVcpus: > * @domain: pointer to domain object, or NULL for Domain0 > * @nvcpus: the new number of virtual CPUs for this domain > * > * Dynamically change the number of virtual CPUs used by the domain. > * Note that this call may fail if the underlying virtualization > hypervisor > * does not support it or if growing the number is arbitrary limited. > * This function requires priviledged access to the hypervisor. > * > * Returns 0 in case of success, -1 in case of failure. > */ > int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) okay > /** > * virDomainPinVcpu: > * @domain: pointer to domain object, or NULL for Domain0 > * @vcpu: virtual CPU number > * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > * @maplen: length of cpumap, in 8-bit bytes > * > * Dynamically change the real CPUs which can be allocated to a virtual > CPU. > * This function requires priviledged access to the hypervisor. > * > * Returns 0 in case of success, -1 in case of failure. > */ > int virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, > unsigned char *cpumap, int maplen) Can you explain more clearly what is the format of cpumap ? An example would be welcome, and that would be needed for the doc and maybe testing. What would happen if maplen is < or > than the number of CPU divided by 8 ? > /** > * virDomainGetVcpus: > * @domain: pointer to domain object, or NULL for Domain0 > * @info: pointer to an array of virVcpuInfo structures > * @maxinfo: number of structures in info array > * > * Extract information about virtual CPUs of a domain, store it in info > array. > * > * Returns the number of info filled in case of success, -1 in case of > failure. > */ > int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int > maxinfo) Hum ... now the problem with that API entry point is that we 'burn' the maximum 256 processors in the ABI, i.e. if we ever need to go past 256 client and servers need to be recompiled. Maybe this is not a real problem in practice but that's annoying. Is there existing APIs doing this kind of things (in POSIX for example), and what hard limit did they use ? Maybe int virDomainGetVcpusNr(virDomainPtr domain, int nr, virVcpuInfoPtr info, int maxCPU); Where the maxCPU is defined by the client as the number of real CPU it defined in its virVcpuInfoPtr and then an iteration over the virtual CPU defined in the domain is possible too. Of course if the domain uses many virtual CPUs this would become expensive but somehow I don't see that being the common use, I would rather guess the domains created use a few CPUs even if instantiated on a very large machine. This > with the following structure (in libvirt.h): > /** > * virVcpuInfo: structure for information about a virtual CPU in a domain. > */ > #define VIR_MAX_CPUS 256 Hum, there is already NUMA machines with more than 256 processors, it's annoying to define an API limit when you know it is already breakable. > typedef enum { > VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ > VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ > VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource > */ > } virVcpuState; > > typedef struct _virVcpuInfo virVcpuInfo; > struct _virVcpuInfo { > unsigned int number; /* virtual CPU number */ > int state; /* value from virVcpuState */ > unsigned long long cpuTime; /* CPU time used, in nanoseconds */ > int cpu; /* real CPU number, or -1 if offline */ > unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. > Each bit set to 1 means that corresponding CPU is usable. > Bytes are stored in little-endian order: CPU0-7, 8-15... > In each byte, lowest CPU number is least significant bit > */ > }; > typedef virVcpuInfo *virVcpuInfoPtr; Hum, maybe some accessors should be provided in the API, letting the client code handle access and having to take care of indianness issues doesn't feel very nice. Something like the FD_CLR/FD_ISSET/FD_SET/FD_ZERO equivalents when using the select() POSIx call. > I have successfully tried those functions via Xen hypervisor, except for > the first (SetVcpus) where hypervisor operation DOM0_MAX_VCPUS fails > (maybe it is not possible on a running domain ?). That function was > successful via Xen daemon. Maybe that operation requires more than one hypervisor call to actually enable the processors. The simpler would be to look at the code in xend about what's needed there, maybe the kernel need to be made aware of that and I would expect this to be a xenstore operation. At least we know we can fallback to xend if the hypervisor call doesn't work directly. I don't know if virDomainGetVcpus should really be mutated into virDomainGetVcpusNr, I would certainly like to be able to keep that API extensible for more than 256 CPUs. Maybe I'm just too cautious there, I would really like feedback from others on this issue ! In the meantime sending the current set of patches you developped could allow to look closely at the 2 calls that I feel okay with. thanks and sorry it took so long ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

4 6

[Libvir] Source repository
by Diwaker Gupta 23 Jul '06

23 Jul '06

Given that most Xen related stuff (including virt-man) lives in Mercurial repositories, it seems a little weird (and a little cumbersome) that libvirt continues to use CVS. This issue briefly came up on the list once earlier, but didn't go anywhere. Is there any strong reason why libvirt can't move to Mercurial? Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog

3 4

Réf. : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by jean-paul.pigache＠bull.net 21 Jul '06

21 Jul '06

This interesting thread is temporarilu suspended because Michel has left for some (long) vacation until August 15th. I think the last proposal is a good one and deserves to be implemented and tested. I am confident that Michel will be willing to update its patch accordingly when he comes back. Is it OK for you ?. Side question: is there a defined "sign-off" procedure to follow when submitting patches ? Cordialement. Jean-Paul Daniel Veillard <veillard(a)redhat.com> Envoyé par : libvir-list-bounces(a)redhat.com 17/07/2006 15:08 Veuillez répondre à veillard Pour : "Daniel P. Berrange" <berrange(a)redhat.com> cc : libvir-list(a)redhat.com, michel.ponceau(a)bull.net Objet : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Mon, Jul 17, 2006 at 01:50:25PM +0100, Daniel P. Berrange wrote: > On Tue, Jul 11, 2006 at 10:50:53AM -0400, Daniel Veillard wrote: > > We still have a relatively simple API for the common case, and for special > > cases we have an extension capability with relatively clear definitions. it's > > a bitstrange but I think that should cover most case as best as possible > > I dont particularly like this as an API because I think it will be error > prone for application developers. Most app developers will only ever have > a handful of CPUs in their test machines, so they'll never the alternate > codepath for > 256 cpu case. Likewise I don't like the idea of a virVcpuInfo > struct which has a variable size because it will totally confuse people who > haven't read the API docs very carefully, again leading to obscure bugs. > > The root problem is that we have two conflicting goals here > > 1. Want to have virVcpuInfo be a fixed size struct > 2. We want a cpumap of arbitrary size Right this is confusing, I wanted to avoid another allocation in the general case but this made things even more confusing. > The obvious solution to this problem is to *remove* the cpumap data from > the virVcpuInfo structure completely, and always pass in a separately > malloc'd array of the correct size. So I'd suggest: > > typedef struct _virVcpuInfo virVcpuInfo; > struct _virVcpuInfo { > unsigned int number; /* virtual CPU number */ > int state; /* value from virVcpuState */ > unsigned long long cpuTime; /* CPU time used, in nanoseconds */ > int cpu; /* real CPU number, or -1 if offline */ > } > > virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, > char *cpumap, int maplen); Agreed, this is the most logical approach > > The client applications calling this API already have to malloc() the memory > region for the 'info' parameter of a correct size, so having to also malloc > the cpumap parameter is no extra trouble. > > virDomainInfo info; > virDomainVpuInfoPtr cpuInfo; > int cpuMapLen; > char *cpuMap; > > virDomainGetInfo(domain, &info); > > cpuInfo = malloc(sizeof(virDomainVcpuInfo)*info.nrVirtCpu); > cpuMapLen = (info.nrVirtCpu + 7) / 8 ; > cpuMap = malloc(cpuMapLen); > > virDomainGetVCpus(domain, cpuInfo, info.nrVirtCpu, cpuMap, cpuMapLen); > > ... do stuff with the data ... > > free(cpuInfo); > free(cpuMap); > > > So you can see there is minimal extra work to always pass in cpuMap as > a separate parameter. If an application didn't care about the cpuMap > data they could simply pass in NULL. Agree. We should keep an example of use (like above completed) in the source tree to help developpers. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

2 1

[Libvir] Bug with libvirt in Xen 3.0.1?
by pvetere＠redhat.com 21 Jul '06

21 Jul '06

Hi, I think I may have found a bug in libvirt and wanted see what people thought. I'm using the stock FC5 installation at the moment (with xen 3.0.1), and the newest version of libvirt. I am noticing that with xen 3.0.1 and newer versions of libvirt, getDomainsID() seems to return bogus values. For example: [root@test05 ~]# virsh list Id Name State ---------------------------------- 0 Domain-0 running libvir: Xen Daemon error : GET operation failed: No such domain 65486 libvir: Xen Daemon error : GET operation failed: No such domain 2986 But, if I use xm, I get what I expect: [root@test05 ~]# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 1507 2 r----- 387.5 vm1 1 256 1 -b---- 151.3 vm2 2 256 1 -b---- 87.9 After some digging around in the code, I believe that libvirt is incorrectly identifying the hypervisor as being "old" in xen_internal.c:xenHypervisorInit, and is therefore passing the incorrect parameter structure into the hypervisor when it makes its ioctl in xen_internal.c:xenHypervisorListDomains. I've tried this same test on a system running xen 3.0.2, and as I expected everything works fine. So, there must be something different about xen 3.0.1 that libvirt is not accounting for. At this point, I don't really have more time to dig further but I thought I'd bring up the issue in case someone on this list can offer more insight. Pete

3 5

[Libvir] Virtual Machine Manager 0.1.5 release
by Daniel P. Berrange 20 Jul '06

20 Jul '06

I've just pushed out another snapshot of the Virtual Machine Manager GUI application for managing Xen machines via libvirt. A summary of the changes in this 0.1.5 release[1]: * Integration with GNOME keyring for the VNC console to avoid need to remember passwords when accessing the guest domain's console * Use cairo to render a '50% alpha gray wash' over the screenshot to give appearance of a 'dimmed' display when paused. Also render the word 'paused' in big letters. * Initial cut of code for saving & restoring domain snapshots to disk * Added icons for buttons which were missing graphics * Miscellaneous RPM spec file fixes to comply with rpmlint * Update status icons to match those in the gnome-applet-vm * Added domain ID and # VCPUs to summary view * Misc bug fixes The next priority target for development is some UI for creating new VM instances (a GUI equivalent of xenguest-install.py script shipping with current Fedora Xen packages) and implenenting the UI for editing domain configuration / hardware. In addition there is now a more permanent home for the application's web pages: http://virt-manager.et.redhat.com/index.html And the Mercurial repository is now published for anonymous read-only access at: http://hg.et.redhat.com/virt/applications/virt-manager--devel Patches are welcome either as traditional unified diffs, or as mercurial changeset bundles - see the following page for details on exporting bundles using hg: http://virt-manager.et.redhat.com/scmrepo.html Regards, Dan. [1] There was a 0.1.4 but it had a fatal flaw in it breaking the console -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Question about XML
by Juan Walker 20 Jul '06

20 Jul '06

Hi, I have a question regarding the XML format that libvir uses for domain configuration. I was wondering if there is a way to use the configuration format that xm uses or if a tool exists to convert to XML. I'm writing an app to help users manage their Xen domains but I'm hoping to be able to use any .sxp files that the user already has. I suspect I missed something in the documentation about why the XML format is better, but if there is no such tool maybe I should volunteer to write one? Thanks.

3 2

[Libvir] just a question about libvirt evolution
by Philippe Berthault 20 Jul '06

20 Jul '06

Hello, Several major modifications will appear this year in future Xen releases (3.0.3 and 3.0.4) that may have impacts on libvirt. These modifications (see xen roadmap edited by Ian Pratt in july 2006) are : - Introduction of XML-RPC, - Xen configuration files in XML format, - Suppression of S-Expressions, - etc.. What is the libvirt position about these points ? Is the initial goal of libvirt to mask Xen evolutions will be always possible ? The most problematic problem would be the configurations files in XML format. Libvirt already supports its own XML format of configuration files. It seems to me that it would be interesting to use the same XML format (or a compatible format) in libvirt and in Xen. Is there a plan in this direction ? Thanks.

3 2

[Libvir] Patch to correct spelling
by Daniel P. Berrange 20 Jul '06

20 Jul '06

The attached patch changes 'informations' to 'information' throughout the codebase to fix up the English grammer. I assume its ok to commit ? Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] possible bug in virDomainLookupByID
by Bryan D. Payne 19 Jul '06

19 Jul '06

I'm experiencing an odd problem in virDomainLookupByID when using 0.1.3 that does not exist when using 0.1.1. Perhaps this is a side effect of switching the backend connection? I'm curious is anyone else has seen this and/or if you have any suggestions for fixing it. The attached code generates the problem that I'm seeing. Specifically, after upgrading to 0.1.3, calling virDomainLookupByID twice results in a failure on the second call. This behavior was not seen in 0.1.1. Any thoughts? Thanks, bryan PS... This problem is seen in XenAccess. Thanks to Daniele Sgandurra for bringing it to my attention. #include <stdio.h> #include <string.h> #include <libvirt/libvirt.h> #include <libvirt/virterror.h> #include <libxml/parser.h> #include <libxml/tree.h> char *get_xml_info (int id) { virConnectPtr conn = NULL; virDomainPtr dom = NULL; char *xml_data = NULL; /* NULL means connect to local Xen hypervisor */ conn = virConnectOpenReadOnly(NULL); if (NULL == conn) { printf("ERROR: Failed to connect to hypervisor\n"); goto error_exit; } /* Find the domain of the given id */ dom = virDomainLookupByID(conn, id); if (NULL == dom) { virErrorPtr error = virConnGetLastError(conn); printf("(%d) %s\n", error->code, error->message); printf("ERROR: Failed to find Domain %d\n", id); goto error_exit; } xml_data = virDomainGetXMLDesc(dom, 0); error_exit: if (NULL!= dom) virDomainFree(dom); if (NULL!= conn) virConnectClose(conn); return xml_data; } int main () { char *xml = NULL; xml = get_xml_info(1); if (!xml){ printf("Failed on first try\n"); return 0; } free(xml); xml = get_xml_info(1); if (!xml){ printf("Failed on second try\n"); return 0; } free(xml); return 1; }

3 5

[Libvir] virDomainLookupByID problem when Root
by Daniele Sgandurra 17 Jul '06

17 Jul '06

Hi all! I've tried to compile and execute info1.c both as user and as root. As user I have no problem, but as root I get: Failed to find Domain 0 I've traced back the problem to the function: virDomainLookupByID(virConnectPtr conn, int id) at the line: path = xs_get_domain_path(conn->xshandle, (unsigned int) id); When root I get path != NULL, otherwise path==NULL; if path==NULL then the block after it is executed and everything is ok, otherwise at the end of the function name=null. (I manually changed path to NULL so that I can run it when root and it works even if info.maxMem it's different from when the program is run as a normal user: it shows -4 instead of 464896). It could be a configuration problem of mine (of Xen Store for example)? Thanks! Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

3 3

[Libvir] announce: gnome-applet-vm-0.1.0rc1
by Karel Zak 14 Jul '06

14 Jul '06

I have just pushed out a new version of the VM Applet. The changes/features are: - D-BUS support and integration with virt-manager - console helper support for privileged operations - fixed a lot of bugs - new icons - better GUI - the applet internally supports multiple libvirt connection (in future it will be useful for monitoring remote virtual machines) Web page (with screenshot of course:-): http://people.redhat.com/kzak/gnome-applet-vm/ Please, help me found bugs and improve this application. Karel -- Karel Zak <kzak(a)redhat.com>

1 0

[Libvir] Patch: Fix for UUIDs in XML parser
by Peter Vetere 13 Jul '06

13 Jul '06

Hi all. Here's a pretty straightforward patch that fixes a bug I found where, if <uuid>...</uuid> is specified in the XML on the call createLinux, it is not propagated down to Xend. The result is an instance with a different UUID than the one requested. Pete

2 1

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 13 Jul '06

13 Jul '06

I imagined that each Libvirt user could choose its own MAX number of CPU. If it is not possible, at least can we reserve the extended cpumap for future development (TODO, same as NULL domain pointer) ? Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Thu, Jul 13, 2006 at 01:12:47PM +0200, michel.ponceau(a)bull.net wrote: > I don't understand. Libvirt users must of course compile API and > application with the same libvirt.h, after updating the value of > VIR_MAX_CPUS when necessary. And go from first info element to next one by > (info+1), which adds sizeof(virVcpuInfo) to address, including correct > length of cpumap according to: > unsigned char cpumap[(VIR_MAX_CPUS + 7) / 8]; /* Bit map of usable > real CPUs. > For alignment constraints, compiler rounds up the sizeof(virVcpuInfo)when > needed. Well if you need to recompile the library to use a larger set of CPU you don't garantee API and ABI, by definition. And you will need to recompile the library because the structures passed between the app and the library change size, this will also likely affect the proxy since I expect vCPU informations to be provided (so communication between the library and proxy must change). There is certainly solutions to the scalability problem, but suggesting a change of header and recompilation of the whole software stack is really not one I would like to propose, it breaks basically all expectations an enterprise customer would have w.r.t. using the library. Unless I really misunderstood what you were suggesting, which is possible in that case reformulating it might be a good idea, because I really understood you want to make the MAX number of CPU a compile time setting. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 13 Jul '06

13 Jul '06

I don't understand. Libvirt users must of course compile API and application with the same libvirt.h, after updating the value of VIR_MAX_CPUS when necessary. And go from first info element to next one by (info+1), which adds sizeof(virVcpuInfo) to address, including correct length of cpumap according to: unsigned char cpumap[(VIR_MAX_CPUS + 7) / 8]; /* Bit map of usable real CPUs. For alignment constraints, compiler rounds up the sizeof(virVcpuInfo)when needed. Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Tue, Jul 11, 2006 at 05:29:52PM +0200, michel.ponceau(a)bull.net wrote: > 2) CPU map cut into standard + extension : It would be more simple to let > each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h. > It could be similar to the version number update, from libvirt.h.in to > libvirt.h : > #define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@ No, I do think it is instead very hard. You start to get into very annoying problems from an API point of view. How do you go from the first element in the info array to the next one ? in the client it's already not nice, you must do pointer arithmetic (and I really don't want to push an API which forces that to most users), it expose potential serious problem like alignment and packing, problems between versions of compilers and tools. In a nutshell I don't want an API where one need to access an array of structure where the size of the structure is not defined by the API itself. What I suggested did that in both case, either low number of CPUs and fixed size records like you initial solutions, or high number of CPUs and you work on a two dimentional array of bytes. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 1

[Libvir] Connecting to remote hypervisors?
by Nick Devito 13 Jul '06

13 Jul '06

I might be overlooking something, but, I don't see anything on the libvirt site about it. Does libvirt support connecting to a remote hypervisor, if so, how? Thanks, Nick Devito

3 2

[Libvir] Updated snapshot of virt-manager GUI application
by Daniel P. Berrange 12 Jul '06

12 Jul '06

I have just pushed out RPM / tar.gz of a new development (alpha) snapshot of the virt-manager GUI application. The changes in this snapshot are: * Fixed DBus service activation & general brokeness * Added a display of virtual CPU count in summary view * Fixed alignment of status label in details page * Make hardware config panel resizeable * Switch detailed graph rendering to use sparkline code instead of matplotlib, removing a huge RPM dependancy chain * Switch to use filled sparkline graphs instead of outline Although I didn't increment the RPM dependancy, I strongly recommend using libvirt 0.1.3 if your host is running > 5 guest domains. This reduces the number of HTTP GETs made by an order of magnitude, improving the response time / scalability of the virt-manager refresh. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 11 Jul '06

11 Jul '06

1) PinVcpu : I consider the size of CPU map in bytes, that is (max_nb_CPUs + 7) / 8 . 2) CPU map cut into standard + extension : It would be more simple to let each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h. It could be similar to the version number update, from libvirt.h.in to libvirt.h : #define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@ Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Tue, Jul 11, 2006 at 04:14:12PM +0200, michel.ponceau(a)bull.net wrote: > Corrections on proposal: > 1) PinVcpus > Replace: > * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > * @maplen: length of cpumap, in 8-bit bytes > by: > * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). > * Each bit set to 1 means that corresponding CPU is usable. > * Bytes are stored in little-endian order: CPU0-7, 8-15... > * In each byte, lowest CPU number is least significant bit. > * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in > * underlying virtualization system (Xen...). > * If maplen < size, missing bytes are set to zero. > * If maplen > size, failure code is returned. Okay, that's sensible I guess except for maplen it can go from 1 to size + 7 div 8 not up to size , right ? > 2) GetVcpu > Add 4rth argument: > * @maplen: number of bytes in cpumap field of virVcpuInfo > virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, > int maplen) > > 3) Structure VcpuInfo > Suppress: #define VIR_MAX_CPUS 256 > Replace: > unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. > by: > unsigned char cpumap[]; /* Bit map of usable real CPUs. > Variable length: it may be less or greater than size of CPU map in > underlying virtualization system (Xen...). Hum, I could see compilers righteously complaining about unsigned char cpumap[]; in a structure. Maybe we should default to 256 / 8 but allow at the API level to grow over that value. What we could do is define a default of 256 available in the structure and allow an extra parameter which could point to a larger array like the following: - restore VIR_MAX_CPUS as VIR_STD_MAX_CPUS 256 - virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, char *lcpumap, int lmaplen); lcpumap and lmaplen being extra arguments for very large arrays for most use case, we will fit in 256 processors, those will be respectively NULL and 0, but assuming we have more than 256 processors: + maxinfo > VIR_STD_MAX_CPUS + lcpumap points to a array of bytes, they are interpreted as an array of cpumap of ((maxinfo + 7) div 8) bytes each. So if lmaplen != ((maxinfo + 7) div 8) * maxinfo then there is an error. in that case the cpumap structures of info are not filled on return. We still have a relatively simple API for the common case, and for special cases we have an extension capability with relatively clear definitions. it's a bitstrange but I think that should cover most case as best as possible > 4) Accessor macros: to be defined later. okay, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 1

[Libvir] Release of libvirt-0.1.2
by Daniel Veillard 11 Jul '06

11 Jul '06

Available at ftp://libvirt.org/libvirt/ This release includes only a couple of things: - fix the header include problem reported last week - add a proxy based driver for read only access from non-root users In a nutshell the proxy goal is to allow monitoring from unpriviledged users by running a proxy which is a small binary running as root accepting connections from libvirt instances and implementing then using either xend RPCs or hypervisor calls. Only read-only operations are implemented i.e. it is useful for monitoring. This requires the (xend-unix-server yes) option to be set in /etc/xen/xend-config.sxp since the proxy connects to xend with the httpdu local socket, that done one can disable the xend-http-server . The proxy itself is started and stopped automatically by the library on-demand. The communication between libvirt instances and the proxy is custom, currently only synchronous operations are implemented but it should be possible to add asynchronous event passing if libvirt is extended this way. The next things I will focuse on are: the 4 unimplemented yet APIs for defined but non-running domains, the CPU extensions which have been proposed last week and the HVM (fully virtualized) Xen domain support sent by Jim Fehlig. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 1

[Libvir] Updated patch for hvm guests
by Jim Fehlig 11 Jul '06

11 Jul '06

Attached is an updated patch providing some support for HVM guests. I have tested listing info on running guests and creating guests. cdrom support for HVM guests still needs some work, as does graphics options. Guests using graphics type 'sdl' still need some work. Using type 'vnc' is functional, but you must then manually use e.g. "vncviewer localhost:<dom_id>" to view. I've also included a patch that backs out some optimizations done xend_internal.c. There is a bug in xend (from testing - I think Anthony fixed it and patch got applied to unstable) that does not close the connection after initial create op causing libvirt to block indefinitely. Backing out the optimizations allowed me to use the hvm patch on _testing branch of xen. I've included it for anyone else that may want to experiment with the hvm patch on _testing xen. Finally, the attached archive contains: 1. a sample xml input file for hvm guest, 2. corresponding s-expr sent to xend, and 3. s-expr returned from xend when getting info on the running guest. I will be on vacation and not have access to network until July 9. I will improve this work after returning. Enjoy, Jim

3 9

[Libvir] Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 10 Jul '06

10 Jul '06

For our administration, we need the following actions, while concerned domain is running: 1) Change the number of virtual CPUs. 2) Change the pinning (affinity) of a virtual CPU on real CPUs. 3) Get detailed information for each virtual CPU. Currently there is no Libvirt function provided for that. We suggest to add the following 3 functions (in libvirt.c): /** * virDomainSetVcpus: * @domain: pointer to domain object, or NULL for Domain0 * @nvcpus: the new number of virtual CPUs for this domain * * Dynamically change the number of virtual CPUs used by the domain. * Note that this call may fail if the underlying virtualization hypervisor * does not support it or if growing the number is arbitrary limited. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) /** * virDomainPinVcpu: * @domain: pointer to domain object, or NULL for Domain0 * @vcpu: virtual CPU number * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) * @maplen: length of cpumap, in 8-bit bytes * * Dynamically change the real CPUs which can be allocated to a virtual CPU. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, unsigned char *cpumap, int maplen) /** * virDomainGetVcpus: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVcpuInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual CPUs of a domain, store it in info array. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo) with the following structure (in libvirt.h): /** * virVcpuInfo: structure for information about a virtual CPU in a domain. */ #define VIR_MAX_CPUS 256 typedef enum { VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource */ } virVcpuState; typedef struct _virVcpuInfo virVcpuInfo; struct _virVcpuInfo { unsigned int number; /* virtual CPU number */ int state; /* value from virVcpuState */ unsigned long long cpuTime; /* CPU time used, in nanoseconds */ int cpu; /* real CPU number, or -1 if offline */ unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. Each bit set to 1 means that corresponding CPU is usable. Bytes are stored in little-endian order: CPU0-7, 8-15... In each byte, lowest CPU number is least significant bit */ }; typedef virVcpuInfo *virVcpuInfoPtr; I have successfully tried those functions via Xen hypervisor, except for the first (SetVcpus) where hypervisor operation DOM0_MAX_VCPUS fails (maybe it is not possible on a running domain ?). That function was successful via Xen daemon.

3 2

[Libvir] Scability / performance fix for virDomainLookupByID
by Daniel P. Berrange 10 Jul '06

10 Jul '06

Attached is a patch to significantly increase scalability / performance of the xenDaemonLookupByID method. The current implementation would get a list of all domain names from XenD, and then iterate doing a HTTP GET on /xend/domain/[name] until the domain with match ID was found. THis had O(n) complexity, with the result that when running on a system with 20 actives domains, 'virsh list' would have O(n^2) complexity needing ~230 HTTP calls, giving a runtime of ~9 seconds. The patch is to make the code do a HTTP GET on /xend/domain/[id] which we just discovered is a valid URL to access. This makes the method call O(1), and 'virsh list' is now a saner O(n), and completes in ~1 second. While still not great performance, this is certainly much better. I think it ought to be possible to optimize the code still further so that XenD is avoided altogether for simple commands which can be fullfilled purely with data available from Hypervisor, but that will need further investigation. Please review the patch in case I missed any bugs / edge cases Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 5

[Libvir] support for hvm guests
by Jim Fehlig 03 Jul '06

03 Jul '06

Daniel, FYI, I'm working on a patch to support hvm guests. Attached is the work thus far. Calling "virsh dumpxml some_hvm_guest" will (almost) correctly dump xml config info on hvm guests. Needs to handle "type=ioemu" component of VIF specification. Currently in the XML there is a type attribute for the interface element that specifies bridge, route, etc. How would you like to structure the interface element and its children to account for hvm guests? Using "virsh create file" where file contains XML config for hvm guests may be close to working but I haven't tested it yet. There are several options that need to be added to the XML to support hvm guests. If we can agree on the structure I can add the functionality. Regards, Jim

6 25

[Libvir] Xen/libVirt GUI app: "Virtual Machine Manager"
by Daniel P. Berrange 28 Jun '06

28 Jun '06

I'm pleased to make available the code for an early *development snapshot* of a graphical application for managing virtual machines. This application is using libvirt as its backend API for managing virtual machines, while the user interface is built in Python and GTK/Glade. The application allows monitoring of guest VM resource utilization / allocation. There are basic controls for controlling the run state of guest. There is also a VNC client widget (written in pure Python!) for displaying the virtual guest framebuffer on fully-virt machines: http://people.redhat.com/berrange/virt-manager/index.html This is a very early snapshot - lots of functionality isn't hooked up yet, the error handling is mostly not there, and there are certainly plenty of bugs. It should none-the-less give a reasonable feel for the kind of direction the application will evolve in. Furthermore the website includes the UI mockups done by our user interaction designers to show some of the ideas considered in ongoing development of the application. The RPMs linked to from the website should install on both Fedora Core 5[1] and Fedora Core 6 test1. The FAQ contains a list of explicit dependancies which should facilitate people trying to get it running on non-Fedora Linux distros. Regards, Dan. [1] You'll need libvirt-0.1.1 from updates-testing -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] just a question about virDomainLookupByName function
by Philippe Berthault 28 Jun '06

28 Jun '06

An ID may be passed to virDomainLookupByName function. In exemple: virDomainLookupByName(conn, "1") is equivalent to virDomainLookupByID(conn, 1) This functionality is very useful but isn't written in the libvirt documentation. Is this functionality will continue to exist in future versions of libvirt or not ? Thanks, Philippe Berthault.

2 1