- Devel - libvirt List Archives

[libvirt] [PATCH] python: Raise exceptions if virDomain*Stats fail.
by Cole Robinson 24 Jul '09

24 Jul '09

The generator couldn't tell that the stats return values were pointers. Stick a white list in the function which tries to make this distinction. --- python/generator.py | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/python/generator.py b/python/generator.py index 9528839..feff7a3 100755 --- a/python/generator.py +++ b/python/generator.py @@ -683,7 +683,10 @@ functions_list_exception_test = { functions_list_default_test = "%s is None" def is_list_type (name): - return name[-1:] == "*" + whitelist = [ "virDomainBlockStats", + "virDomainInterfaceStats" ] + + return name[-1:] == "*" or name in whitelist def nameFixup(name, classe, type, file): # avoid a desastrous clash -- 1.6.0.6

2 1

[libvirt] [PATCH] document telnet serial console options
by Guido Günther 24 Jul '09

24 Jul '09

Hi, attached patch updates the console docs a bit. O.k. to apply? Cheers, -- Guido

2 1

Re: [libvirt] [PATCH 1/9] Add volume encryption information handling.
by Miloslav Trmac 24 Jul '09

24 Jul '09

----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > For the domain XML I agree that libirt would not need to worry about > multiple LUKS keys, but for the storage volume XML we would need to > expose the fact that there are multiple keys,or allow creation of > volumes with multiple keys. I don't know. Does a fact that a feature exist imply that libvirt must fully expose it? Any use case for multiple LUKS passphrases I can think of is a bit far-fetched. > > We know that the type and amount of information that will need to be > > stored will vary depending on the "encryption format"; on the other > > hand, expecting that the information consists of independent "secrets", > > each with a simple and format-independent definition, is probably too > > optimistic. (As mentioned above, we might need a key slot ID associated > > with a LUKS passphrase; we might also need a password hash algorithm > > associated with a dm-crypt passphrase. The encryption formats used in > > practice are often complex enough that a "simple passphrase" can not > > be used.) Once we have to assume that each secret can have an "encryption > > format"-dependent format, I think it is much clearer to use something like > > The idea of a 'key slot' and 'password hash algorithm' are not neccessarily > unique to LUKS though. No, but the specific semantics and value ranges are very likely to be different across formats. > If we get 2 different encryption formats both requiring > the concept of a 'key slot' we need to represent them in the same way in the > XML, not hve a different XML for each format. I was arguing about making the internal representation format-specific, not the XML. In the XML, having something like <secret type='...' id='...'> and <parameter name='...' id='...'> is quite reasonable. I think this is not the case in the internal representation - the information will eventually have to be "parsed" into format-specific variables, and it seems better to me to do this at once from the XML, than to create an additional internal representation and additionl "parsing" code. <snip> > The libvirt approach to XML representation is to try and define XML format > that are indenpedant of specific implementations. This does imply that the > XML parser cannot really do anything beyond basic syntactic validation, > near zero semantic validation. The task of semantic validation of the > parsed data, is thus passed off to the internal drivers which provide the > specific implementations. Not having any driver-specific knowledge in the generic parser does make sense; I'll change the code. Mirek

1 0

