- Devel - libvirt List Archives

[Libvir] [patch 2/5] iptables: use calloc() instead of malloc()/memset()
by Mark McLoughlin 21 Mar '07

21 Mar '07

Replace a few instances of malloc() followed by memset(0) with calloc() Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> Index: libvirt/qemud/iptables.c =================================================================== --- libvirt.orig/qemud/iptables.c +++ libvirt/qemud/iptables.c @@ -270,11 +270,9 @@ iptRulesNew(const char *table, { iptRules *rules; - if (!(rules = (iptRules *)malloc(sizeof (iptRules)))) + if (!(rules = (iptRules *)calloc(1, sizeof (iptRules)))) return NULL; - memset (rules, 0, sizeof (iptRules)); - if (!(rules->table = strdup(table))) goto error; @@ -353,11 +351,9 @@ iptablesAddRemoveChain(iptRules *rules, 2 + /* --table foo */ 2; /* --new-chain bar */ - if (!(argv = (char **)malloc(sizeof(char *) * (n+1)))) + if (!(argv = (char **)calloc(n + 1, sizeof(char *)))) goto error; - memset(argv, 0, sizeof(char *) * (n + 1)); - n = 0; if (!(argv[n++] = strdup(IPTABLES_PATH))) @@ -413,14 +409,12 @@ iptablesAddRemoveRule(iptRules *rules, i va_end(args); - if (!(argv = (char **)malloc(sizeof(char *) * (n + 1)))) + if (!(argv = (char **)calloc(n + 1, sizeof(char *)))) goto error; if (!(rule = (char *)malloc(rulelen))) goto error; - memset(argv, 0, sizeof(char *) * (n + 1)); - n = 0; if (!(argv[n++] = strdup(IPTABLES_PATH))) --

1 0

[Libvir] [patch 1/5] iptables: fix invalid free
by Mark McLoughlin 21 Mar '07

21 Mar '07

In iptablesContextNew(), make sure we don't try and free an invalid pointer if one of the iptRulesNew() fails. Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> Index: libvirt/qemud/iptables.c =================================================================== --- libvirt.orig/qemud/iptables.c +++ libvirt/qemud/iptables.c @@ -496,7 +496,7 @@ iptablesContextNew(void) { iptablesContext *ctx; - if (!(ctx = (iptablesContext *) malloc(sizeof (iptablesContext)))) + if (!(ctx = (iptablesContext *) calloc(1, sizeof (iptablesContext)))) return NULL; if (!(ctx->input_filter = iptRulesNew("filter", IPTABLES_PREFIX "INPUT"))) @@ -518,9 +518,12 @@ iptablesContextNew(void) void iptablesContextFree(iptablesContext *ctx) { - iptRulesFree(ctx->input_filter); - iptRulesFree(ctx->forward_filter); - iptRulesFree(ctx->nat_postrouting); + if (ctx->input_filter) + iptRulesFree(ctx->input_filter); + if (ctx->forward_filter) + iptRulesFree(ctx->forward_filter); + if (ctx->nat_postrouting) + iptRulesFree(ctx->nat_postrouting); free(ctx); } --

1 0

[Libvir] [patch 0/5] Misc. fixes to iptables support
by Mark McLoughlin 21 Mar '07

21 Mar '07

Hey, What follows is a few misc patches for qemud's iptables support. The main point is to add reload-on-HUP as suggested by danpb. Comments welcome .. Cheers, Mark. --

1 0

[Libvir] A whole tonne of networking fixes / enhancements
by Daniel P. Berrange 21 Mar '07

21 Mar '07

I've been testing the networking support and found various bugs / missing features that I thought we really need to have in the release - some of them impact the XML so we have to get this right now. - Build up in memory linked-list of network devices & disk devices in same order as they are listed in XML. Currently they are built up in reversed order, which makes the XML not be idempotent, and also means that if you have multiple NICs, what you think is eth0 ends up being eth4 and what you think is eth4 is eth0. This patch fixes the ordering to match XML. - Set the 'vlan' attribute in command line args to QEMU. This ensures that separate network devices are in fact separated. Previously if you had multiple NICs, QEMU connected them all to the same VLAN so any traffic on one NIC got sent to all NICs. Most definitely not what you want in any usual scenario, and created a traffic storm from the resultant network loops ! - Added support for networking of type='bridge'. This gives parity with equivalent Xen networking, eg <interface type='bridge'> <source dev='xenbr0'/> <target dev='vnet3'/> </interface> Will create a tap device called vnet3 and bridge it into xenbr0 - Added support for networking of type='ethernet'. This give parity with equivlent Xen networking, eg <interface type='ethernet'> <script path='/etc/qemu-ifup'/> <target dev='vnet5'/> </interface> Will create a tap device called vnet5 and run 'qemu-ifup' to setup its configuration. Think the various non-bridge Xen networking configs. - Added support for 'client', 'server', 'mcast' networking types. These are QEMU specific types, allowing unprivileged (or privileged) users to create virtual networks without TAP devices. eg two machines, one with <interface type='server'> <source address="127.0.0.1" port="5555"/> </interface> And the other with <interface type='client'> <source address="127.0.0.1" port="5555"/> </interface> Or both using multicast: <interface type='mcast'> <source address="230.0.0.1" port="5558"/> </interface> Both these options allow QEMU instancs on different physical machines to talk to each other. The multicast protocol is also compatible with the UserModeLinux multicast protocol. - Fix the 'type=network' config use the <target dev='vnet3'> element instead of a custom tapifname=vnet3 attribute - this gives consistent way to name tap devices that - most importantly - matches the Xen XML format for specifying vifname, eg <interface type='network'> <source network='default'/> <target dev='vnet2'/> </interface> Will create a tapdevice called vnet2 and connect it to the bridge device associated with the network 'default'. - Removed references to 'vde' - we're not using this explicitly - at some time in the future, we'll perhaps use VDE for doing virtual networking for unprivileged users where bridge devices are not available - Removed references to 'tap' network type - this is basically handled by the 'ethernet' network type to give XML compatability with the same functionality in the Xen backend. - The virtual network configuration currently always adds whole bunch of IPTables rules to the FORWARD/POSTROUTING chain which allow traffic from the virtual network to be masqueraded out through any active physical interface. This may be correct thing todo for the default network, but we also need the ability to create totally isolated networks (no forwarding at all), or directed networks (eg forwarding to an explicit physical device). To deal with this scenario I introduce a new element in the network XML called '<forward>'. If this is not present, then no forwarding rules are added at all. If it is present, but with no attributes then a generic rule allowing forwarding to any interface is added. If it is present and the 'dev' attribute is specific then forwarding is only allowed to that named interface. The default network XML thus now includes <forward/> So that by default we have a virtual network connected to all physical devices. - MAC addreses were not be autogenerated inside libvirt_qemud. If you don't provide a MAC address, QEMU (insanely) uses a hardcoded default. So all NICs end up with an identical MAC. We now always autogenerate a MAC address if not explicitly listed in XML. One final thing to be aware of - the Fedora Core 6 Xen kernel currently has totally fubar TCP checksum offland. So if you try to bridge a Xen guest into the libvirt virtual networking, it'll fail to get a DHCP address from dnsmasq. Even if you fix that by turning off TX checksums in Dom0, you'll get checksum failures for the actual TCP data transmission too. The only solution is to either upgrade the Dom0 kernel to a RHEL-5 vintage, or to also turn off checksumming in the guest. A new FC6 xen kernel is in the works which should hopefully fix this for real. With fixed kernel, I can easily setup virtual networks connecting both Xen PV, Xen FV and QEMU instances together. Anyway, the upshot of all this, is that we can now trivially create really complicated & fun networking layouts across QEMU & Xen, using a mixture of bridging, NAT, isolated LANs, and tunnelled VLANS :-) We really ought to document it a little though Since Mark is off on vacation for a while, I'd appreciate people taking a close look at this / actually giving it a try if you can. It is possible to create a totally isolated network using <network> <name>private</name> <uuid>d237ce44-8efa-452c-b8e6-1ae9cf53aeb1</uuid> <bridge name="virbr0" /> <ip address="192.168.122.1" netmask="255.255.255.0"> <dhcp> <range start="192.168.122.2" end="192.168.122.254" /> </dhcp> </ip> </network> And a QEMU guest with 5 (yes, 5) network cards <domain type='qemu'> <name>QEMUFirewall</name> <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> <memory>219200</memory> <currentMemory>219200</currentMemory> <vcpu>1</vcpu> <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> </os> <devices> <emulator>/usr/bin/qemu</emulator> <disk type='block' device='disk'> <source dev='/dev/HostVG/QEMUGuest1'/> <target dev='hda'/> </disk> <interface type='network'> <source network='private'/> <target dev='vnet1'/> </interface> <interface type='bridge'> <source dev='xenbr0'/> <target dev='vnet2'/> </interface> <interface type='ethernet'> <script path='/etc/dan-test-ifup'/> <target dev='vnet3'/> </interface> <interface type='server'> <source address="127.0.0.1" port="5555"/> </interface> <interface type='mcast'> <source address="230.0.0.1" port="5558"/> </interface> <graphics type='vnc' port='-1'/> </devices> </domain> In this XML, only eth1 is connected to the hosts public facing network. The other NICs are all on various private networks. So this QEMU guest is in essence a router/firewall box. eg, you could connected various other guests to the 'private' virtual network, and the only way they could reach the outside world is via this QEMU instance doing routing. 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 2

[Libvir] Turn on compiler buffer checks
by Daniel P. Berrange 21 Mar '07

21 Mar '07

Since testing the latest Fedora RPMs I've hit a number of buffer overflow issues which were caught by the extra compiler checks Fedora turns on. It would be much better if we caught these before release, so the attached patch modifies the configure script so that the following options are always turned on if the compiler supports them: -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables Since all our production builds use these flags & the patch only enables them if the compiler has support I don't see any issue with having them turned on by default. In addition I altered the existing configure compiler flag checks so that every compiler flag we turned on is explicitly checked to see if supported by the current compiler rather than doing a crude $CC=gcc heuristic which doesn't take account of differing gcc version numbers. If we wanted super-extra paranoia we could also turn on -fstack-protector-all possibly only with --enable-compiler-warnings=maximum since it adds more non-trivial performance overhead 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] Fix for buffer overflow in network setup
by Daniel P. Berrange 20 Mar '07

20 Mar '07

There was a buffer overflow in teh code to deal with building command line arguments which was only exposed when the Fedora RPM builds uses the stack protector args to GCC. The attached patch increases the buffer size and uses snprintf() instead of sprintf(). BTW, if anyone is looking for a patch to write - removing all other calls to sprintf() would be a worthy task :-) 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] [PATCH] Add error message to virsh setmem/setmaxmem
by Masayuki Sunou 20 Mar '07

20 Mar '07

Hi Virsh setmem/setmaxmem doesn't output an error message when an invalid value is set to "bytes". This patch outputs an error message, when an invalid value is set as "bytes" of virsh setmem/setmaxmem. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.66 diff -u -p -r1.66 virsh.c --- src/virsh.c 19 Mar 2007 14:20:30 -0000 1.66 +++ src/virsh.c 19 Mar 2007 23:29:14 -0000 @@ -1461,6 +1461,7 @@ cmdSetmem(vshControl * ctl, vshCmd * cmd bytes = vshCommandOptInt(cmd, "bytes", &bytes); if (bytes <= 0) { virDomainFree(dom); + vshError(ctl, FALSE, _("Invalid value of \"bytes\"")); return FALSE; } @@ -1504,6 +1505,7 @@ cmdSetmaxmem(vshControl * ctl, vshCmd * bytes = vshCommandOptInt(cmd, "bytes", &bytes); if (bytes <= 0) { virDomainFree(dom); + vshError(ctl, FALSE, _("Invalid value of \"bytes\"")); return FALSE; }

2 1

[Libvir] RPM upgrades interaction with default networking
by Daniel P. Berrange 20 Mar '07

20 Mar '07

I've been thinking about the tricky issue of RPM upgrades and how they interact with the new networking stuff and don't think we've currently got quite the optimal setup. The current approach is that 'make install' puts a default.xml file into /etc/libvirt/qemu/networks and also symlinks that file into the autostart directory. So if someone builds from tar.gz and does make install they'll get a default network config installed & turned on out of the box. This is fine for tar.gz scenario. When we build an RPM we also include the default.xml file in the /etc/libvirt/qemu/networks directory, as well as the autostart symlink. So anyone installing the libvirt RPM gets the default network, whether they're doing an upgrade or fresh install. This is reasonable for the new install, or the first time you upgrade to a new neworking-enabled libvirt. If you subsequently delete the default network, or turn off autostarting, then along comes the next libvirt RPM update and autostart gets turned back on, and/or the default network recreated. This will be considered to be rather unpleasant by many people because no matter what they do, they will always be given a virbr0, a dnsmasq process and a bunch of extra iptables rules whether they want them or not. So I think we need to figure out a way to deploy a default network out of the box, but at the same time ensure that if the turn it off / delete it, upgrades won't re-introduce it. Ideally if someone upgrades from FC6 -> FC7 they will also get the default network created (once only). One way we can address this is to put the default.xml into the docs directory /usr/share/doc/libvirt-X.Y.Z (or perhaps stuff is into a dir like /usr/share/libvirt instead) and then have a RPM %post script which copies it into /etc/libvirt/qemu/networks. If we make the %post script conditional on '$1 == 1' then it will only be run for completely new libvirt installs. This doesn't address the upgrade question though - so someone updating from FC6 -> FC7 won't get the default network. Perhaps we shouldn't worry about them ? 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 5

[Libvir] [PATCH] Check calls to printf-like functions (and some fixes)
by Richard W.M. Jones 20 Mar '07

20 Mar '07

* Check calls to printf-like functions (and some fixes) * Fix qemudDebug when debug not enabled * Fix TODO so it doesn't supply a semi-colon (and all calls to this macro) * Add vim/emacs local variables in several places AFAICS this doesn't break the Python API build script, which was the objection to Jim Meyerling's previous patch to do much the same (http://www.redhat.com/archives/libvir-list/2006-March/msg00065.html) Rich.

3 6

[Libvir] more printf-style function checking
by Jim Meyering 19 Mar '07

19 Mar '07

I had the first hunk of the following patch laying around, but when I updated/compiled today, it triggered a warning: virsh.c:3162: warning: format '%d' expects type 'int', but argument 6 has type 's ize_t' I've fixed it by using %lu, which is more likely to be the same width as size_t that %d, and by casting strlen's return val to the new, expected type. 2007-03-19 Jim Meyering <jim(a)meyering.net> Avoid printf-style format mismatch. * src/virsh.c (vshError): Use ATTRIBUTE_FORMAT. (_vshStrdup): Use %lu (not %d) for strlen, and cast the strlen return value to "unsigned long" to match the format. Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.65 diff -u -p -r1.65 virsh.c --- src/virsh.c 19 Mar 2007 09:46:13 -0000 1.65 +++ src/virsh.c 19 Mar 2007 14:03:10 -0000 @@ -179,8 +179,8 @@ typedef struct __vshControl { static vshCmdDef commands[]; -static void vshError(vshControl * ctl, int doexit, const char *format, - ...); +static void vshError(vshControl * ctl, int doexit, const char *format, ...) + ATTRIBUTE_FORMAT(printf, 3, 4); static int vshInit(vshControl * ctl); static int vshDeinit(vshControl * ctl); static void vshUsage(vshControl * ctl, const char *cmdname); @@ -3158,8 +3158,8 @@ _vshStrdup(vshControl * ctl, const char if ((x = strdup(s))) return x; - vshError(ctl, TRUE, _("%s: %d: failed to allocate %d bytes"), - filename, line, strlen(s)); + vshError(ctl, TRUE, _("%s: %d: failed to allocate %lu bytes"), + filename, line, (unsigned long)strlen(s)); return NULL; }

2 1

[Libvir] remove global variables from header files
by Jim Meyering 19 Mar '07

19 Mar '07

Hello, I compiled the latest-from-cvs libvirt and was surprised to see link failures. It was because I used -fno-common: .libs/libvirt_la-hash.o:(.bss+0x0): multiple definition of `virDomainFlags' .libs/libvirt_la-libvirt.o:(.bss+0x0): first defined here libvirt_qemud-buf.o:(.bss+0x0): multiple definition of `qemud_packet_type' libvirt_qemud-qemud.o:(.bss+0x0): first defined here libvirt_qemud-buf.o:(.bss+0x4): multiple definition of `qemud_domain_runstate' libvirt_qemud-qemud.o:(.bss+0x4): first defined here Those happen when more than one compilation unit contains a non-extern declaration of the same global variable. In each of the three cases, the name in question appears only at the point of declaration, so one could conceivably simply remove the name, leaving the anonymous "enum". But then there would be no way to declare a variable to be of that type, so I chose to reuse the name, making it the name of the enum. If name space pollution is an issue, and applications that use those headers won't need those types, then it'd be better to remove the names altogether. Here's a patch: 2007-03-19 Jim Meyering <jim(a)meyering.net> Remove global variables from header files. * qemud/protocol.h (qemud_domain_runstate): Declare a named enum and no variable, rather than a global variable of type "anonymous enum". (qemud_packet_type): Likewise. * src/internal.h (virDomainFlags): Likewise. Index: qemud/protocol.h =================================================================== RCS file: /data/cvs/libvirt/qemud/protocol.h,v retrieving revision 1.5 diff -u -p -r1.5 protocol.h --- qemud/protocol.h 15 Mar 2007 17:24:57 -0000 1.5 +++ qemud/protocol.h 19 Mar 2007 13:36:55 -0000 @@ -29,7 +29,7 @@ #include <net/if.h> /* for IF_NAMESIZE */ /* List of different packet types which can be sent */ -enum { +enum qemud_packet_type { QEMUD_PKT_FAILURE = 0, QEMUD_PKT_GET_VERSION, QEMUD_PKT_GET_NODEINFO, @@ -71,7 +71,7 @@ enum { QEMUD_PKT_GET_CAPABILITIES, QEMUD_PKT_MAX, -} qemud_packet_type; +}; #define QEMUD_PROTOCOL_VERSION_MAJOR 1 @@ -86,11 +86,11 @@ enum { #define QEMUD_MAX_ERROR_LEN 1024 /* Possible guest VM states */ -enum { +enum qemud_domain_runstate { QEMUD_STATE_RUNNING = 1, QEMUD_STATE_PAUSED, QEMUD_STATE_STOPPED, -} qemud_domain_runstate; +}; /* Each packets has at least a fixed size header. * Index: src/internal.h =================================================================== RCS file: /data/cvs/libvirt/src/internal.h,v retrieving revision 1.35 diff -u -p -r1.35 internal.h --- src/internal.h 16 Mar 2007 15:03:21 -0000 1.35 +++ src/internal.h 19 Mar 2007 13:36:55 -0000 @@ -155,10 +155,10 @@ struct _virConnect { * a set of special flag values associated to the domain */ -enum { +enum virDomainFlags { DOMAIN_IS_SHUTDOWN = (1 << 0), /* the domain is being shutdown */ DOMAIN_IS_DEFINED = (1 << 1) /* the domain is defined not running */ -} virDomainFlags; +}; /** * _virDomain:

2 1

[Libvir] [PATCH] Fix driver counting in virConnectOpen
by Atsushi SAKAI 19 Mar '07

19 Mar '07

Hi, I think virConnectOpen driver counting check is wrong. If we does not run libvirt_qemud, virsh does not run on root privilege. This restriction forces Xen user to run verbose libvirt_qemud. Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com> Thanks Atsushi SAKAI diff -urpN libvirt-0.2.1/src/libvirt.c libvirt-0.2.1.check/src/libvirt.c --- libvirt-0.2.1/src/libvirt.c 2007-03-16 01:45:36.000000000 +0900 +++ libvirt-0.2.1.check/src/libvirt.c 2007-03-19 18:37:22.000000000 +0900 @@ -322,7 +322,7 @@ virConnectOpen(const char *name) } } - if (ret->nb_drivers == 0 || ret->nb_network_drivers == 0) { + if (ret->nb_drivers == 0 && ret->nb_network_drivers == 0) { /* we failed to find an adequate driver */ virLibConnError(NULL, VIR_ERR_NO_SUPPORT, name); goto failed; @@ -389,7 +389,7 @@ virConnectOpenReadOnly(const char *name) ret->networkDrivers[ret->nb_network_drivers++] = virNetworkDriverTab[i]; } } - if (ret->nb_drivers == 0) { + if (ret->nb_drivers == 0 && ret->nb_network_drivers == 0) { if (name == NULL) virLibConnError(NULL, VIR_ERR_NO_CONNECT, _("Xen Daemon or Xen Store"));

2 1

[Libvir] [PATCH] Guard a negative value of "virsh setmem" and "virsh setmexmem"
by Masayuki Sunou 19 Mar '07

19 Mar '07

Hi "virsh setmem" and "virsh setmexmem" have the problem of setting a very big value in the domain when -1 is set in the domain. As a result, I detected the problem of doing abnormal operation of Xen in 64bit machine. (virsh setmem) Therefore, I contribute the patch that corrects the argument of the function to guard a negative value. This treatment is based on setMemoryTarget(a)XendDomainInfo.py. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. ------------------------------------------------------------------------------- Index: include/libvirt/libvirt.h =================================================================== RCS file: /data/cvs/libvirt/include/libvirt/libvirt.h,v retrieving revision 1.41 diff -u -p -r1.41 libvirt.h --- include/libvirt/libvirt.h 15 Mar 2007 17:24:57 -0000 1.41 +++ include/libvirt/libvirt.h 16 Mar 2007 01:37:25 -0000 @@ -314,9 +314,9 @@ int virDomainGetUUIDString (virDomainP char * virDomainGetOSType (virDomainPtr domain); unsigned long virDomainGetMaxMemory (virDomainPtr domain); int virDomainSetMaxMemory (virDomainPtr domain, - unsigned long memory); + int memory); int virDomainSetMemory (virDomainPtr domain, - unsigned long memory); + int memory); int virDomainGetMaxVcpus (virDomainPtr domain); /* Index: include/libvirt/libvirt.h.in =================================================================== RCS file: /data/cvs/libvirt/include/libvirt/libvirt.h.in,v retrieving revision 1.26 diff -u -p -r1.26 libvirt.h.in --- include/libvirt/libvirt.h.in 15 Mar 2007 17:24:57 -0000 1.26 +++ include/libvirt/libvirt.h.in 16 Mar 2007 01:37:26 -0000 @@ -314,9 +314,9 @@ int virDomainGetUUIDString (virDomainP char * virDomainGetOSType (virDomainPtr domain); unsigned long virDomainGetMaxMemory (virDomainPtr domain); int virDomainSetMaxMemory (virDomainPtr domain, - unsigned long memory); + int memory); int virDomainSetMemory (virDomainPtr domain, - unsigned long memory); + int memory); int virDomainGetMaxVcpus (virDomainPtr domain); /* Index: src/libvirt.c =================================================================== RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.63 diff -u -p -r1.63 libvirt.c --- src/libvirt.c 15 Mar 2007 17:24:57 -0000 1.63 +++ src/libvirt.c 16 Mar 2007 01:37:31 -0000 @@ -1499,7 +1499,7 @@ virDomainGetMaxMemory(virDomainPtr domai * Returns 0 in case of success and -1 in case of failure. */ int -virDomainSetMaxMemory(virDomainPtr domain, unsigned long memory) +virDomainSetMaxMemory(virDomainPtr domain, int memory) { int ret = -1 , i; virConnectPtr conn; @@ -1553,7 +1553,7 @@ virDomainSetMaxMemory(virDomainPtr domai * Returns 0 in case of success and -1 in case of failure. */ int -virDomainSetMemory(virDomainPtr domain, unsigned long memory) +virDomainSetMemory(virDomainPtr domain, int memory) { int ret = -1 , i; virConnectPtr conn; -------------------------------------------------------------------------------

2 3

[Libvir] [PATCH]Reprt error for a existing file
by Kazuki Mizushima 19 Mar '07

19 Mar '07

Hi, I make a patch which reports error for a existing file to prevent overwriting before the file. # ./virsh dump 1 a.dump error: file a.dump exists already # echo $? 1 # ./virsh save 1 a.save error: file a.save exists already # echo $? 1 As you know, we need to add this message item to libvirt/po. Signed-off-by: Kazuki Mizushima <mizushima.kazuk(a)jp.fujitsu.com> Thanks, Kazuki Mizushima Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.58 diff -u -p -r1.58 virsh.c --- src/virsh.c 2 Mar 2007 14:22:33 -0000 1.58 +++ src/virsh.c 5 Mar 2007 06:49:28 -0000 @@ -25,6 +25,7 @@ #include <getopt.h> #include <sys/types.h> #include <sys/time.h> +#include <sys/stat.h> #include <ctype.h> #include <fcntl.h> #include <locale.h> @@ -860,6 +861,7 @@ cmdSave(vshControl * ctl, vshCmd * cmd) virDomainPtr dom; char *name; char *to; + struct stat st; int ret = TRUE; if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) @@ -871,6 +873,11 @@ cmdSave(vshControl * ctl, vshCmd * cmd) if (!(dom = vshCommandOptDomain(ctl, cmd, "domain", &name))) return FALSE; + if (stat(to, &st) == 0){ + vshError(ctl, FALSE, _("file %s exists already"), to); + return FALSE; + } + if (virDomainSave(dom, to) == 0) { vshPrint(ctl, _("Domain %s saved to %s\n"), name, to); } else { @@ -942,6 +949,7 @@ cmdDump(vshControl * ctl, vshCmd * cmd) virDomainPtr dom; char *name; char *to; + struct stat st; int ret = TRUE; if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) @@ -953,6 +961,11 @@ cmdDump(vshControl * ctl, vshCmd * cmd) if (!(dom = vshCommandOptDomain(ctl, cmd, "domain", &name))) return FALSE; + if (stat(to, &st) == 0){ + vshError(ctl, FALSE, _("file %s exists already"), to); + return FALSE; + } + if (virDomainCoreDump(dom, to, 0) == 0) { vshPrint(ctl, _("Domain %s dumpd to %s\n"), name, to); } else {

3 8

[Libvir] Release of libvirt-0.2.1
by Daniel Veillard 16 Mar '07

16 Mar '07

A lot of work had accumulated in CVS, and it was really time for a new release, it's available from: ftp://libvirt.org/libvirt * Various internal cleanups (Richard Jones,Daniel Berrange,Mark McLoughlin) * Bug fixes: - libvirt_qemud daemon path (Daniel Berrange) - libvirt config directory (Daniel Berrange and Mark McLoughlin) - memory leak in qemud (Mark) - various fixes on network support (Mark) - avoid Xen domain zombies on device hotplug errors (Daniel Berrange) - various fixes on qemud (Mark) - argsparsing (Richard Jones) - virsh -t argument (Saori Fukuta) - avoid virsh crash on TAB key (Daniel Berrange) - detect xend operation failures (Kazuki Mizushima) - don't listen on null socket (Rich Jones) - read-only socket cleanup (Rich Jones) - use of vnc port 5900 (Nobuhiro Itou) - assorted networking fixes (Daniel Berrange) - shutoff and shutdown mismatches (Kazuki Mizushima) - unlimited memory handling (Atsushi SAKAI) - python binding fixes (Tatsuro Enokura) * Build and portability fixes: - IA64 fixes (Atsushi SAKAI) - dependancies and build (Daniel Berrange) - fix xend port detection (Daniel Berrange) - icompile time warnings (Mark) - avoid const related compiler warnings (Daniel Berrange) - automated builds (Daniel Berrange) - pointer/int mismatch (Richard Jones) - configure time selection of drivers - libvirt spec hacking (Daniel Berrange) * Add support for network autostart and init scripts (Mark McLoughlin) * New API virConnectGetCapabilities() to detect the virtualization capabilities of a host (Richard Jones) * Minor improvements: - qemud signal handling (Mark) - don't shutdown or reboot domain0 (Kazuki Mizushima) - QEmu version autodetection (Daniel Berrange) - network UUIDs (Mark) - speed up UUID domain lookups (Tatsuro Enokura and Daniel Berrange) - support for paused QEmu CPU (Daniel Berrange) - keymap VNC attribute support (Takahashi Tomohiro and Daniel Berrange) - maximum number of virtual CPU (Masayuki Sunou) - virtsh --readonly option (Rich Jones) - python bindings for new functions (Daniel Berrange) * Documentation updates especially on the XML formats Thanks to everybody who contributed to 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] [PATCH] Check calls to printf-like functions (and some fixes) (second version)
by Richard W.M. Jones 16 Mar '07

16 Mar '07

-- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 4

[Libvir] [PATCH] TODO macro shouldn't contain a semicolon
by Richard W.M. Jones 16 Mar '07

16 Mar '07

I don't think it's a good idea for macros which look like statements to behave differently from actual statements. This patch fixes the TODO macro in this way. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

1 0

[Libvir] libvirt.py has the two functions that names are the same.
by Tatsuro Enokura 16 Mar '07

16 Mar '07

Hi, When I used the lookupByName() function of libvirt.py, it failed with the following error messages. ------ Traceback (most recent call last): File "./virt-install.mod", line 569, in <module> main() File "./virt-install.mod", line 499, in main guest, hvm, conn) File "./virt-install.mod", line 187, in get_disks disk, size) File "./virt-install.mod", line 186, in <lambda> map(lambda d, s: get_disk(d, s, sparse, guest, hvm, conn), File "./virt-install.mod", line 131, in get_disk vm = conn.lookupByName(name) File "/usr/lib/python2.5/site-packages/libvirt.py", line 483, in lookupByName if ret is None:raise libvirtError('virNetworkLookupByName() failed', conn=self) libvirt.libvirtError: virNetworkLookupByName() failed ------ The lookupByName() function is the same name for domain and for network in libvirt.py. The lookupByUUIDstring() function is similar. I think that generator of libvirt.py's function is incorrect. Thanks, Tatsuro Enokura --- cat /usr/lib/python2.5/site-packages/libvirt.py .. snip .. def lookupByName(self, name): """Try to lookup a domain on the given hypervisor based on its name. """ ret = libvirtmod.virDomainLookupByName(self._o, name) if ret is None:raise libvirtError('virDomainLookupByName() failed', conn=self) __tmp = virDomain(_obj=ret) __tmp.ref = self return __tmp def lookupByName(self, name): """Try to lookup a network on the given hypervisor based on its name. """ ret = libvirtmod.virNetworkLookupByName(self._o, name) if ret is None:raise libvirtError('virNetworkLookupByName() failed', conn=self) __tmp = virNetwork(_obj=ret) __tmp.ref = self return __tmp def lookupByUUIDString(self, uuidstr): """Try to lookup a network on the given hypervisor based on its UUID. """ ret = libvirtmod.virNetworkLookupByUUIDString(self._o, uuidstr) if ret is None:raise libvirtError('virNetworkLookupByUUIDString() failed', conn=self) __tmp = virNetwork(_obj=ret) __tmp.ref = self return __tmp def lookupByUUIDString(self, uuidstr): """Try to lookup a domain on the given hypervisor based on its UUID. """ ret = libvirtmod.virDomainLookupByUUIDString(self._o, uuidstr) if ret is None:raise libvirtError('virDomainLookupByUUIDString() failed', conn=self) __tmp = virDomain(_obj=ret) __tmp.ref = self return __tmp .. snip .. --

2 3

[Libvir] [PATCH] Fix dom0 maxmem display for memmax not set case
by Atsushi SAKAI 16 Mar '07

16 Mar '07

Hi, This patch intends to fix dom0 maxmem display. If we do NOT set maximum memory, max_pages (in Xen) are set maximum value(0xFFFFFFFF). This display confuses user. For x86 cases, following data are shown on "virsh dominfo 0" (please case 4kb page size This case max_pages x 4 is output). Max memory: 4294967292 kB This patch fix as follows Max memory: no limit (This comment is taken from xentop :-)) This problem is already cared on xentop (Xen performance tool). Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com> Thanks Atsushi SAKAI diff -urpN libvirt.orig/src/virsh.c libvirt/src/virsh.c --- libvirt.orig/src/virsh.c 2007-03-09 22:44:24.000000000 +0900 +++ libvirt/src/virsh.c 2007-03-15 20:13:04.000000000 +0900 @@ -1186,8 +1186,13 @@ cmdDominfo(vshControl * ctl, vshCmd * cm vshPrint(ctl, "%-15s %.1lfs\n", _("CPU time:"), cpuUsed); } - vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"), + if (info.maxMem != UINT_MAX) + vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"), info.maxMem); + else + vshPrint(ctl, "%-15s %-15s\n", _("Max memory:"), + _("no limit")); + vshPrint(ctl, "%-15s %lu kB\n", _("Used memory:"), info.memory); diff -urpN libvirt.orig/src/xen_internal.c libvirt/src/xen_internal.c --- libvirt.orig/src/xen_internal.c 2007-03-15 16:43:16.000000000 +0900 +++ libvirt/src/xen_internal.c 2007-03-15 19:38:17.000000000 +0900 @@ -1598,7 +1598,9 @@ xenHypervisorGetDomInfo(virConnectPtr co */ info->cpuTime = XEN_GETDOMAININFO_CPUTIME(dominfo); info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * kb_per_pages; - info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo) * kb_per_pages; + info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo); + if(info->maxMem != UINT_MAX) + info->maxMem *= kb_per_pages; info->nrVirtCpu = XEN_GETDOMAININFO_CPUCOUNT(dominfo); return (0); }

