- Devel - libvirt List Archives

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