Re: [libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
by Miloslav Trmac 24 Jul '09

24 Jul '09

Daniel, thanks for the review. ----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > > New XML tags are defined to represent encryption parameters (currently > > format and passphrase, more can be added in the future), e.g. > > <encryption format='qcow'> > > <passphrase>c2lsbHk=</passphrase> > > </encryption> > > (passphrase content uses base64) > > I don't think we need 'format=qcow' in there - the guest XML already > has ability to have a <driver name='qemu' type='qcow2'/> element, > and the storage vol XML also has a <format type='qcow2'/> element. The format of encrypted data is conceptually separate from the format of the image: for example, a future LVM crypt implementation is planned that will support on-line encryption key change (re-encrypting the data without needing to stop its users). This can be naturally used on partitions, but it can also be used on a ("loopback-mounted") file stored on another filesystem - which is useful because this gives us on-line encryption key change capability for both partitions and files without creating two separate implementations of the functionality. (The same loopback setup could be done with LUKS today, although it is rather pointless.) So the fact that qemu treats the unencrypted file using the "raw" format does not imply that no encryption is used, or that any particular encryption implementation is used. For these reasons I think the encryption format should be explicitly specified. (The same information could be represented in the <driver> element, but there is currently no equivalent generic functionality for the <volume> element. It is also better to keep this information "within the <encryption> node", because this allows the "dumb" client discussed below to simply store the <encryption> node for each volume, and attach it inside <domain> descriptions, without any further understanding of the encryption format.) > I think it would be good to change the naming of the inner element > a little too. I think having it called 'secret' and then a 'type' > attribute would be a little nicer. eg > > <encryption> > <secret type='passphrase'/>c2lsbHk=</secret> > </encryption> OK, I'll change that. > It might be desirable to add encryption algorithm, but that can probably > wait since qcow doesn't support multiple algorithms at this time. Exactly. The expected content of the <encryption> element is "format"-specific. > > The <encryption> tag can be added to a <volume> node passed to > > virStorageVolCreateXML() to create an encrypted volume, or to a > > <disk> node inside a <domain> to specify what encryption parameters to > > use for a domain. If the domain is persistent, the parameters > > (including the passphrase) will be saved unencrypted in /etc/libvirtd; > > the primary use case is to store the parameters outside of libvirtd, > > (perhaps by virt-manager in a GNOME keyring). > > - Support for "dumb" clients that don't know anything about encryption > > formats and the required parameters: adding an encryption format to libvirt > > would automatically make it supported in all clients. > > > > Such a client would only request that a volume should be created when > > creating it, and libvirt would choose an appropriate format, parameters > > and passphrase/key and return it to the client, who could later pass it > > unmodified inside a <domain>. > > > > This requires public API additions to let libvirt return the encryption > > information as one of the results of a volume creation operation. > > > > - Support for storing the passphrases/keys used by persistent domains > > outside of the main XML files, e.g. in a separate passphrase-encrypted > > file that must be entered on libvirtd startup. > > I think these two points overlap quite alot. Not quite: the main case of a "dumb" client would be a large-scale virtualization management software that contains a primary store of encryption information, and gives each node access only to those keys that are currently necessary by the node to run its domains; the fact that each node has access to only a limited set of keys prevents an attacker that compromises a single node from reading disk images of all domains managed in the entire site, even if the disk image storage (e.g. unencrypted NFS) does not allow managing access by each node separately. Such a client must be able to transfer the actual secrets, not only identifiers, to libvirt. (The idea of a "dumb" client, that does not know the specifics of the format, is an additional feature on top, but one that implies that the client does send the actual secrets.) Storage of secrets in a separate keystore is more important for "local" libvirt deployments, where libvirt manages the primary, long-term, store of the secrets. > As you say there are two initial approaches to persistence of secrets > > - Keep the keys in the domain XML files > - Use a separate keystore > > For the separate keystore, there are probably 3 interesting targets > to consider > > 1. A simple text (or pkcs11) file managed by libvirtd on the host > > This would be useful for the privileged libvirtd to use in > ad-hoc, small scale deployments. Perhaps allowing it to be > shared between a small number of hosts on NFS, or GFS etc > > 2. A desktop key agent (eg gnome-keyring) > > This would be useful for the unprivileged libvirtd instances > that run in the context of the desktop login session. Users > already have SSH, GPG, website keys stored here, so having > keys for their VM disks is obviously desirable Another option here is to let the client store the secrets in gnome-keyring, and transfer them to libvirt only when starting a domain (especially when there are no persistent domains). That doesn't affect the design in any way, though. > 3. A off-node key management server > > This would be useful for a large scale data center / cluster > cloud deployment. This is good to allow management scalability > and better separation of responsiblities of adminstration. > > If no keystore is in use, then I clearly all keys must go in & out > of libvirt using the XML, which is pretty much what you're doing > in this series. I would say though, there is no point in clearing > the secret from the virStorageVolDefPtr instance/XML after volume > creation, since the secret is going to be kept in memory forever > for any guest using the volume. By not clearing the secret, an > app could create a volume, requesting automatic key generation, > then just do virStorageVolDumpXML(vol, VIR_STORAGE_VOL_XML_SECURE) > to extract it and pass to onto the XML for the guest that's created That is unreliable with current implementation, because a pool refresh creates all information about volumes anew by reading the volume files; therefore, after any pool refresh libvirt "forgets" the secrets directly associated with a volume (not secrets associated with an use of a volume in a domain). If client A creates a volume, client B can refresh the pool before client A is able to read the automatically generated secrets. One of the reasons the patch is clearing the information immediately is to make sure a {virStorageVolCreateXML; virStorageVolGetXMLDesc) always fails and no client is written depending on this racy operation sequence. There is another, more important, reason why the node should never return encryption data to anyone who can connect to it. Consider the above-described situation of a large-scale virtualization deployment that uses volume image encryption to restrict access of nodes to volume data: If domain migration is supported, the nodes (all of them, or at least nodes within some groups) must be able to connect "read-write" to other nodes. Yet, if the volume image encryption is to restrict access to volume data, such connections must not allow extracting encryption secrets, or any compromised node could simply ask the other nodes for their secrets and read the data. Thus, even a read-write connection should not allow any client to read secrets. I did not realize this when I started writing the original patches; I'll modify them not to allow returning the secrets using virDomainGetXMLDesc(), which is currently possible. The only potential exception is volume creation with secret auto-generation (not implemented in these patches), and in this case it is important to ensure that only the client that initiated the volume creation, not other clients, is can get the generated secrets. The most natural implementation would be a new operation (virStorageVolCreateXMLFromAndReturn???) that generates the secrets, creates the volume, and returns the secrets in a single step. In this scenario virStorageVolDumpXML does not need to return the secrets. > If a keystore is in use, then I'd suggest we should have explicit > APIs for secret management, As argued below, that might not be necessary, depending on the intended scope of libvirt. > and forbid the use of the actual secrets > in the XML everywhere. I wouldn't necessarily be that strict - if a centralized key management server is used by libvirt, it might still make sense for users to create one-off virtual machines that are encrypted, but not managed by the centralized infrastructure. > Instead, either pass in a pre-created key UUID when creating a volume > or defining a guest eg, the XML fragment would look like this > > <encryption> > <secret type='keyuuid'>123456-1234-1245-1234-124512345</secret> > </encryption> > > Internally libvirt would then get the real passphrase from the keystore > by looking up the associated UUID. > > Or request auto-creation of a key by leaving out the data > > <encryption> > <secret type='keyuuid'/> > </encryption> > > Internally libvirt would add a key to its database, and fillin the UUID > which you could then see via DumpXML. > > With a keystore we'd likely need a handful of APIs > > - create a secret providing a passphrase > - list all known secret UUIDs > - get the passphrase assoicated with a secret > - delete a secret based on UUID > - lookup a secret UUID based on the a disk path We might not need all of these. There are three main use cases for storing keys outside of XML: 1) This is a "small-scale deployment", where libvirt is the primary key store, and anyone that is able to connect to libvirtd is implicitly allowed to use the secrets. In this case the keystore can be managed completely automatically - creating a volume, or perhaps using it for the first time, implies storing a secret, and deleting a volume implies deleting a secret. Secrets are identified using a volume-unique object (is that a path, or an UUID?), which is completely transparent to the client. As long as the volume is "known" to libvirt, the client does not even need to specify any <encryption> element when creating a domain. (1a, a "small-scale deployment" where there are multiple clients that should be protected against each other, and libvirt is the primary key store, does not make sense unless a client account system is added to libvirt. If libvirt can not distinguish between different client accounts, it can only restrict access to secrets by insisting that the client specifies a keyuuid - but the client will need to store the keyuuid values and protect them exactly as if they were the "real" secrets; the client can just as easily store the "real" secrets and skip using keyuuids altogether.) 2) The secrets are primarily stored outside libvirt (to restrict node access to image data), and libvirt stores only secrets for currently defined persistent domains (to support domain autostart). In this case the keystore can be managed completely automatically - persistent domain definition implies storing a secret, deleting the domain implies deleting a secret. Secrets are identified using a (domain, volume) pair, and this identifier is never exposed to the client. 3) An external key store (such as a KMIP server) is used. In this case the management of access rights, listing and deleting secrets, would be performed by interacting with the external key store directly. Secrets are identified by using the external key store identifiers, and the client and libvirtd send these identifiers to each other. The above seems to indicate the only operations libvirt needs from a keystore are: - generate a UUID (in a keystore-specific format) - store a secret using a specified UUID - get secret associated with an UUID - delete a secret associated with an UUID. The first two operations could perhaps be combined, depending on the specifics of the external key store (e.g. the client might want to allocate an UUID so that the client, not the node, is the "owner" of the UUID, grant the node access to the UUID, and let the node create a volume and store the secret in the UUID). > The nice thing about separating the passphrases out of the XML completely > is that we would then have the ability to do fine grained access control. > eg, you could give people ability to create new guests / volumes, using > encryption without them ever specifying, or having access to the secrets. > A seperate role could be given ability to create/list/delete secrets. > This would also let us associate one secret with many disks, which > might be a useful scenario for some people. AFAICS libvirt does not currently have the concept of an "user"; as described above, such features can be handled in an external key store. If you plan to add the "user" concept to libvirt, this would definitely make sense. Mirek

2 1

[libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
by Miloslav Trmač 24 Jul '09

24 Jul '09

Hello, the following patches add full support for qcow/qcow2 volume encryption, assuming a client that supports it. New XML tags are defined to represent encryption parameters (currently format and passphrase, more can be added in the future), e.g. <encryption format='qcow'> <passphrase>c2lsbHk=</passphrase> </encryption> (passphrase content uses base64) The <encryption> tag can be added to a <volume> node passed to virStorageVolCreateXML() to create an encrypted volume, or to a <disk> node inside a <domain> to specify what encryption parameters to use for a domain. If the domain is persistent, the parameters (including the passphrase) will be saved unencrypted in /etc/libvirtd; the primary use case is to store the parameters outside of libvirtd, (perhaps by virt-manager in a GNOME keyring). Possible enhancements: - Documentation and test cases. I'll write both if the code is acceptable, I wanted to make the code available for review first. - Support for "dumb" clients that don't know anything about encryption formats and the required parameters: adding an encryption format to libvirt would automatically make it supported in all clients. Such a client would only request that a volume should be created when creating it, and libvirt would choose an appropriate format, parameters and passphrase/key and return it to the client, who could later pass it unmodified inside a <domain>. This requires public API additions to let libvirt return the encryption information as one of the results of a volume creation operation. - Support for storing the passphrases/keys used by persistent domains outside of the main XML files, e.g. in a separate passphrase-encrypted file that must be entered on libvirtd startup.

3 25

Re: [libvirt] [PATCH 2/9] Attach encryption information to virStorageVolDef.
by Daniel P. Berrange 24 Jul '09

24 Jul '09

On Fri, Jul 24, 2009 at 12:19:22AM -0400, Miloslav Trmac wrote: > ----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > > > On Tue, Jul 21, 2009 at 01:11:58PM +0200, Miloslav Trma?? wrote: > > > Note that partial encryption information (e.g. specifying an encryption > > > format, but not the key/passphrase) is valid: > > > * virStorageVolGetXMLDesc() will never reveal the key/passphrase, even > > > if known by libvirt. > > > > I don't think that restriction really adds anything in the scenario > > that we're using domain XML files for persistent storage of keys. > > The patches leave this decision to the client: the client might decide > not to use persistent domains. In any case, allowing the node to store > the secrets locally does not imply that anyone that can connect to the > node read-write can access the secrets - or does it? In general all libvirt clients have the same privileges, the only restriction being local read-only clients. Basically if a client authenticates read-write then they can access / modify all objects managed on that host. In the future we will introduce fine grained access control down to a level of (user, object, operation). > > eg, if domain XML lets you see passphrases, then vol XML should > > too (given a suitable VIR_STORAGE_VOL_SECURE flag). > > Domain XML should not allow returning the secrets either, because domain > migration lets other nodes connect read-write - see [0/9] for more details. We have to allow returning the secrets, because clients need to be able to round-trip the XML without loosing data, eg xml = virDomainGetXMLDesc(dom, VIR_DOMAIN_XML_INACTIVE | VIR_DOMAIN_XML_SECURE) ...modify xml... virDomainDefineXML(conn, xml) must not loose any data, including the secrets. > > > * Future mechanisms could be set up to allow a libvirt user to specify > > > during volume creation that a volume should be encrypted, leaving > > > libvirt to choose suitable parameters and key and return them: > > > this would allow the libvirt user to automatically support any > > > encryption parameters (and perhaps encryption formats) supported in > > > libvirt, as long as the user can send the same information back when > > > using the volume in the future. > > > > We could allow this now without extra APIs, if we let virStorageVolGetXML > > show the ke/passphrase given a new VIR_STORAGE_VOL_SECURE flag. > > That is racy with respect to pool refresh, and gives other clients than > the node creator (again, other nodes) access to the secrets - again, > see [0/9]. Allowing other clients access to the secrets is fine - all authenticated clients are considered equal. We shouldn't try to define restrictions on this specifically for disk encryption, as fine grained per-client access control will be introduced across the whole of libvirt at a later date. There is a small race wrt to pool refresh, however, in the scenario of not using a keystore, this is an acceptable limitation IMHO. If using a keystore, then libvirt can associate a key ID with a volume and maintain that mapping long term, and reliably pass the actual secrets about internally. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

1 0

[libvirt] [PATCH] docs: say that the old repository is deprecated...
by Jim Meyering 24 Jul '09

24 Jul '09

I've just officially deprecated the original cvs-to-git-mirror libvirt repository on et.redhat.com, by git-removing all files and adding one with a pointer to the new repository: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=2940bc0fa9f2a3 Here's the corresponding change to update libvirt's web documentation: >From 521ac5174827400804d33e219ce02e6bd3da1089 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Fri, 24 Jul 2009 10:57:39 +0200 Subject: [PATCH] docs: say that the old repository is deprecated... * docs/downloads.html.in: but will remain for sake of old links. --- docs/downloads.html.in | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/downloads.html.in b/docs/downloads.html.in index 0d2adb4..a34ddd1 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -74,9 +74,10 @@ <p> Jim Mereying was maintaining a CVS to git mirror on <a href="http://git.et.redhat.com/?p=libvirt.git">git.et.redhat.com</a>. - Existing users should migrate to the new git server, as the - old one will be deprecated and turned into a mirror of the - libvirt.org one. It's available as: + Existing users should migrate to the new libvirt.org git server, as the + old one is now deprecated. For the sake of old links including now- + rewritten SHA1s, we'll leave the old repository on-line for some time. + It is available as: </p> <pre> -- 1.6.4.rc2.182.g24de1

2 2

[libvirt] OpenVZ : cannot assign bridge to any interface
by Yuji NISHIDA 24 Jul '09

24 Jul '09

Hi, I'm bit confuing between 2 problems with libvirt-0.6.5 for OpenVZ. [1] bridge was created but no interface assigned to it [2] virsh dumpxml returns xml in which type is "qemu" [1] ------------------------------------------------- I tried libvirt-0.6.5 on Fedora8 to create OpenVZ container ( OpenVZ kernel is linux-2.6.18 ). A bridge was seemed to successfully create but no interface could not be assigned to the bridge. Due to that, ping could not reach the guest in container(10.0.1.2). ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ [root@node13 test]# brctl show bridge name bridge id STP enabled interfaces br101 8000.000000000000 no [root@node13 test]# ifconfig -a br101 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:10.0.1.1 Bcast:10.0.1.15 Mask:255.255.255.240 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:5031 (4.9 KiB) eth0 Link encap:Ethernet HWaddr 00:1C:C4:xx:xx:xx inet addr:133.xx.xx.xx Bcast:133.xx.xx.xx Mask:255.255.255.0 inet6 addr: fe80::21c:c4ff:xxxx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:196949 errors:0 dropped:0 overruns:0 frame:0 TX packets:64300 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:228373526 (217.7 MiB) TX bytes:5652593 (5.3 MiB) Interrupt:169 eth1 Link encap:Ethernet HWaddr 00:1C:C4:xx:xx:xx BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:50 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:323 errors:0 dropped:0 overruns:0 frame:0 TX packets:323 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:29949 (29.2 KiB) TX bytes:29949 (29.2 KiB) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth101 Link encap:Ethernet HWaddr 52:54:00:52:C3:FF inet6 addr: fe80::5054:ff:fe52:c3ff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ The followings are python script and xml that I tested with. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ [root@node13 test]# cat test.py import libvirt conn = libvirt.open('openvz:///system') conn.networkDefineXML( file('net.xml').read() ) conn.defineXML( file('test.xml').read() ) net = conn.networkLookupByName('guestnet101') net.create() guest = conn.lookupByName('101') guest.create() [root@node13 test]# cat test.xml <domain type='openvz' id='101'> <name>101</name> <os> <type>exe</type> <init>/sbin/fakeinit.sh</init> </os> <memory>524288</memory> <devices> <filesystem type='template'> <source name='fedora-10-x86_64'/> <target dir='/'/> </filesystem> <console type='pty'/> <interface type='bridge'> <mac address="52:54:00:00:01:01" /> <source bridge='guestnet101'/> <target dev='veth101'/> </interface> </devices> </domain> [root@node13 test]# cat net.xml <network> <name>guestnet101</name> <bridge name="br101" stp="off" /> <forward mode="nat"/> <ip address="10.0.1.1" netmask="255.255.255.240"> <dhcp> <range start="10.0.1.2" end="10.0.1.2" /> </dhcp> </ip> </network> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ [2] ------------------------------------------------- I guess "type" in domain must be 'openvz' but virsh dumpxml returns it as 'qemu'. ( The configuration of VE 101 remains in [1] ) ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ [root@node13 test]# virsh dumpxml 101 <domain type='qemu' id='101'> <name>101</name> <uuid>dedee02b-b74f-6e43-f5ec-27050986efa8</uuid> <memory>0</memory> <currentMemory>0</currentMemory> <vcpu>1</vcpu> <os> <type>exe</type> <init>/sbin/init</init> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <devices> <filesystem type='template'> <source name='fedora-10-x86_64'/> <target dir='/'/> </filesystem> <interface type='bridge'> <mac address='52:54:00:00:01:01'/> <source bridge='guestnet101'/> <target dev='veth101'/> </interface> </devices> </domain> [root@node13 test]# virsh net-dumpxml guestnet101 <network> <name>guestnet101</name> <uuid>5462e7a5-2048-3067-af9d-b134381a3f8a</uuid> <forward mode='nat'/> <bridge name='br101' stp='off' forwardDelay='0' /> <ip address='10.0.1.1' netmask='255.255.255.240'> <dhcp> <range start='10.0.1.2' end='10.0.1.2' /> </dhcp> </ip> </network> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Regards. ----- Yuji Nishida nishidy(a)nict.go.jp

3 3

[libvirt] How to call QEMU with -snapshot ?
by Jun Koi 24 Jul '09

24 Jul '09

Hi, I want to execute qemu (actually is KVM, qemu-system_x86-64) with -snapshot. Is there any way to do that? I tried following ways, and none works: - Put -snapshot in <emulator> in configuration file. - Create a script calling "qemu -snapshot", and rename it to qemu-system_x86-64 (and of course i rename the original one to smt else, and let my scrip call that) In all these cases, I got error about parsing for QEMU version. Thanks, J

1 0

Re: [libvirt] [PATCH 9/9] Add support for qcow encrypted volumes to qemu.
by Miloslav Trmac 24 Jul '09

24 Jul '09

----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > On Tue, Jul 21, 2009 at 01:12:05PM +0200, Miloslav Trma?? wrote: > > --- > > src/qemu_driver.c | 51 > ++++++++++++++++++++++++++++++++++++++++++++++++++- > > 1 files changed, 50 insertions(+), 1 deletions(-) > > IIUC this should only be needed when starting a QEMU guest. > > The 'cont' method is called from quite a few different contexts. > So it might be nice to pass a flag down from qemudStartVMDaemon > such that the passphrase handling is guarenteed to only be run > during startup (qemudStartVMDaemon is also used for migrate > and restore, so covers those scenarios OK) qemudStartVMDaemon is called during migration (and restore), but it does not sent "cont". The only place where "cont" is sent where passphrase handling is not necessary is qemudDomainResume. In any case, the passphrase handling only does something if qemu prompts for a passphrase, it does not hurt anything in other cases - on the contrary, should something go wrong and qemu would prompt for a passphrase, this ensures libvirt either supplies a passphrase, or reports an error, instead of hanging. Mirek

1 0

[libvirt] [PATCH] Add bare %s format string to printf-derivatives called with no format string
by Laine Stump 23 Jul '09

23 Jul '09

--- src/datatypes.c | 24 ++++++++++++------------ src/domain_conf.c | 9 +++++---- src/interface_conf.c | 4 ++-- src/lxc_driver.c | 2 +- src/qemu_driver.c | 4 ++-- src/storage_backend.c | 6 +++--- src/virsh.c | 4 ++-- 7 files changed, 27 insertions(+), 26 deletions(-) diff --git a/src/datatypes.c b/src/datatypes.c index 1e33ccb..8b3f8c3 100644 --- a/src/datatypes.c +++ b/src/datatypes.c @@ -289,7 +289,7 @@ virGetDomain(virConnectPtr conn, const char *name, const unsigned char *uuid) { if (virHashAddEntry(conn->domains, name, ret) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("failed to add domain to connection hash table")); + "%s", _("failed to add domain to connection hash table")); goto error; } conn->refs++; @@ -330,7 +330,7 @@ virReleaseDomain(virDomainPtr domain) { if (virHashRemoveEntry(conn->domains, domain->name, NULL) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("domain missing from connection hash table")); + "%s", _("domain missing from connection hash table")); conn = NULL; } @@ -430,7 +430,7 @@ virGetNetwork(virConnectPtr conn, const char *name, const unsigned char *uuid) { if (virHashAddEntry(conn->networks, name, ret) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("failed to add network to connection hash table")); + "%s", _("failed to add network to connection hash table")); goto error; } conn->refs++; @@ -468,7 +468,7 @@ virReleaseNetwork(virNetworkPtr network) { if (virHashRemoveEntry(conn->networks, network->name, NULL) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("network missing from connection hash table")); + "%s", _("network missing from connection hash table")); conn = NULL; } @@ -603,7 +603,7 @@ _("Failed to change interface mac address from %s to %s due to differing lengths if (virHashAddEntry(conn->interfaces, name, ret) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("failed to add interface to connection hash table")); + "%s", _("failed to add interface to connection hash table")); goto error; } conn->refs++; @@ -642,7 +642,7 @@ virReleaseInterface(virInterfacePtr iface) { /* unlock before reporting error because error report grabs lock */ virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("interface missing from connection hash table")); + "%s", _("interface missing from connection hash table")); /* don't decr the conn refct if we weren't connected to it */ conn = NULL; } @@ -744,7 +744,7 @@ virGetStoragePool(virConnectPtr conn, const char *name, const unsigned char *uui if (virHashAddEntry(conn->storagePools, name, ret) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("failed to add storage pool to connection hash table")); + "%s", _("failed to add storage pool to connection hash table")); goto error; } conn->refs++; @@ -783,7 +783,7 @@ virReleaseStoragePool(virStoragePoolPtr pool) { if (virHashRemoveEntry(conn->storagePools, pool->name, NULL) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("pool missing from connection hash table")); + "%s", _("pool missing from connection hash table")); conn = NULL; } @@ -887,7 +887,7 @@ virGetStorageVol(virConnectPtr conn, const char *pool, const char *name, const c if (virHashAddEntry(conn->storageVols, key, ret) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("failed to add storage vol to connection hash table")); + "%s", _("failed to add storage vol to connection hash table")); goto error; } conn->refs++; @@ -927,7 +927,7 @@ virReleaseStorageVol(virStorageVolPtr vol) { if (virHashRemoveEntry(conn->storageVols, vol->key, NULL) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("vol missing from connection hash table")); + "%s", _("vol missing from connection hash table")); conn = NULL; } @@ -1023,7 +1023,7 @@ virGetNodeDevice(virConnectPtr conn, const char *name) if (virHashAddEntry(conn->nodeDevices, name, ret) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("failed to add node dev to conn hash table")); + "%s", _("failed to add node dev to conn hash table")); goto error; } conn->refs++; @@ -1061,7 +1061,7 @@ virReleaseNodeDevice(virNodeDevicePtr dev) { if (virHashRemoveEntry(conn->nodeDevices, dev->name, NULL) < 0) { virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, - _("dev missing from connection hash table")); + "%s", _("dev missing from connection hash table")); conn = NULL; } diff --git a/src/domain_conf.c b/src/domain_conf.c index fbe9d78..96cadd5 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -2189,7 +2189,7 @@ virSecurityLabelDefParseXML(virConnectPtr conn, VIR_FREE(p); if (def->seclabel.type < 0) { virDomainReportError(conn, VIR_ERR_XML_ERROR, - _("invalid security type")); + "%s", _("invalid security type")); goto error; } @@ -2211,7 +2211,7 @@ virSecurityLabelDefParseXML(virConnectPtr conn, VIR_SECURITY_LABEL_BUFLEN-1, ctxt); if (p == NULL) { virDomainReportError(conn, VIR_ERR_XML_ERROR, - _("security label is missing")); + "%s", _("security label is missing")); goto error; } @@ -2224,8 +2224,9 @@ virSecurityLabelDefParseXML(virConnectPtr conn, p = virXPathStringLimit(conn, "string(./seclabel/imagelabel[1])", VIR_SECURITY_LABEL_BUFLEN-1, ctxt); if (p == NULL) { - virDomainReportError(conn, VIR_ERR_XML_ERROR, - _("security imagelabel is missing")); + +virDomainReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("security imagelabel is missing")); goto error; } def->seclabel.imagelabel = p; diff --git a/src/interface_conf.c b/src/interface_conf.c index 7da1a2f..a74d17e 100644 --- a/src/interface_conf.c +++ b/src/interface_conf.c @@ -601,7 +601,7 @@ virInterfaceDefParseXML(virConnectPtr conn, xmlXPathContextPtr ctxt) { tmp = virXPathString(conn, "string(./@type)", ctxt); if (tmp == NULL) { virInterfaceReportError(conn, VIR_ERR_XML_ERROR, - _("interface misses the type attribute")); + "%s", _("interface misses the type attribute")); return(NULL); } type = virInterfaceTypeFromString(tmp); @@ -643,7 +643,7 @@ virInterfaceDefParseXML(virConnectPtr conn, xmlXPathContextPtr ctxt) { bridge = virXPathNode(conn, "./bridge[1]", ctxt); if (bridge == NULL) { virInterfaceReportError(conn, VIR_ERR_XML_ERROR, - _("bridge interface misses the bridge element")); + "%s", _("bridge interface misses the bridge element")); goto error; } tmp = virXMLPropString(bridge, "stp"); diff --git a/src/lxc_driver.c b/src/lxc_driver.c index 3503573..66cfa8e 100644 --- a/src/lxc_driver.c +++ b/src/lxc_driver.c @@ -102,7 +102,7 @@ static virDrvOpenStatus lxcOpen(virConnectPtr conn, /* URI was good, but driver isn't active */ if (lxc_driver == NULL) { lxcError(conn, NULL, VIR_ERR_INTERNAL_ERROR, - _("lxc state driver is not active")); + "%s", _("lxc state driver is not active")); return VIR_DRV_OPEN_ERROR; } } diff --git a/src/qemu_driver.c b/src/qemu_driver.c index c4683ae..3b56092 100644 --- a/src/qemu_driver.c +++ b/src/qemu_driver.c @@ -1599,7 +1599,7 @@ static int qemudSecurityHook(void *data) { if (qemudDomainSetSecurityLabel(h->conn, h->driver, h->vm) < 0) { qemudReportError(h->conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _("Failed to set security label")); + "%s", _("Failed to set security label")); return -1; } @@ -3592,7 +3592,7 @@ static int qemudDomainGetSecurityLabel(virDomainPtr dom, virSecurityLabelPtr sec if (driver->securityDriver && driver->securityDriver->domainGetSecurityLabel) { if (driver->securityDriver->domainGetSecurityLabel(dom->conn, vm, seclabel) == -1) { qemudReportError(dom->conn, dom, NULL, VIR_ERR_INTERNAL_ERROR, - _("Failed to get security label")); + "%s", _("Failed to get security label")); goto cleanup; } } diff --git a/src/storage_backend.c b/src/storage_backend.c index 67815d7..9f2dcca 100644 --- a/src/storage_backend.c +++ b/src/storage_backend.c @@ -423,7 +423,7 @@ virStorageBackendCreateQemuImg(virConnectPtr conn, use_kvmimg = 0; else { virStorageReportError(conn, VIR_ERR_INTERNAL_ERROR, - _("unable to find kvm-img or qemu-img")); + "%s", _("unable to find kvm-img or qemu-img")); return -1; } @@ -485,9 +485,9 @@ virStorageBackendCreateQcowCreate(virConnectPtr conn, return -1; } if (vol->backingStore.path != NULL) { - virStorageReportError(conn, VIR_ERR_NO_SUPPORT, + virStorageReportError(conn, VIR_ERR_NO_SUPPORT, "%s", _("copy-on-write image not supported with " - "qcow-create")); + "qcow-create")); return -1; } diff --git a/src/virsh.c b/src/virsh.c index fff73a1..4499aca 100644 --- a/src/virsh.c +++ b/src/virsh.c @@ -4869,7 +4869,7 @@ cmdVolClone(vshControl *ctl, const vshCmd *cmd) origpool = virStoragePoolLookupByVolume(origvol); if (!origpool) { - vshError(ctl, FALSE, _("failed to get parent pool")); + vshError(ctl, FALSE, "%s", _("failed to get parent pool")); goto cleanup; } @@ -6583,7 +6583,7 @@ cmdCd(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED) int found; if (!ctl->imode) { - vshError(ctl, FALSE, _("cd: command valid only in interactive mode")); + vshError(ctl, FALSE, "%s", _("cd: command valid only in interactive mode")); return -1; } -- 1.6.0.6

3 3

[libvirt] [PATCH 0/8] Support cgroups in QEMU driver (v2)
by Daniel P. Berrange 23 Jul '09

23 Jul '09

This is an updated series of the v1 patches here: http://www.redhat.com/archives/libvir-list/2009-July/msg00435.html I have re-ordered the patches a little to put the generic refactoring all first. I identified some bugs in the existing LXC driver schedular parameter handling which I fixed. Also fixed virsh to use the correct data types when setting schedular parameters instead of hardcoding a bogus type. Finally, I've made QEMU's use of cgroups configurable. Daniel P. Berrange (8): Use enums for cgroup controller types / labels Use virFileReadAll/virFileWriteStr for key cgroup read/write helpers Make cgroups a little more efficient Refactor cgroups to allow a group per driver to be managed directly Place every QEMU guest in a private cgroup Implement schedular tunables API using cgroups Use cgroups for block device whitelisting in QEMU guests Make QEMU cgroups use configurable qemud/libvirtd_qemu.aug | 2 + qemud/test_libvirtd_qemu.aug | 21 +- src/Makefile.am | 3 +- src/cgroup.c | 867 +++++++++++++++++++++++------------------- src/cgroup.h | 42 ++- src/libvirt_private.syms | 2 + src/lxc_conf.h | 2 + src/lxc_controller.c | 19 +- src/lxc_driver.c | 34 ++- src/qemu.conf | 34 ++ src/qemu_conf.c | 61 +++ src/qemu_conf.h | 5 + src/qemu_driver.c | 399 +++++++++++++++++++- src/util.c | 47 +++- src/util.h | 5 + src/virsh.c | 232 +++++++----- 16 files changed, 1237 insertions(+), 538 deletions(-)

2 18

[libvirt] clone memory leak and libvirt connection selection
by Johnny Luong 23 Jul '09

23 Jul '09

Hi, I'm trying to use libvirt-0.6.5 within a multithreaded application without libvirtd and from what it looks like, it appears to have two things that are somewhat undesirable: 1) It tries to connect to libvirtd which isn't running. But it does eventually connect to the hypervisor. 2) It appears to leak some memory within a readonly connect and close. This is not too bad but it would be an issue in my long lived daemon application. I've attached an example program illustrating the issue with the linker log and the log from valgrind showing the memory leak. The code itself is based off the one on the website. Is there a URI I can use to avoid the connection to the libvirtd daemon while still connecting to the xendstore and is the memory leak an issue with the application environment or the library? Let me know if you need any more information. Thanks, Johnny