2 3

[Libvir] [PATCH] Make libvirt build when xen-devel is not installed
by Hugh Brock 15 Mar '07

15 Mar '07

After the Capabilities patch went in, we discovered that although we could supposedly build libvirt without xen-devel installed, in fact we needed to be more aggressive with ifdefs (and conditionally turn off compilation of some tests that only test xen features). This patch makes it possible to compile libvirt with neither qemu nor xen-devel installed. Signed-off-by: Hugh Brock <hbrock(a)redhat.com> -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

2 1

[Libvir] virConnectGetCapabilities patch, 2007-03-15 (version 2)
by Richard W.M. Jones 15 Mar '07

15 Mar '07

This is the latest version of the capabilities patch, which should address all concerns which have been raised since the last version. Also attached, example XML produced by different backends. Note as before this has not been tested in the Xen case, because I don't have access to a working Xen machine (laptop still broken, desktop still lacking working SATA drivers, other desktop still lacking wired network...). Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759) <capabilities> <host> <cpu> <arch>x86_64</arch> </cpu> </host> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> <domain type="kqemu"/> <domain type="kvm"> <emulator>/usr/bin/qemu-kvm</emulator> </domain> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mips"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mips</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mipsel"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mipsel</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="sparc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-sparc</emulator> <domain type="qemu"/> <machine>sun4m</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="ppc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-ppc</emulator> <domain type="qemu"/> <machine>g3bw</machine> <machine>mac99</machine> <machine>prep</machine> </arch> </guest> </capabilities> <capabilities> <host> <cpu> <arch>x86_64</arch> </cpu> </host> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mips"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mips</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mipsel"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mipsel</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="sparc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-sparc</emulator> <domain type="qemu"/> <machine>sun4m</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="ppc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-ppc</emulator> <domain type="qemu"/> <machine>g3bw</machine> <machine>mac99</machine> <machine>prep</machine> </arch> </guest> </capabilities> <capabilities> <host> <cpu> <arch>i686</arch> <features> <pae/> <nonpae/> </features> </cpu> </host> <guest> <os_type>linux</os_type> <arch name="i686"> <wordsize>32</wordsize> <domain type="test"/> </arch> <features> <pae/> <nonpae/> </features> </guest> </capabilities>