2 1

[libvirt] [PATCH 0/2] Add some more features to LXC driver
by Daniel P. Berrange 23 Jul '09

23 Jul '09

This patch series simply adds a couple of easy features to the LXC driver. Daniel P. Berrange (2): Add domain events support to LXC driver Add domain autostart for LXC driver src/lxc_conf.h | 7 + src/lxc_driver.c | 365 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 367 insertions(+), 5 deletions(-)

2 6

[libvirt] MemoryPeek() is slow
by Jun Koi 23 Jul '09

23 Jul '09

Hi, I play around with MemoryPeek() API on QEMU. While it works well, I found that it is too slow. That is expected because of the way it works: we always need to save memory to a file, and read it in again, and that is too inefficient. I am trying to figure out a better way to do this. To do that, clearly we need to re-architecture QEMU for this: We must have another way to read memory from outside the QEMU process. Anybody could suggest a solution for this problem? I am willing to spend time on this feature to improve the situation. Thanks, J

3 6

[libvirt] PATCH: Fix many many win32 bugs
by Daniel P. Berrange 23 Jul '09

23 Jul '09

Latest GCC changed the meaning of 'printf' attribute annotation to refer to the host platform's native format specifiers. On Win32/mingw32 this means it is now validating against Microsoft's useless format specifiers. We replace all the printf like functions on Win32 thanks to GNULIB and thus should always validate against the GNU format specifiers. This means we have to use the 'gnu_printf' annotation everywhere, but only for GCC >= 4.4. This also disables the 'pwd' and 'cd' commands in virsh because neither of those build successfully on Win32. Finally, disables the OpenNebula driver on Win32 Daniel diff --git a/HACKING b/HACKING index ca39d61..da28e98 100644 --- a/HACKING +++ b/HACKING @@ -312,7 +312,7 @@ gcc's printf attribute directive in the prototype. For example, here's the one for virAsprintf, in util.h: int virAsprintf(char **strp, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf, 2, 3); + ATTRIBUTE_FMT_PRINTF(2, 3); This makes it so gcc's -Wformat and -Wformat-security options can do their jobs and cross-check format strings with the number and types diff --git a/autobuild.sh b/autobuild.sh index 54abede..d090e74 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -76,6 +76,7 @@ if [ -x /usr/bin/i686-pc-mingw32-gcc ]; then --without-uml \ --without-vbox \ --without-openvz \ + --without-one \ --without-libvirtd make diff --git a/mingw32-libvirt.spec.in b/mingw32-libvirt.spec.in index 271c6ca..9514032 100644 --- a/mingw32-libvirt.spec.in +++ b/mingw32-libvirt.spec.in @@ -52,6 +52,7 @@ MinGW Windows libvirt virtualization library. --without-uml \ --without-vbox \ --without-openvz \ + --without-one \ --without-libvirtd make @@ -90,6 +91,7 @@ rm -rf $RPM_BUILD_ROOT %{_mingw32_datadir}/libvirt/schemas/storagevol.rng %{_mingw32_datadir}/libvirt/schemas/nodedev.rng %{_mingw32_datadir}/libvirt/schemas/capability.rng +%{_mingw32_datadir}/libvirt/schemas/interface.rng %{_mingw32_datadir}/locale/*/LC_MESSAGES/libvirt.mo diff --git a/qemud/dispatch.h b/qemud/dispatch.h index ab45b19..1d85df9 100644 --- a/qemud/dispatch.h +++ b/qemud/dispatch.h @@ -41,7 +41,7 @@ remoteDispatchClientRequest (struct qemud_server *server, void remoteDispatchFormatError (remote_error *rerr, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf, 2, 3); + ATTRIBUTE_FMT_PRINTF(2, 3); void remoteDispatchAuthError (remote_error *rerr); void remoteDispatchGenericError (remote_error *rerr); diff --git a/qemud/qemud.h b/qemud/qemud.h index abacbbb..254db44 100644 --- a/qemud/qemud.h +++ b/qemud/qemud.h @@ -52,15 +52,61 @@ #ifdef HAVE_ANSIDECL_H #include <ansidecl.h> #endif + +#ifndef __GNUC_PREREQ +#if defined __GNUC__ && defined __GNUC_MINOR__ +# define __GNUC_PREREQ(maj, min) \ + ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min)) +#else +#define __GNUC_PREREQ(maj,min) 0 +#endif +#endif + +/** + * ATTRIBUTE_UNUSED: + * + * Macro to flag conciously unused parameters to functions + */ #ifndef ATTRIBUTE_UNUSED #define ATTRIBUTE_UNUSED __attribute__((__unused__)) #endif -#ifndef ATTRIBUTE_FORMAT -#define ATTRIBUTE_FORMAT(args...) __attribute__((__format__ (args))) + +/** + * ATTRIBUTE_FMT_PRINTF + * + * Macro used to check printf like functions, if compiling + * with gcc. + * + * We use gnulib which guarentees we always have GNU style + * printf format specifiers even on broken Win32 platforms + * hence we have to force 'gnu_printf' for new GCC + */ +#ifndef ATTRIBUTE_FMT_PRINTF +#if __GNUC_PREREQ (4, 4) +#define ATTRIBUTE_FMT_PRINTF(fmtpos,argpos) __attribute__((__format__ (gnu_printf, fmtpos,argpos))) +#else +#define ATTRIBUTE_FMT_PRINTF(fmtpos,argpos) __attribute__((__format__ (printf, fmtpos,argpos))) +#endif #endif + +#ifndef ATTRIBUTE_RETURN_CHECK +#if __GNUC_PREREQ (3, 4) +#define ATTRIBUTE_RETURN_CHECK __attribute__((__warn_unused_result__)) #else +#define ATTRIBUTE_RETURN_CHECK +#endif +#endif + +#else +#ifndef ATTRIBUTE_UNUSED #define ATTRIBUTE_UNUSED -#define ATTRIBUTE_FORMAT(...) +#endif +#ifndef ATTRIBUTE_FMT_PRINTF +#define ATTRIBUTE_FMT_PRINTF(...) +#endif +#ifndef ATTRIBUTE_RETURN_CHECK +#define ATTRIBUTE_RETURN_CHECK +#endif #endif #define qemudDebug DEBUG @@ -213,7 +259,7 @@ struct qemud_server { }; void qemudLog(int priority, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf,2,3); + ATTRIBUTE_FMT_PRINTF(2,3); diff --git a/src/buf.h b/src/buf.h index 0b78d17..7d31cb2 100644 --- a/src/buf.h +++ b/src/buf.h @@ -40,7 +40,7 @@ unsigned int virBufferUse(const virBufferPtr buf); void virBufferAdd(const virBufferPtr buf, const char *str, int len); void virBufferAddChar(const virBufferPtr buf, char c); void virBufferVSprintf(const virBufferPtr buf, const char *format, ...) - ATTRIBUTE_FORMAT(printf, 2, 3); + ATTRIBUTE_FMT_PRINTF(2, 3); void virBufferStrcat(const virBufferPtr buf, ...); void virBufferEscapeString(const virBufferPtr buf, const char *format, const char *str); void virBufferURIEncodeString (const virBufferPtr buf, const char *str); diff --git a/src/internal.h b/src/internal.h index adb6507..cf7e196 100644 --- a/src/internal.h +++ b/src/internal.h @@ -67,8 +67,13 @@ #ifdef __GNUC__ #ifndef __GNUC_PREREQ +#if defined __GNUC__ && defined __GNUC_MINOR__ +# define __GNUC_PREREQ(maj, min) \ + ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min)) +#else #define __GNUC_PREREQ(maj,min) 0 #endif +#endif /** * ATTRIBUTE_UNUSED: @@ -80,13 +85,21 @@ #endif /** - * ATTRIBUTE_FORMAT + * ATTRIBUTE_FMT_PRINTF * - * Macro used to check printf/scanf-like functions, if compiling + * Macro used to check printf like functions, if compiling * with gcc. + * + * We use gnulib which guarentees we always have GNU style + * printf format specifiers even on broken Win32 platforms + * hence we have to force 'gnu_printf' for new GCC */ -#ifndef ATTRIBUTE_FORMAT -#define ATTRIBUTE_FORMAT(args...) __attribute__((__format__ (args))) +#ifndef ATTRIBUTE_FMT_PRINTF +#if __GNUC_PREREQ (4, 4) +#define ATTRIBUTE_FMT_PRINTF(fmtpos,argpos) __attribute__((__format__ (gnu_printf, fmtpos,argpos))) +#else +#define ATTRIBUTE_FMT_PRINTF(fmtpos,argpos) __attribute__((__format__ (printf, fmtpos,argpos))) +#endif #endif #ifndef ATTRIBUTE_RETURN_CHECK @@ -98,9 +111,15 @@ #endif #else +#ifndef ATTRIBUTE_UNUSED #define ATTRIBUTE_UNUSED -#define ATTRIBUTE_FORMAT(...) +#endif +#ifndef ATTRIBUTE_FMT_PRINTF +#define ATTRIBUTE_FMT_PRINTF(...) +#endif +#ifndef ATTRIBUTE_RETURN_CHECK #define ATTRIBUTE_RETURN_CHECK +#endif #endif /* __GNUC__ */ /* diff --git a/src/logging.h b/src/logging.h index 0b9ae79..f1e2525 100644 --- a/src/logging.h +++ b/src/logging.h @@ -121,6 +121,6 @@ extern int virLogParseFilters(const char *filters); extern int virLogParseOutputs(const char *output); extern void virLogMessage(const char *category, int priority, const char *funcname, long long linenr, int flags, - const char *fmt, ...) ATTRIBUTE_FORMAT(printf, 6, 7); + const char *fmt, ...) ATTRIBUTE_FMT_PRINTF(6, 7); #endif diff --git a/src/security.h b/src/security.h index 585caa0..5fc3086 100644 --- a/src/security.h +++ b/src/security.h @@ -82,7 +82,7 @@ virSecurityDriverVerify(virConnectPtr conn, virDomainDefPtr def); void virSecurityReportError(virConnectPtr conn, int code, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf, 3, 4); + ATTRIBUTE_FMT_PRINTF(3, 4); /* Helpers */ void virSecurityDriverInit(virSecurityDriverPtr drv); diff --git a/src/sexpr.h b/src/sexpr.h index c3d038e..1d9adaa 100644 --- a/src/sexpr.h +++ b/src/sexpr.h @@ -49,7 +49,7 @@ void sexpr_free(struct sexpr *sexpr); const char *sexpr_node(const struct sexpr *sexpr, const char *node); int sexpr_node_copy(const struct sexpr *sexpr, const char *node, char **dst); const char *sexpr_fmt_node(const struct sexpr *sexpr, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf,2,3); + ATTRIBUTE_FMT_PRINTF(2,3); struct sexpr *sexpr_lookup(const struct sexpr *sexpr, const char *node); int sexpr_has(const struct sexpr *sexpr, const char *node); #endif diff --git a/src/threads-win32.c b/src/threads-win32.c index 10233b0..ef3f2ef 100644 --- a/src/threads-win32.c +++ b/src/threads-win32.c @@ -41,8 +41,10 @@ void virCondEventCleanup(void *data); int virThreadInitialize(void) { - virMutexInit(&virThreadLocalLock); - virThreadLocalInit(&virCondEvent, virCondEventCleanup); + if (virMutexInit(&virThreadLocalLock) < 0) + return -1; + if (virThreadLocalInit(&virCondEvent, virCondEventCleanup) < 0) + return -1; return 0; } diff --git a/src/util.h b/src/util.h index 1a7286c..43a5bbc 100644 --- a/src/util.h +++ b/src/util.h @@ -160,7 +160,7 @@ int virMacAddrCompare (const char *mac1, const char *mac2); void virSkipSpaces(const char **str); int virParseNumber(const char **str); int virAsprintf(char **strp, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf, 2, 3); + ATTRIBUTE_FMT_PRINTF(2, 3); #define VIR_MAC_BUFLEN 6 #define VIR_MAC_PREFIX_BUFLEN 3 diff --git a/src/virsh.c b/src/virsh.c index fff73a1..6919292 100644 --- a/src/virsh.c +++ b/src/virsh.c @@ -202,7 +202,7 @@ typedef struct __vshControl { static const vshCmdDef commands[]; static void vshError(vshControl *ctl, int doexit, const char *format, ...) - ATTRIBUTE_FORMAT(printf, 3, 4); + ATTRIBUTE_FMT_PRINTF(3, 4); static int vshInit(vshControl *ctl); static int vshDeinit(vshControl *ctl); static void vshUsage(void); @@ -272,9 +272,9 @@ static virStorageVolPtr vshCommandOptVolBy(vshControl *ctl, const vshCmd *cmd, VSH_BYUUID|VSH_BYNAME) static void vshPrintExtra(vshControl *ctl, const char *format, ...) - ATTRIBUTE_FORMAT(printf, 2, 3); + ATTRIBUTE_FMT_PRINTF(2, 3); static void vshDebug(vshControl *ctl, int level, const char *format, ...) - ATTRIBUTE_FORMAT(printf, 3, 4); + ATTRIBUTE_FMT_PRINTF(3, 4); /* XXX: add batch support */ #define vshPrint(_ctl, ...) fprintf(stdout, __VA_ARGS__) @@ -495,6 +495,8 @@ cmdConnect(vshControl *ctl, const vshCmd *cmd) return ctl->conn ? TRUE : FALSE; } +#ifndef WIN32 + /* * "console" command */ @@ -510,8 +512,6 @@ static const vshCmdOptDef opts_console[] = { {NULL, 0, 0, NULL} }; -#ifndef __MINGW32__ - static int cmdRunConsole(vshControl *ctl, virDomainPtr dom) { @@ -574,17 +574,6 @@ cmdRunConsole(vshControl *ctl, virDomainPtr dom) return ret; } -#else /* __MINGW32__ */ - -static int -cmdRunConsole(vshControl *ctl, virDomainPtr dom ATTRIBUTE_UNUSED) -{ - vshError (ctl, FALSE, "%s", _("console not implemented on this platform")); - return FALSE; -} - -#endif /* __MINGW32__ */ - static int cmdConsole(vshControl *ctl, const vshCmd *cmd) { @@ -603,6 +592,9 @@ cmdConsole(vshControl *ctl, const vshCmd *cmd) return ret; } +#endif /* WIN32 */ + + /* * "list" command */ @@ -931,7 +923,9 @@ static const vshCmdInfo info_create[] = { static const vshCmdOptDef opts_create[] = { {"file", VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop("file containing an XML domain description")}, +#ifndef WIN32 {"console", VSH_OT_BOOL, 0, gettext_noop("attach to console after creation")}, +#endif {NULL, 0, 0, NULL} }; @@ -943,7 +937,9 @@ cmdCreate(vshControl *ctl, const vshCmd *cmd) int found; int ret = TRUE; char *buffer; +#ifndef WIN32 int console = vshCommandOptBool(cmd, "console"); +#endif if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) return FALSE; @@ -961,8 +957,10 @@ cmdCreate(vshControl *ctl, const vshCmd *cmd) if (dom != NULL) { vshPrint(ctl, _("Domain %s created from %s\n"), virDomainGetName(dom), from); +#ifndef WIN32 if (console) cmdRunConsole(ctl, dom); +#endif virDomainFree(dom); } else { vshError(ctl, FALSE, _("Failed to create domain from %s"), from); @@ -1083,7 +1081,9 @@ static const vshCmdInfo info_start[] = { static const vshCmdOptDef opts_start[] = { {"domain", VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop("name of the inactive domain")}, +#ifndef WIN32 {"console", VSH_OT_BOOL, 0, gettext_noop("attach to console after creation")}, +#endif {NULL, 0, 0, NULL} }; @@ -1092,7 +1092,9 @@ cmdStart(vshControl *ctl, const vshCmd *cmd) { virDomainPtr dom; int ret = TRUE; +#ifndef WIN32 int console = vshCommandOptBool(cmd, "console"); +#endif if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) return FALSE; @@ -1109,8 +1111,10 @@ cmdStart(vshControl *ctl, const vshCmd *cmd) if (virDomainCreate(dom) == 0) { vshPrint(ctl, _("Domain %s started\n"), virDomainGetName(dom)); +#ifndef WIN32 if (console) cmdRunConsole(ctl, dom); +#endif } else { vshError(ctl, FALSE, _("Failed to start domain %s"), virDomainGetName(dom)); @@ -6562,6 +6566,8 @@ editReadBackFile (vshControl *ctl, const char *filename) return ret; } + +#ifndef WIN32 /* * "cd" command */ @@ -6603,6 +6609,9 @@ cmdCd(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED) return 0; } +#endif + +#ifndef WIN32 /* * "pwd" command */ @@ -6638,6 +6647,7 @@ cmdPwd(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED) free (cwd); return !err; } +#endif /* * "edit" command @@ -6802,9 +6812,13 @@ static const vshCmdDef commands[] = { {"attach-interface", cmdAttachInterface, opts_attach_interface, info_attach_interface}, {"autostart", cmdAutostart, opts_autostart, info_autostart}, {"capabilities", cmdCapabilities, NULL, info_capabilities}, +#ifndef WIN32 {"cd", cmdCd, opts_cd, info_cd}, +#endif {"connect", cmdConnect, opts_connect, info_connect}, +#ifndef WIN32 {"console", cmdConsole, opts_console, info_console}, +#endif {"create", cmdCreate, opts_create, info_create}, {"start", cmdStart, opts_start, info_start}, {"destroy", cmdDestroy, opts_destroy, info_destroy}, @@ -6882,7 +6896,9 @@ static const vshCmdDef commands[] = { {"pool-undefine", cmdPoolUndefine, opts_pool_undefine, info_pool_undefine}, {"pool-uuid", cmdPoolUuid, opts_pool_uuid, info_pool_uuid}, +#ifndef WIN32 {"pwd", cmdPwd, NULL, info_pwd}, +#endif {"quit", cmdQuit, NULL, info_quit}, {"reboot", cmdReboot, opts_reboot, info_reboot}, {"restore", cmdRestore, opts_restore, info_restore}, diff --git a/src/virterror_internal.h b/src/virterror_internal.h index fe9a96f..da89de7 100644 --- a/src/virterror_internal.h +++ b/src/virterror_internal.h @@ -46,7 +46,7 @@ void virRaiseErrorFull(virConnectPtr conn, int int1, int int2, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf, 13, 14); + ATTRIBUTE_FMT_PRINTF(13, 14); /* Includes 'dom' and 'net' for compatbility, but they're ignored */ #define virRaiseError(conn, dom, net, domain, code, level, \ @@ -61,7 +61,7 @@ void virReportErrorHelper(virConnectPtr conn, int domcode, int errcode, const char *funcname ATTRIBUTE_UNUSED, size_t linenr ATTRIBUTE_UNUSED, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf, 7, 8); + ATTRIBUTE_FMT_PRINTF(7, 8); void virReportSystemErrorFull(virConnectPtr conn, int domcode, @@ -70,7 +70,7 @@ void virReportSystemErrorFull(virConnectPtr conn, const char *funcname, size_t linenr, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf, 7, 8); + ATTRIBUTE_FMT_PRINTF(7, 8); #define virReportSystemError(conn, theerrno, fmt,...) \ virReportSystemErrorFull((conn), \ diff --git a/src/xend_internal.c b/src/xend_internal.c index 55ffd3f..e23ae2b 100644 --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -582,7 +582,7 @@ xend_op(virConnectPtr xend, const char *name, const char *key, ...) * Returns a parsed S-Expression in case of success, NULL in case of failure */ static struct sexpr *sexpr_get(virConnectPtr xend, const char *fmt, ...) - ATTRIBUTE_FORMAT(printf,2,3); + ATTRIBUTE_FMT_PRINTF(2,3); static struct sexpr * sexpr_get(virConnectPtr xend, const char *fmt, ...) -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2 1

[libvirt] How to config my VM to use KVM with libvirt?
by Jun Koi 22 Jul '09

22 Jul '09

Hi, I have a VM running under libvirt, and it is currently run with -no-kvm option (I saw that in "ps" output). Now I want to run this VM with KVM. How can I reconfigure it for that? I looked into its configuration file under /etc/libvirt/qemu, but didnt see any option to turn KVM on. Thanks, J

4 7

[libvirt] [PATCH 0/4] Fixes to some bugs encountered testing virInterface*
by Laine Stump 22 Jul '09

22 Jul '09

This series of patches fixes some problems I found while testing the virInterface implementation. Note that the 3rd patch in the series only fixes virInterface-related instances of the problem (releasing the conn lock before reporting errors). If that patch is approved, a similar thing must be done for several other functions in datatypes.c.

3 18

[libvirt] [PATCH] Release conn lock before reporting errors
by Laine Stump 22 Jul '09

22 Jul '09

This is a follow-on to 528d37. It's fixing several other cases in datatypes.c where we try to report an error while holding the conn's lock, which can't work because the error reporting also tries to lock the conn. --- src/datatypes.c | 133 ++++++++++++++++++++++++++++++++++--------------------- 1 files changed, 82 insertions(+), 51 deletions(-) diff --git a/src/datatypes.c b/src/datatypes.c index ba5401d..c2030dd 100644 --- a/src/datatypes.c +++ b/src/datatypes.c @@ -270,11 +270,13 @@ virGetDomain(virConnectPtr conn, const char *name, const unsigned char *uuid) { /* TODO check the UUID */ if (ret == NULL) { if (VIR_ALLOC(ret) < 0) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } ret->name = strdup(name); if (ret->name == NULL) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } @@ -285,6 +287,7 @@ virGetDomain(virConnectPtr conn, const char *name, const unsigned char *uuid) { memcpy(&(ret->uuid[0]), uuid, VIR_UUID_BUFLEN); if (virHashAddEntry(conn->domains, name, ret) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to add domain to connection hash table")); goto error; @@ -299,7 +302,6 @@ virGetDomain(virConnectPtr conn, const char *name, const unsigned char *uuid) { return(ret); error: - virMutexUnlock(&conn->lock); if (ret != NULL) { VIR_FREE(ret->name); VIR_FREE(ret); @@ -325,24 +327,28 @@ virReleaseDomain(virDomainPtr domain) { DEBUG("release domain %p %s", domain, domain->name); /* TODO search by UUID first as they are better differenciators */ - if (virHashRemoveEntry(conn->domains, domain->name, NULL) < 0) + if (virHashRemoveEntry(conn->domains, domain->name, NULL) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("domain missing from connection hash table")); + conn = NULL; + } domain->magic = -1; domain->id = -1; VIR_FREE(domain->name); VIR_FREE(domain); - DEBUG("unref connection %p %d", conn, conn->refs); - conn->refs--; - if (conn->refs == 0) { - virReleaseConnect(conn); - /* Already unlocked mutex */ - return; + if (conn) { + DEBUG("unref connection %p %d", conn, conn->refs); + conn->refs--; + if (conn->refs == 0) { + virReleaseConnect(conn); + /* Already unlocked mutex */ + return; + } + virMutexUnlock(&conn->lock); } - - virMutexUnlock(&conn->lock); } @@ -406,11 +412,13 @@ virGetNetwork(virConnectPtr conn, const char *name, const unsigned char *uuid) { /* TODO check the UUID */ if (ret == NULL) { if (VIR_ALLOC(ret) < 0) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } ret->name = strdup(name); if (ret->name == NULL) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } @@ -420,6 +428,7 @@ virGetNetwork(virConnectPtr conn, const char *name, const unsigned char *uuid) { memcpy(&(ret->uuid[0]), uuid, VIR_UUID_BUFLEN); if (virHashAddEntry(conn->networks, name, ret) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to add network to connection hash table")); goto error; @@ -431,7 +440,6 @@ virGetNetwork(virConnectPtr conn, const char *name, const unsigned char *uuid) { return(ret); error: - virMutexUnlock(&conn->lock); if (ret != NULL) { VIR_FREE(ret->name); VIR_FREE(ret); @@ -457,23 +465,27 @@ virReleaseNetwork(virNetworkPtr network) { DEBUG("release network %p %s", network, network->name); /* TODO search by UUID first as they are better differenciators */ - if (virHashRemoveEntry(conn->networks, network->name, NULL) < 0) + if (virHashRemoveEntry(conn->networks, network->name, NULL) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("network missing from connection hash table")); + conn = NULL; + } network->magic = -1; VIR_FREE(network->name); VIR_FREE(network); - DEBUG("unref connection %p %d", conn, conn->refs); - conn->refs--; - if (conn->refs == 0) { - virReleaseConnect(conn); - /* Already unlocked mutex */ - return; + if (conn) { + DEBUG("unref connection %p %d", conn, conn->refs); + conn->refs--; + if (conn->refs == 0) { + virReleaseConnect(conn); + /* Already unlocked mutex */ + return; + } + virMutexUnlock(&conn->lock); } - - virMutexUnlock(&conn->lock); } @@ -714,11 +726,13 @@ virGetStoragePool(virConnectPtr conn, const char *name, const unsigned char *uui /* TODO check the UUID */ if (ret == NULL) { if (VIR_ALLOC(ret) < 0) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } ret->name = strdup(name); if (ret->name == NULL) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } @@ -728,6 +742,7 @@ virGetStoragePool(virConnectPtr conn, const char *name, const unsigned char *uui memcpy(&(ret->uuid[0]), uuid, VIR_UUID_BUFLEN); if (virHashAddEntry(conn->storagePools, name, ret) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to add storage pool to connection hash table")); goto error; @@ -739,7 +754,6 @@ virGetStoragePool(virConnectPtr conn, const char *name, const unsigned char *uui return(ret); error: - virMutexUnlock(&conn->lock); if (ret != NULL) { VIR_FREE(ret->name); VIR_FREE(ret); @@ -766,23 +780,27 @@ virReleaseStoragePool(virStoragePoolPtr pool) { DEBUG("release pool %p %s", pool, pool->name); /* TODO search by UUID first as they are better differenciators */ - if (virHashRemoveEntry(conn->storagePools, pool->name, NULL) < 0) + if (virHashRemoveEntry(conn->storagePools, pool->name, NULL) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("pool missing from connection hash table")); + conn = NULL; + } pool->magic = -1; VIR_FREE(pool->name); VIR_FREE(pool); - DEBUG("unref connection %p %d", conn, conn->refs); - conn->refs--; - if (conn->refs == 0) { - virReleaseConnect(conn); - /* Already unlocked mutex */ - return; + if (conn) { + DEBUG("unref connection %p %d", conn, conn->refs); + conn->refs--; + if (conn->refs == 0) { + virReleaseConnect(conn); + /* Already unlocked mutex */ + return; + } + virMutexUnlock(&conn->lock); } - - virMutexUnlock(&conn->lock); } @@ -845,16 +863,19 @@ virGetStorageVol(virConnectPtr conn, const char *pool, const char *name, const c ret = (virStorageVolPtr) virHashLookup(conn->storageVols, key); if (ret == NULL) { if (VIR_ALLOC(ret) < 0) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } ret->pool = strdup(pool); if (ret->pool == NULL) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } ret->name = strdup(name); if (ret->name == NULL) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } @@ -864,6 +885,7 @@ virGetStorageVol(virConnectPtr conn, const char *pool, const char *name, const c ret->conn = conn; if (virHashAddEntry(conn->storageVols, key, ret) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to add storage vol to connection hash table")); goto error; @@ -875,7 +897,6 @@ virGetStorageVol(virConnectPtr conn, const char *pool, const char *name, const c return(ret); error: - virMutexUnlock(&conn->lock); if (ret != NULL) { VIR_FREE(ret->name); VIR_FREE(ret->pool); @@ -903,24 +924,28 @@ virReleaseStorageVol(virStorageVolPtr vol) { DEBUG("release vol %p %s", vol, vol->name); /* TODO search by UUID first as they are better differenciators */ - if (virHashRemoveEntry(conn->storageVols, vol->key, NULL) < 0) + if (virHashRemoveEntry(conn->storageVols, vol->key, NULL) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("vol missing from connection hash table")); + conn = NULL; + } vol->magic = -1; VIR_FREE(vol->name); VIR_FREE(vol->pool); VIR_FREE(vol); - DEBUG("unref connection %p %d", conn, conn->refs); - conn->refs--; - if (conn->refs == 0) { - virReleaseConnect(conn); - /* Already unlocked mutex */ - return; + if (conn) { + DEBUG("unref connection %p %d", conn, conn->refs); + conn->refs--; + if (conn->refs == 0) { + virReleaseConnect(conn); + /* Already unlocked mutex */ + return; + } + virMutexUnlock(&conn->lock); } - - virMutexUnlock(&conn->lock); } @@ -981,7 +1006,8 @@ virGetNodeDevice(virConnectPtr conn, const char *name) ret = (virNodeDevicePtr) virHashLookup(conn->nodeDevices, name); if (ret == NULL) { - if (VIR_ALLOC(ret) < 0) { + if (VIR_ALLOC(ret) < 0) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } @@ -989,11 +1015,13 @@ virGetNodeDevice(virConnectPtr conn, const char *name) ret->conn = conn; ret->name = strdup(name); if (ret->name == NULL) { + virMutexUnlock(&conn->lock); virReportOOMError(conn); goto error; } if (virHashAddEntry(conn->nodeDevices, name, ret) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to add node dev to conn hash table")); goto error; @@ -1005,7 +1033,6 @@ virGetNodeDevice(virConnectPtr conn, const char *name) return(ret); error: - virMutexUnlock(&conn->lock); if (ret != NULL) { VIR_FREE(ret->name); VIR_FREE(ret); @@ -1031,24 +1058,28 @@ virReleaseNodeDevice(virNodeDevicePtr dev) { virConnectPtr conn = dev->conn; DEBUG("release dev %p %s", dev, dev->name); - if (virHashRemoveEntry(conn->nodeDevices, dev->name, NULL) < 0) + if (virHashRemoveEntry(conn->nodeDevices, dev->name, NULL) < 0) { + virMutexUnlock(&conn->lock); virLibConnError(conn, VIR_ERR_INTERNAL_ERROR, _("dev missing from connection hash table")); + conn = NULL; + } dev->magic = -1; VIR_FREE(dev->name); VIR_FREE(dev->parent); VIR_FREE(dev); - DEBUG("unref connection %p %d", conn, conn->refs); - conn->refs--; - if (conn->refs == 0) { - virReleaseConnect(conn); - /* Already unlocked mutex */ - return; + if (conn) { + DEBUG("unref connection %p %d", conn, conn->refs); + conn->refs--; + if (conn->refs == 0) { + virReleaseConnect(conn); + /* Already unlocked mutex */ + return; + } + virMutexUnlock(&conn->lock); } - - virMutexUnlock(&conn->lock); } -- 1.6.0.6