1 0

[Libvir] Proposed XML format for capabilities, with examples [long]
by Richard W.M. Jones 15 Mar '07

15 Mar '07

Lots of people had various things to say about the first capabilities patches (see thread starting here: https://www.redhat.com/archives/libvir-list/2007-March/msg00153.html) So I thought I'd try to pull together ideas into a single thread, and post some information about what this is trying to achieve and some example proposed XML. Motivation ---------- At the moment there is a considerable amount of conditional code in libvirt clients. For example the following code from virt-manager (src/virtManager/create.py): if self.connection.get_type() == "QEMU": <------- 1 self.window.get_widget("virt-method-pv").set_sensitive(False) self.window.get_widget("virt-method-fv").set_active(True) self.window.get_widget("virt-method-fv-unsupported").hide() self.window.get_widget("virt-method-fv-disabled").hide() else: self.window.get_widget("virt-method-pv").set_sensitive(True) self.window.get_widget("virt-method-pv").set_active(True) if virtinst.util.is_hvm_capable(): <--------- 2 self.window.get_widget("virt-method-fv").set_sensitive(True) self.window.get_widget("virt-method-fv-unsupported").hide() self.window.get_widget("virt-method-fv-disabled").hide() This hopefully demonstrates two points which I'd like to fix: Firstly having code which requires knowledge of what a driver is capable of (line 1 above) is not scalable as we add more and more types of virtualisation (OpenVZ, VMWare, ...). Secondly the virtinst.util module does some probing to find out what the local hardware is capable of (line 2 above), and that won't work over remote connections. Thirdly, although you can only really connect to one driver at a time (except in the Xen case, but that's just weird), the <domain> description required by virDomainCreateLinux is to some extent driver-specific. So you need additional logic when creating domains, and for some of those (eg. qemu/kqemu/kvm) it's non-trivial and depends on information that you "just know" about the driver. The proposed new API ("virConnectGetCapabilities") would return an XML description of the capabilities of the driver / hypervisor. In the remote case, probing would be done on the remote machine. In either case the idea would be to remove conditional code from virt-manager, remove local hardware probing from virtinst, and provide some description of what optional features the <domain> XML supports. In the next two sections I'll analyse the problem areas in the current virtinst and virt-manager. You may want to skip the next two sections and go straight to the example XML. Analysis of virtinst -------------------- The main issue is with virtinst/util.py which contains the following functions which do local probing: (1) is_pae_capable: host supports PAE? Uses Linux-specific /proc/cpuinfo (2) is_hvm_capable: host supports HVM & enabled in Xen? Uses Xen-specific /sys/hypervisor/properties/capabilities (3) is_kqemu_capable: [Linux] kernel supports kqemu? Uses Linux-specific /dev/kqemu (4) is_kvm_capable: [Linux] kernel supports kvm? Uses Linux-specific /dev/kvm In virtinst/FullVirtGuest.py: (5) "emulator" and "loader" must be specified for Xen/QEMU and Xen guests respectively. They have architecture- and distro-specific paths which refer to files on the remote machine. In virtinst/ParaVirtGuest.py: (6) Uses "xm console" to connect to the console in the Xen case (but then this sort of paravirtualisation implies Xen). In virtinst/DistroManager.py: (7) We download the kernel and boot.iso files, and download and modify the initrd file. [Comment: I'm not sure that capabilities can solve this, but it does need to be fixed properly for the remote case to work]. Analysis of virt-manager ------------------------ In src/virtManager/create.py: (8) Tries to detect if VT-x/AMD-V is present in the hardware but disabled in the BIOS by doing some Xen-specific heuristics. (9) Paravirt and fullvirt dialogs are enabled based on the type of the connection (eg. if self.connection.get_type() == "QEMU" it disables paravirt). (10) CPU architecture combo box is enabled only for type == "QEMU". (11) Similarly, the "accelerate" checkbox is enabled only for type == "QEMU". [Comment: Dan tells me that this requirement comes about because kqemu is sometimes unreliable, so users need a way to disable it]. (12) Local media are required for FV installs. Also we use HAL to detect media inserted and removed. [Comment: Can be solved separately by abstracting storage]. In the *.glade files: (13) The list of CPU architectures for qemu is hard-coded in the interface description file. Other areas which are beyond the role of capabilities: * Remote console * Serial console * Saving images Proposed XML format ------------------- My thoughts are that capabilities need to return the following information about the underlying driver/hypervisor: * Host CPU flags (1,8) * List of guest architectures supported. For each of these: - Model of virtualised CPU (10,13) example: x86_64 - Name of the virtualised machine (if applic.) example: pc - Virtualised CPU features: PAE, ... - Fullvirt flag: can we run an unmodified OS as a guest? (2,9) or Paravirt: what sort of paravirt API does a guest need (eg. xen, pvops, VMI, ...)? - The <domain type='?'> for this guest example: kqemu - The <domain><os><type machine='?'> for this guest (if applic.) example: pc - Suggested emulator and loader paths (5) - Driver-specific flags which libvirt clients would not be required to understand, but could be used to enhance libvirt clients. examples: uses kqemu, uses kvm (3,4,11) (Notes: (a) I have flattened qemu's nested arch/machine list, because I there is not a natural hierarchy. (b) The guest architectures list is a Cartesian product, although at the moment the worst case (qemu) would only have about 14 entries. An alternate way to do this is discussed at the end. (c) The host CPU model is already provided by virNodeGetInfo). Example: Xen ------------ For Xen the primary source for capabilities are the files /sys/hypervisor/properties/capabilities and /proc/cpuinfo. A Xen driver might present the following description of its capabilities: <capabilities> <host> <cpu_flags> <cpu_flag> vmx </cpu_flag> <cpu_flag> pae </cpu_flag>  </cpu_flags> </host> <guest_architectures> <guest_architecture> <model> x86_64 </model> <paravirt> xen </paravirt> <domain_type> xen </domain_type> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <pae/> <paravirt> xen </paravirt> <domain_type> xen </domain_type> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <fullvirt/> <domain_type> xen </domain_type> <loader> /usr/lib/xen/boot/hvmloader </loader> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <pae/> <fullvirt/> <domain_type> xen </domain_type> <loader> /usr/lib/xen/boot/hvmloader </loader> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> x86_64 </model> <fullvirt/> <domain_type> xen </domain_type> <loader> /usr/lib/xen/boot/hvmloader </loader> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> </guest_architectures> </capabilities> Example: qemu + kqemu + kvm --------------------------- Qemu has by far the longest list of supported guest architectures. Out of the box it supports 10 distinct machine types and then you can add 4 extra machine types if the kernel can do kqemu and kvm, making 14 in all. Below I have abbreviated this list for clarity. <capabilities> <host> <cpu_flags> <cpu_flag> vmx </cpu_flag> <cpu_flag> pae </cpu_flag>  </cpu_flags> </host> <guest_architectures> <guest_architecture> <model> sparc </model> <machine> sun4m </machine> <fullvirt/> <domain_type> qemu </domain_type> <machine_type> sun4m </machine_type> <emulator> /usr/bin/qemu-system-sparc </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <machine> pc </machine> <fullvirt/> <domain_type> qemu </domain_type> <machine_type> pc </machine_type> <emulator> /usr/bin/qemu </emulator> </guest_architecture> <guest_architecture> <model> x86_64 </model> <machine> pc </machine> <fullvirt/> <domain_type> kqemu </domain_type> <machine_type> pc </machine_type> <emulator> /usr/bin/qemu </emulator> <qemu_uses_kqemu /> </guest_architecture> <guest_architecture> <model> x86_64 </model> <machine> pc </machine> <fullvirt/> <domain_type> kvm </domain_type> <machine_type> pc </machine_type> <emulator> /usr/bin/qemu-kvm </emulator> <qemu_uses_kvm /> </guest_architecture> </guest_architecture> </capabilities> Guest architectures: Cartesian product or UI builder? ----------------------------------------------------- Currently the list of guest architectures is a flat list, worst case 5 entries long for Xen and 14 entries long for qemu. Presenting this in user interfaces could be challenging. One suggestion is that the user interface looks like: [*] Show only fullvirt [*] Show only PC architectures [ ] Show 32 bit architectures [*] Show 64 bit architectures | Shorter list of architectures which match | the criteria checked above. | ... | Another is that we change the XML description so that it matches the UI. For instance: <guest_architecture> <models> <model> sparc </model> <model> ppc </model> ... Or: <pae> <can_enable/> <can_disable/> </pae> This is relatively easy to do with qemu, but the format of Xen's /sys/hypervisor/properties/capabilities makes it quite hard. i18n ---- Some proposed features may make translation challenging. For example qemu supports a whole list of machine types ("pc", "sun4m", etc.) and it would be nice for libvirt clients to be able to provide some sort of description for the user. It would not be wise to carry this description in the XML because it would not be possible to localise it. To avoid all libvirt clients duplicating and maintaining lists of machine types and descriptions, it may be worth adding a call to the API along the lines of: virConnectGetMachineDescription (const char *machine_name, const char *lang); (where lang == NULL would mean to use the current language). [EOF] -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

2 5

[Libvir] virConnectGetCapabilities patch, 2007-03-15
by Richard W.M. Jones 15 Mar '07

15 Mar '07

The latest version is attached. This should satisfy all concerns which have been raised with the previous versions. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

1 0

[Libvir] [PATCH]fix the judgment of the domain state between hypervisor and xend
by Kazuki Mizushima 15 Mar '07

15 Mar '07

Hi, According to the xm & virsh man page, I make a patch which fixes the judgment of the domain state between xenHypervisorDriver and xenDaemonDriver. Signed-off-by: Kazuki Mizushima <mizushima.kazuk(a)jp.fujitsu.com> Thanks, Kazuki Mizushima Index: xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.101 diff -u -p -r1.101 xend_internal.c --- xend_internal.c 8 Mar 2007 14:12:06 -0000 1.101 +++ xend_internal.c 14 Mar 2007 10:42:16 -0000 @@ -1722,9 +1722,9 @@ sexpr_to_xend_domain_info(virDomainPtr d if (strchr(flags, 'c')) info->state = VIR_DOMAIN_CRASHED; else if (strchr(flags, 's')) - info->state = VIR_DOMAIN_SHUTDOWN; - else if (strchr(flags, 'd')) info->state = VIR_DOMAIN_SHUTOFF; + else if (strchr(flags, 'd')) + info->state = VIR_DOMAIN_SHUTDOWN; else if (strchr(flags, 'p')) info->state = VIR_DOMAIN_PAUSED; else if (strchr(flags, 'b'))

2 2

[Libvir] [PATCH] modular compilation of xen/qemu/test
by Daniel Veillard 14 Mar '07

14 Mar '07

The following patch adds 3 configure options to turn on or off the support for Xen, QEMU/KVM and the test driver, as the output of configure --help shows: ... --with-xen add XEN support (on) --with-qemu add QEMU/KVM support (on) --with-test add test driver support (on) ... It uses compile time flags, is not really intrusive, it just pointed out a few strangeness, one of which was fixed (a Xen include) and the remaining ones are: - xml.c doesn't depend on Xen except for virDomainXMLDevID calling xenStoreDomainGetNetworkID() - libvirt.c still calls xenDaemonDomainLookupByName_ids from virDomainGetUUID() , I'm not sure if this can be avoided In the tests directory, sexpr2xmltest.c and xmconfigtest.c still depends on code in xen specific modules, trying to add them without xen being present was more complex than the value it may add (it also makes the patch smaller to cut at the module level). Plan to commit this before the release, unless this raises a problem, 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/

2 1