3 2

[libvirt] [PATCH] Rename remaining occurrences of 'interface' to avoid MINGW32 build problem
by Laine Stump 22 Jul '09

22 Jul '09

--- qemud/remote.c | 2 +- src/interface_conf.c | 34 +++++++++++++++++----------------- src/interface_conf.h | 4 ++-- src/veth.c | 6 +++--- src/veth.h | 2 +- 5 files changed, 24 insertions(+), 24 deletions(-) diff --git a/qemud/remote.c b/qemud/remote.c index 651e9fb..d32d513 100644 --- a/qemud/remote.c +++ b/qemud/remote.c @@ -61,7 +61,7 @@ static virDomainPtr get_nonnull_domain (virConnectPtr conn, remote_nonnull_domain domain); static virNetworkPtr get_nonnull_network (virConnectPtr conn, remote_nonnull_network network); -static virInterfacePtr get_nonnull_interface (virConnectPtr conn, remote_nonnull_interface interface); +static virInterfacePtr get_nonnull_interface (virConnectPtr conn, remote_nonnull_interface iface); static virStoragePoolPtr get_nonnull_storage_pool (virConnectPtr conn, remote_nonnull_storage_pool pool); static virStorageVolPtr get_nonnull_storage_vol (virConnectPtr conn, remote_nonnull_storage_vol vol); static void make_nonnull_domain (remote_nonnull_domain *dom_dst, virDomainPtr dom_src); diff --git a/src/interface_conf.c b/src/interface_conf.c index 1cc9f36..c2e8d07 100644 --- a/src/interface_conf.c +++ b/src/interface_conf.c @@ -1207,51 +1207,51 @@ virInterfaceObjPtr virInterfaceAssignDef(virConnectPtr conn, virInterfaceObjListPtr interfaces, const virInterfaceDefPtr def) { - virInterfaceObjPtr interface; + virInterfaceObjPtr iface; - if ((interface = virInterfaceFindByName(interfaces, def->name))) { - if (interface->def) - virInterfaceDefFree(interface->def); - interface->def = def; + if ((iface = virInterfaceFindByName(interfaces, def->name))) { + if (iface->def) + virInterfaceDefFree(iface->def); + iface->def = def; - return interface; + return iface; } - if (VIR_ALLOC(interface) < 0) { + if (VIR_ALLOC(iface) < 0) { virReportOOMError(conn); return NULL; } - if (virMutexInit(&interface->lock) < 0) { + if (virMutexInit(&iface->lock) < 0) { virInterfaceReportError(conn, VIR_ERR_INTERNAL_ERROR, "%s", _("cannot initialize mutex")); - VIR_FREE(interface); + VIR_FREE(iface); return NULL; } - virInterfaceObjLock(interface); - interface->def = def; + virInterfaceObjLock(iface); + iface->def = def; if (VIR_REALLOC_N(interfaces->objs, interfaces->count + 1) < 0) { virReportOOMError(conn); - VIR_FREE(interface); + VIR_FREE(iface); return NULL; } - interfaces->objs[interfaces->count] = interface; + interfaces->objs[interfaces->count] = iface; interfaces->count++; - return interface; + return iface; } void virInterfaceRemove(virInterfaceObjListPtr interfaces, - const virInterfaceObjPtr interface) + const virInterfaceObjPtr iface) { unsigned int i; - virInterfaceObjUnlock(interface); + virInterfaceObjUnlock(iface); for (i = 0 ; i < interfaces->count ; i++) { virInterfaceObjLock(interfaces->objs[i]); - if (interfaces->objs[i] == interface) { + if (interfaces->objs[i] == iface) { virInterfaceObjUnlock(interfaces->objs[i]); virInterfaceObjFree(interfaces->objs[i]); diff --git a/src/interface_conf.h b/src/interface_conf.h index aea1208..bb9dce4 100644 --- a/src/interface_conf.h +++ b/src/interface_conf.h @@ -186,14 +186,14 @@ virInterfaceObjPtr virInterfaceFindByName(const virInterfaceObjListPtr void virInterfaceDefFree(virInterfaceDefPtr def); -void virInterfaceObjFree(virInterfaceObjPtr interface); +void virInterfaceObjFree(virInterfaceObjPtr iface); void virInterfaceObjListFree(virInterfaceObjListPtr vms); virInterfaceObjPtr virInterfaceAssignDef(virConnectPtr conn, virInterfaceObjListPtr interfaces, const virInterfaceDefPtr def); void virInterfaceRemove(virInterfaceObjListPtr interfaces, - const virInterfaceObjPtr interface); + const virInterfaceObjPtr iface); virInterfaceDefPtr virInterfaceDefParseString(virConnectPtr conn, const char *xmlStr); diff --git a/src/veth.c b/src/veth.c index 04e68b2..71d7de6 100644 --- a/src/veth.c +++ b/src/veth.c @@ -191,16 +191,16 @@ error_out: * * Returns 0 on success or -1 in case of error */ -int moveInterfaceToNetNs(const char* interface, int pidInNs) +int moveInterfaceToNetNs(const char* iface, int pidInNs) { int rc = -1; char *pid = NULL; const char *argv[] = { - "ip", "link", "set", interface, "netns", NULL, NULL + "ip", "link", "set", iface, "netns", NULL, NULL }; int cmdResult; - if (NULL == interface) { + if (NULL == iface) { goto error_out; } diff --git a/src/veth.h b/src/veth.h index 43181cd..429eb3d 100644 --- a/src/veth.h +++ b/src/veth.h @@ -19,6 +19,6 @@ int vethCreate(char* veth1, int veth1MaxLen, char* veth2, int veth2MaxLen); int vethDelete(const char* veth); int vethInterfaceUpOrDown(const char* veth, int upOrDown); -int moveInterfaceToNetNs(const char *interface, int pidInNs); +int moveInterfaceToNetNs(const char *iface, int pidInNs); #endif /* VETH_H */ -- 1.6.0.6

3 2

[libvirt] managing libvirt users in a one-server context
by Juan Miscaro 22 Jul '09

22 Jul '09

I have a single KVM server on which I want to allow co-workers the ability to create vm's. Here are my criteria in order of importance: 1. I do not want to have to grant all users root privileges. 2. I would like the vm's to use the host's bridge (br0) by default. 3. I do not want one user to be able to start, stop, or (re)define the vm's created by another user by default. 4. I would like a user to be able grant access to another user. Mostly for viewing. Can I do all this with hardcoded usernames and passwords? If not, what is my best option? -- /jm

2 1

[libvirt] Bugfix for failing to reconnect to vbox:///session
by Pritesh Kothari 22 Jul '09

22 Jul '09

Hi All, While reconnecting to vbox:///session, since the VBoxCGlueInit() is not intialized, the g_pfnGetFunctions is NULL and thus reconnection fails with SEGV. Fixed this in the patch below. Regards, Pritesh

3 4

[libvirt] [PATCH 0/1] RFC Fix problems with TLS connections & threading
by Daniel P. Berrange 22 Jul '09

22 Jul '09

Even though we are not using gcrypt directly in any libvirt code, it turns out that we are responsible for initializing its thread support, since its used by gnutls. This really sucks in terms of library API encapsulation. It is also a little annoying if libvirt is used within an app that already uses gnutls/gcrypt, because there is no checking in gcrypt to see if threading ops are already set, so our call would override any pre-existing initialization, and an apps own call would override us. The only other option I see is to punt on the whole problem and declare apps are responsible for initializing gcrypt, but then this sucks too because it means apps have to presume we're built with gnutls, and not nss - not that we support nss currently. This bug only really impacts the libvirt client if using multiple virConnectPtr objects from separate threads with a TLS based URI. The server isn't impacted because all TLS I/O is done from the single I/O thread, and not any of the RPC workers. Daniel P. Berrange (1): Initialize gcrypt threading src/remote_internal.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 43 insertions(+), 0 deletions(-)

1 1

[libvirt] [PATCH] Support physical memory in virDomainMemoryPeek()
by Nguyen Anh Quynh 22 Jul '09

22 Jul '09

Hi, This patch provides support for physical memory in virDomainMemoryPeek(). Please consider applying. Signed-off-by: Nguyen Anh Quynh <aquynh(a)gmail.com> # diffstat pmemsave3.diff docs/libvirt-api.xml | 2 +- include/libvirt/libvirt.h.in | 1 + src/libvirt.c | 14 +++++--------- src/qemu_driver.c | 17 ++++++++--------- 4 files changed, 15 insertions(+), 19 deletions(-)

3 8

[libvirt] [PATCH 00/14] Add support for qemu NIC hotplug
by Mark McLoughlin 22 Jul '09

22 Jul '09

Hey, Here's a series of patches to (mostly) support NIC hotplug with qemu 0.10.x or later. qemu-0.10.0 introduced the host_net_add monitor command without which we cannot do NIC hotplug, so we do not try and support hotplug with older versions of KVM. With qemu-0.11.0 we will be able to pass a tap file descriptor over the monitor, but until then we cannot support 'bridge' and 'network' type interfaces. A forthcoming patch series will rectify that. Cheers, Mark.

3 60