Re: [libvirt] [PATCH v2 0/3] Fix migration of paused VMs
On Thu, Dec 10, 2009 at 11:38:16AM +, Daniel P. Berrange wrote: On Wed, Dec 09, 2009 at 02:38:25PM +0100, Paolo Bonzini wrote: This is the final version of QEMU support for migrating paused VMs. The patch series is the same as what I posted on Nov 25, except for the check on the return value of virDomainGetInfo. Patch 2 also had some easily-solved conflicts upon rebasing. I haven't yet implemented an error message when inactive domains are migrated; I'll do so in a follow-up patch. Paolo include/libvirt/libvirt.h.in |1 + src/libvirt.c | 15 ++- src/qemu/qemu_driver.c | 37 - src/xen/xend_internal.c|9 + tools/virsh.c |5 - tools/virsh.pod|7 --- 6 files changed, 56 insertions(+), 18 deletions(-) Paolo Bonzini (3): fix migration of paused vms upon failure add virsh --suspend retrieve paused/running state at the beginning of migration ACK to this series Yup, pushed ! thanks Paolo ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix reference leak in remoteDispatchStorageVolCreateXmlFrom
On Fri, Dec 11, 2009 at 02:13:24AM +0100, Matthias Bolte wrote:
---
daemon/remote.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 3117615..7a43046 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -4118,12 +4118,15 @@ remoteDispatchStorageVolCreateXmlFrom (struct
qemud_server *server ATTRIBUTE_UNU
clonevol = get_nonnull_storage_vol (conn, args-clonevol);
if (clonevol == NULL) {
+virStoragePoolFree(pool);
remoteDispatchConnError(rerr, conn);
return -1;
}
newvol = virStorageVolCreateXMLFrom (pool, args-xml, clonevol,
args-flags);
+virStorageVolFree(clonevol);
+virStoragePoolFree(pool);
if (newvol == NULL) {
remoteDispatchConnError(rerr, conn);
return -1;
Hum, looks right, but how did you find this, valgrind the TCK ?
ACK
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix memory leak in virStorageBackendCopyToFD
On Fri, Dec 11, 2009 at 02:12:46AM +0100, Matthias Bolte wrote: --- src/storage/storage_backend.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index a3b4d5a..9dc801c 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -198,6 +198,8 @@ cleanup: if (inputfd != -1) close(inputfd); +VIR_FREE(buf); + return ret; } Good catch, ACK ! thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] My beefs with the libvirt XML configuration format
On Fri, Dec 11, 2009 at 08:09:33AM +0100, Daniel Veillard wrote: On Thu, Dec 10, 2009 at 06:07:13PM +, Daniel P. Berrange wrote: There should be an option to validate the XML input, either by providing a VIR_DOMAIN_XML_VALIDATE flag with the APIs which accept XML as input, or by having virsh edit doing validation after the editor exits. I think I suggested a couple of time to have the input XML data be validated at the API level, but we don't want to do this systematically, this would create IMHO more problems it can solve. Using a flag and/or activating it when libvirt conf is in debug mode would both make sense. This would also allow virsh to re-launch the editor upon error and let you correct the mistake instead of forcing you to start again from scratch. The schemas validation won't be perfect in any way, for example trying to limit the list of allowed ethernet adapter based on the hypervisor type is nearly impossible even with Relax-NG since we differentiate based on an attribute in the top level element (this would force to basically write parallel schemas and become completely unmaintainable). Relax-NG validation also will provide out of context error messages, while the conf parser can give way better diagnostics. I think it is a mistake that our current schemas try to validate the content of attributes such as ethernet adapter name. Increasingly we in a situation where the allowed values are dynamically determined on the fly. The schema would be more useful if it simply validated that it was a string a-Z,0-9, and didn't try to check explicit enumeration of values there. ie just validate basic syntax, and not semantics. The original poster's problem of 'pc' vs 'pc-0.11' is a good example of validating the individual values is bad - 'pc-0.11' is dynamically pulled from the QEMU binary so there's no hope of the schema ever being aware of that. Regards, 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: the filesystem tag (WAS: simple LXC/libvirt busybox container (Unable to get cgroup))
On Thu, Dec 10, 2009 at 05:44:30PM -0600, Tony Risinger wrote: wow! i was starting to think i would never get past this problem! [r...@phs-001 ~]# echo $VIRSH_DEFAULT_CONNECT_URI lxc:/// [r...@phs-001 ~]# virsh create /vps/def/exec/sys/arch-nano.xml Domain arch-nano created from /vps/def/exec/sys/arch-nano.xml [r...@phs-001 ~]# virsh console arch-nano Connected to domain arch-nano Escape character is ^] # [r...@phs-001 ~]# grep cgroup /proc/mounts none /cgroup cgroup rw,relatime,devices,memory,cpuacct,cpu 0 0 everything seems to be working fine now after disabling ns from cgroup mount; thank you very much Ryota and Daniel for you time and assistance. i must have sunk 40+ hours into this, but i learned a tremendous amount, so nothing is lost. :-) this is somewhat of a digression, and i can submit a new thread if need be, but my last remaining question is about the filesystem tag/root mounting. i have not found any mention of the filesystem tag in the docs or how to work with it... i want to have libvirt mount a specified device (a btrfs subvolume) and use it for the root filesystem of the created LXC container. is there a way to do this? perhaps source dev=/dev/sdb options=subvol./, or do i need to use the storage XML? i didnt see a way to use a storage/device definition as the rootfs. The plan is that the filesystem tag will eventually support 3 types of sources, a directory (which gets bind mounted into the root), a file (loopback device + mounted), or block device (directly mounted). Currently though we only support the first option. So if you have a block device, you should first mount it in your host OS, and then let LXC bind the mount point into the container. Regards, 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] simple LXC/libvirt busybox container (Unable to get cgroup)
On Thu, Dec 10, 2009 at 09:45:03PM +0900, Ryota Ozaki wrote: On Thu, Dec 10, 2009 at 9:36 PM, Daniel P. Berrange berra...@redhat.com wrote: What you do mean by 'ns' subsystem ? 'ns' is one of functions of cgroups like such as devices, memory, cpu, etc. and it is enabled if you mount cgroup without any options that Tony is doing. # grep cgroup /proc/mounts cgroup /dev/cgroups/cpu cgroup rw,relatime,cpuacct,cpu 0 0 cgroup /dev/cgroups/memory cgroup rw,relatime,memory 0 0 cgroup /dev/cgroups/devices cgroup rw,relatime,devices 0 0 Oh, you don't enable 'ns', so yes, things go fine in your environment. I added the 'ns' controller as another mount poiint, and weirdly everything still worked. It was only when i rebooted and mounted everything at the same mount point that it stopped working. I'll investigate why this is try and come up with a fix for 'ns' 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] getSchedulerParameters() always returning nullpointerexception in JAVA
Hi everyvody,
I'm developing a new API based on libvirt.
I'm currently stucked using getSchedulerParameters, always is returning a
nullpointerexception, no matter which Xen Domain I'm passing to the
function.
Enclosing both the code and the error console:
public int getCPUPriority(String name) {
int res=-1;
try {
Domain d = getDomain(name);
SchedParameter[] pars = d.getSchedulerParameters();
for (SchedParameter pri : pars) {
if (pri.field==weight)
res=Integer.parseInt(pri.getValueAsString());
}
} catch (LibvirtException e) {
log.error( Error: getting CPU priority of \+name+\. +
e.getClass());
e.printStackTrace();
}
return res;
}
Dec 11, 2009 1:04:18 PM net.emotivecloud.virtmonitor.VirtMonitor
getCPUCapacity
SEVERE: Error: getting CPU capacity of XenTest.
java.lang.NullPointerException
at org.libvirt.SchedParameter.create(Unknown Source)
at org.libvirt.Domain.getSchedulerParameters(Unknown Source)
at
net.emotivecloud.virtmonitor.VirtMonitor.getCPUCapacity(VirtMonitor.java:462)
at net.emotivecloud.virtmonitor.VirtMonitor.main(VirtMonitor.java:763)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
at java.lang.Thread.run(Thread.java:636)
Any ideas?
Thanks in advance,
Marc Gonzalez Mateo
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Allow versioned pc machines for QEmu
* docs/schemas/domain.rng: add pattern for pc-0.10, pc-0.11 and similar machine types --- docs/schemas/domain.rng |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index d1d3efb..dd3f732 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -171,6 +171,9 @@ valuexenfv/value valuepc/value valueisapc/value +data type=string + param name=patternpc-[0-9\.]+/param +/data /choice /attribute /optional -- 1.6.5.6 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] getSchedulerParameters() always returning nullpointerexception in JAVA
On Fri, Dec 11, 2009 at 02:01:36PM +0100, Marc Gonzalez Mateo wrote:
Hi everyvody,
I'm developing a new API based on libvirt.
I'm currently stucked using getSchedulerParameters, always is returning a
nullpointerexception, no matter which Xen Domain I'm passing to the
function.
Enclosing both the code and the error console:
public int getCPUPriority(String name) {
int res=-1;
try {
Domain d = getDomain(name);
SchedParameter[] pars = d.getSchedulerParameters();
Hum, it seems
Domain.getSchedulerParameters()
does
SchedParameter[] returnValue = new SchedParameter[0];
and
public static SchedParameter create(virSchedParameter vParam) {
SchedParameter returnValue = null;
switch (vParam.type) {
case (1):
and the create method getting there gets a null pointer as the
initialization argument, which it first dereference ...
so not surprizing looking at the code, maybe Bryan has an idea of what
is going on there, I'm a bit lost in this initialization process ...
Daniel
for (SchedParameter pri : pars) {
if (pri.field==weight)
res=Integer.parseInt(pri.getValueAsString());
}
} catch (LibvirtException e) {
log.error( Error: getting CPU priority of \+name+\. +
e.getClass());
e.printStackTrace();
}
return res;
}
Dec 11, 2009 1:04:18 PM net.emotivecloud.virtmonitor.VirtMonitor
getCPUCapacity
SEVERE: Error: getting CPU capacity of XenTest.
java.lang.NullPointerException
at org.libvirt.SchedParameter.create(Unknown Source)
at org.libvirt.Domain.getSchedulerParameters(Unknown Source)
at
net.emotivecloud.virtmonitor.VirtMonitor.getCPUCapacity(VirtMonitor.java:462)
at net.emotivecloud.virtmonitor.VirtMonitor.main(VirtMonitor.java:763)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
at java.lang.Thread.run(Thread.java:636)
Any ideas?
Thanks in advance,
Marc Gonzalez Mateo
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] add missing doc for device shareable/ option
This has been there forever, but we never documented it in the domain format page. The description is not fantastic, so improvements welcome :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 5b7aa10..48eafa4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -349,6 +349,7 @@ lt;encryption type='...'gt; ... lt;/encryptiongt; +lt;shareable/gt; lt;/diskgt; .../pre @@ -389,6 +390,11 @@ the a href=formatstorageencryption.htmlStorage Encryption/a page for more information. /dd + dtcodeshareable/code/dt + ddIf present, this indicates the device is expected to be shared + between domains (assuming the hypervisor and OS support this), + which means that caching should be desactivated for that device. + /dd /dl h4a name=elementsUSBUSB and PCI devices/a/h4 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Out of band channels
A libvirt client can connect to libvirt on a remote host. However, on its own this doesn't give the client a usable level of access. The reason for this is that libvirt doesn't expose some critical management interfaces. For QEMU this amounts to pretty much anything provided directly by the QEMU process, including: * VNC console [1] * Any character device [2] I'm undecided as to whether access to underlying storage falls into this bucket. It would certainly be convenient in certain circumstances. This means, for example that I need out of band access to: * See a graphical console * Connect to a serial console * Connect to a guest channel As these are fairly fundamental operations, I wonder if there has been any thought towards creating tunnels over a libvirt connection. In the first instance, I think this would require a generic method to multiplex multiple streams over a single remote connection. This would obviously be a significant protocol change. Would a messaging protocol, AMQP for instance, be a good candidate here? Secondly, I think interfaces which currently create local resources should have a default which is managed by libvirt itself. So you'd have: serial target port='0'/ /serial or serial type='managed' target port='0'/ /serial This would cause libvirt to create whichever host-side chardev is most convenient to it and connect itself. The API would then expose read and write APIs for the named connection. e.g: virDomainFoo foo;[3] if = virDomainGetFoo(domain, serial0); bytesIn = virDomainFooRead(foo, buf, sizeof(buf)); A client application could expose this in a variety of ways locally. Matt [1] There's an open RFE for this one: https://bugzilla.redhat.com/show_bug.cgi?id=526953 [2] e.g. virsh # console RHEL3.FV.64.IDE error: Cannot connect to a remote console device [3] What would you call it? -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix owner and group in example volume XML
The owner and group in the documentation examples were confusingly given as '0744'. They should be numeric uid and gid. Changed the examples to use the default uid and gid assigned to qemu in F12. * docs/formatstorage.html.in: Change example owner and group in volume XML --- docs/formatstorage.html.in | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in index ccf5a91..5c41c39 100644 --- a/docs/formatstorage.html.in +++ b/docs/formatstorage.html.in @@ -119,8 +119,8 @@ lt;targetgt; lt;pathgt;/dev/disk/by-pathlt;/pathgt; lt;permissionsgt; -lt;ownergt;0744lt;/ownergt; -lt;groupgt;0744lt;/groupgt; +lt;ownergt;107lt;/ownergt; +lt;groupgt;107lt;/groupgt; lt;modegt;0744lt;/modegt; lt;labelgt;virt_image_tlt;/labelgt; lt;/permissionsgt; @@ -244,8 +244,8 @@ lt;pathgt;/var/lib/virt/images/sparse.imglt;/pathgt; lt;format type='qcow2'/gt; lt;permissionsgt; -lt;ownergt;0744lt;/ownergt; -lt;groupgt;0744lt;/groupgt; +lt;ownergt;107lt;/ownergt; +lt;groupgt;107lt;/groupgt; lt;modegt;0744lt;/modegt; lt;labelgt;virt_image_tlt;/labelgt; lt;/permissionsgt; @@ -294,8 +294,8 @@ lt;pathgt;/var/lib/virt/images/master.imglt;/pathgt; lt;formatgt;rawlt;/formatgt; lt;permissionsgt; -lt;ownergt;0744lt;/ownergt; -lt;groupgt;0744lt;/groupgt; +lt;ownergt;107lt;/ownergt; +lt;groupgt;107lt;/groupgt; lt;modegt;0744lt;/modegt; lt;labelgt;virt_image_tlt;/labelgt; lt;/permissionsgt; @@ -368,8 +368,8 @@ lt;targetgt; lt;pathgt;/var/lib/virt/images/sparse.imglt;/pathgt; lt;permissionsgt; -lt;ownergt;0744lt;/ownergt; -lt;groupgt;0744lt;/groupgt; +lt;ownergt;107lt;/ownergt; +lt;groupgt;107lt;/groupgt; lt;modegt;0744lt;/modegt; lt;labelgt;virt_image_tlt;/labelgt; lt;/permissionsgt; -- 1.6.5.2 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix memory leak in virStorageBackendCopyToFD
2009/12/11 Daniel Veillard veill...@redhat.com: On Fri, Dec 11, 2009 at 02:12:46AM +0100, Matthias Bolte wrote: --- src/storage/storage_backend.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index a3b4d5a..9dc801c 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -198,6 +198,8 @@ cleanup: if (inputfd != -1) close(inputfd); + VIR_FREE(buf); + return ret; } Good catch, ACK ! thanks ! Daniel Also found by using the TCK and valgrind. Okay, pushed. Matthias -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix reference leak in remoteDispatchStorageVolCreateXmlFrom
2009/12/11 Daniel Veillard veill...@redhat.com:
On Fri, Dec 11, 2009 at 02:13:24AM +0100, Matthias Bolte wrote:
---
daemon/remote.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 3117615..7a43046 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -4118,12 +4118,15 @@ remoteDispatchStorageVolCreateXmlFrom (struct
qemud_server *server ATTRIBUTE_UNU
clonevol = get_nonnull_storage_vol (conn, args-clonevol);
if (clonevol == NULL) {
+ virStoragePoolFree(pool);
remoteDispatchConnError(rerr, conn);
return -1;
}
newvol = virStorageVolCreateXMLFrom (pool, args-xml, clonevol,
args-flags);
+ virStorageVolFree(clonevol);
+ virStoragePoolFree(pool);
if (newvol == NULL) {
remoteDispatchConnError(rerr, conn);
return -1;
Hum, looks right, but how did you find this, valgrind the TCK ?
ACK
Daniel
Yes, with the TCK while running libvirtd under valgrind.
Valgrind reported some of the hashes of a virConnectPtr leaking. I
tracked it down to testcase 200, narrowed it further down by
annotating the get, release and unref functions in datatypes.c and saw
each call to virStorageVolCreateXMLFrom leaked a ref to the pool and
the input volume. Looking at the code that is involved during a call
to virStorageVolCreateXMLFrom revealed the problem.
Okay, pushed.
Matthias
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Toward the next 0.7.5 release
The last release was 0.7.4 on Nov 20, so if we try to keep with the one month release cycle, we would end up with a release on Friday 25, but I really plan on celebrating Chrismas with my familly that day instead of spending time in front of a computer (I plan to roast a pig and that requires all my attention :-) I would prefer to not wait too much, as there were some serious locking bugs in 0.7.4, and I would rather not wait until the end of the vacations either. So I'm tempted to push on Wed 23, with possibly a smaller timeframe for the bug fixes only window. We didn't (yet!) introduce major changes inside (except maybe for the VirtualBox driver and early bug have been reported) and Matthias has been debugging seriously with the TCK so things should be in relatively good shape out of git. So my plan right nw would be to enter freeze, next Friday the 18th and push the release 0f 0.7.5 on the 23rd. So send those patches along and if we forgot to ACK patches please raise our attention about them, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Out of band channels
On 12/11/2009 03:32 PM, Matthew Booth wrote: A libvirt client can connect to libvirt on a remote host. However, on its own this doesn't give the client a usable level of access. The reason for this is that libvirt doesn't expose some critical management interfaces. For QEMU this amounts to pretty much anything provided directly by the QEMU process, including: * VNC console [1] * Any character device [2] I'm undecided as to whether access to underlying storage falls into this bucket. It would certainly be convenient in certain circumstances. This means, for example that I need out of band access to: * See a graphical console * Connect to a serial console * Connect to a guest channel As these are fairly fundamental operations, I wonder if there has been any thought towards creating tunnels over a libvirt connection. In the first instance, I think this would require a generic method to multiplex multiple streams over a single remote connection. This would obviously be a significant protocol change. Would a messaging protocol, AMQP for instance, be a good candidate here? In point of fact, we *do* have a way to mulitplex generic data through a libvirt tunnel; it's how we implemented tunnelled migration for kvm. Look in git for commits referencing data streams, around August 2009. I think danpb's plan was to eventually tunnel character devices (serial console's in particular) over the generic data stream, but I think that work got preempted by more high priority work. So I think what you are proposing makes sense, it just needs someone to sit down and plumb it. If you are gung-ho to do it, the implementation for tunnelled migration is in src/qemu/qemu_driver.c to use as an example. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Allow versioned pc machines for QEmu
On Fri, Dec 11, 2009 at 02:12:20PM +0100, Diego Elio Petten? wrote: * docs/schemas/domain.rng: add pattern for pc-0.10, pc-0.11 and similar machine types --- docs/schemas/domain.rng |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index d1d3efb..dd3f732 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -171,6 +171,9 @@ valuexenfv/value valuepc/value valueisapc/value +data type=string + param name=patternpc-[0-9\.]+/param +/data /choice /attribute /optional My preference is that we delete this choice block entirely and just declare it with a regex allowing a-Z, 0-9, _, -, . Even with your addition I know there are places where this will still break. The values for this attribute are dynamically extracted from the QEMU binary, so whatever QEMU reports is the only valid list. The RNG will always be chasing the QEMU changes if we try to duplicate the data. Regards, 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Allow versioned pc machines for QEmu
Il giorno Fri, 11/12/2009 alle 20.02 +, Daniel P. Berrange ha scritto: My preference is that we delete this choice block entirely and just declare it with a regex allowing a-Z, 0-9, _, -, . I guess whatever choice works ;) I'm mostly concerned that right now my configuration files don't validate… -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/6] domMemStats: Add domainMemoryStats method to struct _virDriver
Set up the types for the domainMemoryStats function and insert it into the
virDriver structure definition. Because of static initializers, update every
driver and set the new field to NULL.
Note: The changes in python/* are to fix compiler errors. The actual python
binding is implemented in a later patch.
Signed-off-by: Adam Litke a...@us.ibm.com
To: libvirt list libvir-list@redhat.com
---
include/libvirt/libvirt.h.in | 52 ++
python/generator.py |4 ++-
src/driver.h |7 +
src/esx/esx_driver.c |1 +
src/lxc/lxc_driver.c |1 +
src/opennebula/one_driver.c |1 +
src/openvz/openvz_driver.c |1 +
src/phyp/phyp_driver.c |1 +
src/qemu/qemu_driver.c |1 +
src/remote/remote_driver.c |1 +
src/test/test_driver.c |1 +
src/uml/uml_driver.c |1 +
src/vbox/vbox_tmpl.c |1 +
src/xen/xen_driver.c |1 +
14 files changed, 73 insertions(+), 1 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index f51a565..3416ed4 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -333,6 +333,55 @@ struct _virDomainInterfaceStats {
*/
typedef virDomainInterfaceStatsStruct *virDomainInterfaceStatsPtr;
+/**
+ * Memory Statistics Tags:
+ */
+typedef enum {
+/* The total amount of data read from swap space (in bytes). */
+VIR_MEMSTAT_SWAP_IN = 0,
+/* The total amount of memory written out to swap space (in bytes). */
+VIR_MEMSTAT_SWAP_OUT= 1,
+
+/*
+ * Page faults occur when a process makes a valid access to virtual memory
+ * that is not available. When servicing the page fault, if disk IO is
+ * required, it is considered a major fault. If not, it is a minor fault.
+ * These are expressed as the number of faults that have occurred.
+ */
+VIR_MEMSTAT_MAJOR_FAULT = 2,
+VIR_MEMSTAT_MINOR_FAULT = 3,
+
+/*
+ * The amount of memory left completely unused by the system. Memory that
+ * is available but used for reclaimable caches should NOT be reported as
+ * free. This value is expressed in bytes.
+ */
+VIR_MEMSTAT_MEM_FREE= 4,
+
+/*
+ * The total amount of usable memory as seen by the domain. This value
+ * may be less than the amount of memory assigned to the domain if a
+ * balloon driver is in use or if the guest OS does not initialize all
+ * assigned pages. This value is expressed in bytes.
+ */
+VIR_MEMSTAT_MEM_TOTAL = 5,
+
+/*
+ * The number of statistics supported by this version of the interface.
+ * To add new statistics, add them to the enum and increase this value.
+ */
+VIR_MEMSTAT_NR_TAGS = 6,
+} virDomainMemoryStatTags;
+
+typedef struct _virDomainMemoryStat virDomainMemoryStatStruct;
+
+struct _virDomainMemoryStat {
+virDomainMemoryStatTags tag;
+unsigned long long val;
+};
+
+typedef virDomainMemoryStatStruct *virDomainMemoryStatPtr;
+
/* Domain migration flags. */
typedef enum {
@@ -633,6 +682,9 @@ int virDomainInterfaceStats
(virDomainPtr dom,
const char *path,
virDomainInterfaceStatsPtr
stats,
size_t size);
+int virDomainMemoryStats (virDomainPtr dom,
+ virDomainMemoryStatPtr stats,
+ unsigned int nr_stats);
int virDomainBlockPeek (virDomainPtr dom,
const char *path,
unsigned long long offset,
diff --git a/python/generator.py b/python/generator.py
index 21b4137..4783f2b 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -160,7 +160,8 @@ def enum(type, name, value):
functions_failed = []
functions_skipped = [
-virConnectListDomains
+virConnectListDomains,
+virDomainMemoryStats
]
skipped_modules = {
@@ -170,6 +171,7 @@ skipped_types = {
#'int *': usually a return type,
'virConnectDomainEventCallback': No function types in python,
'virEventAddHandleFunc': No function types in python,
+ 'virDomainMemoryStatPtr': Not implemented yet,
}
###
diff --git a/src/driver.h b/src/driver.h
index 0c8f923..12ba5a7 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -226,6 +226,12 @@ typedef int
struct _virDomainInterfaceStats *stats);
typedef int
+(*virDrvDomainMemoryStats)
+(virDomainPtr domain,
+ struct _virDomainMemoryStat *stats,
+ unsigned int nr_stats);
+
+typedef int
(*virDrvDomainBlockPeek)
[libvirt] [PATCH 6/6] python: Add python bindings for virDomainMemoryStats
Enable virDomainMemoryStats in the python API. dom.memoryStats() will return a
dictionary containing the supported statistics. A dictionary is required
because the meaining of each quantity cannot be inferred from its index in a
list.
Signed-off-by: Adam Litke a...@us.ibm.com
To: libvirt list libvir-list@redhat.com
---
python/generator.py |3 +-
python/libvirt-override-api.xml |5
python/libvirt-override.c | 43 +++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/python/generator.py b/python/generator.py
index 4783f2b..b474e4b 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -161,7 +161,6 @@ def enum(type, name, value):
functions_failed = []
functions_skipped = [
virConnectListDomains,
-virDomainMemoryStats
]
skipped_modules = {
@@ -171,7 +170,6 @@ skipped_types = {
#'int *': usually a return type,
'virConnectDomainEventCallback': No function types in python,
'virEventAddHandleFunc': No function types in python,
- 'virDomainMemoryStatPtr': Not implemented yet,
}
###
@@ -282,6 +280,7 @@ skip_impl = (
'virNetworkGetAutostart',
'virDomainBlockStats',
'virDomainInterfaceStats',
+'virDomainMemoryStats',
'virNodeGetCellsFreeMemory',
'virDomainGetSchedulerType',
'virDomainGetSchedulerParameters',
diff --git a/python/libvirt-override-api.xml b/python/libvirt-override-api.xml
index 148b89b..a382f07 100644
--- a/python/libvirt-override-api.xml
+++ b/python/libvirt-override-api.xml
@@ -100,6 +100,11 @@
arg name='domain' type='virDomainPtr' info='a domain object'/
arg name='path' type='char *' info='the path for the interface device'/
/function
+function name='virDomainMemoryStats' file='python'
+ infoExtracts memory statistics for a domain/info
+ return type='virDomainMemoryStats' info='a dictionary of statistics'/
+ arg name='domain' type='virDomainPtr' info='a domain object'/
+/function
function name=virNodeGetCellsFreeMemory file='python'
infoReturns the available memory for a list of cells/info
arg name='conn' type='virConnectPtr' info='pointer to the hypervisor
connection'/
diff --git a/python/libvirt-override.c b/python/libvirt-override.c
index 5d24fd2..0d91896 100644
--- a/python/libvirt-override.c
+++ b/python/libvirt-override.c
@@ -114,6 +114,48 @@ libvirt_virDomainInterfaceStats(PyObject *self
ATTRIBUTE_UNUSED, PyObject *args)
return(info);
}
+static PyObject *
+libvirt_virDomainMemoryStats(PyObject *self ATTRIBUTE_UNUSED, PyObject *args) {
+virDomainPtr domain;
+PyObject *pyobj_domain;
+unsigned int nr_stats, i;
+virDomainMemoryStatStruct stats[VIR_MEMSTAT_NR_TAGS];
+PyObject *info;
+
+if (!PyArg_ParseTuple(args, (char *)O:virDomainMemoryStats,
pyobj_domain))
+return(NULL);
+domain = (virDomainPtr) PyvirDomain_Get(pyobj_domain);
+
+nr_stats = virDomainMemoryStats(domain, stats, VIR_MEMSTAT_NR_TAGS);
+if (nr_stats == -1)
+return VIR_PY_NONE;
+
+/* convert to a Python dictionary */
+if ((info = PyDict_New()) == NULL)
+return VIR_PY_NONE;
+
+for (i = 0; i nr_stats; i++) {
+if (stats[i].tag == VIR_MEMSTAT_SWAP_IN)
+PyDict_SetItem(info, libvirt_constcharPtrWrap(swap_in),
+ PyLong_FromUnsignedLongLong(stats[i].val));
+if (stats[i].tag == VIR_MEMSTAT_SWAP_OUT)
+PyDict_SetItem(info, libvirt_constcharPtrWrap(swap_out),
+ PyLong_FromUnsignedLongLong(stats[i].val));
+if (stats[i].tag == VIR_MEMSTAT_MAJOR_FAULT)
+PyDict_SetItem(info, libvirt_constcharPtrWrap(major_fault),
+ PyLong_FromUnsignedLongLong(stats[i].val));
+if (stats[i].tag == VIR_MEMSTAT_MINOR_FAULT)
+PyDict_SetItem(info, libvirt_constcharPtrWrap(minor_fault),
+ PyLong_FromUnsignedLongLong(stats[i].val));
+if (stats[i].tag == VIR_MEMSTAT_MEM_FREE)
+PyDict_SetItem(info, libvirt_constcharPtrWrap(free_memory),
+ PyLong_FromUnsignedLongLong(stats[i].val));
+if (stats[i].tag == VIR_MEMSTAT_MEM_TOTAL)
+PyDict_SetItem(info, libvirt_constcharPtrWrap(total_memory),
+ PyLong_FromUnsignedLongLong(stats[i].val));
+}
+return info;
+}
static PyObject *
libvirt_virDomainGetSchedulerType(PyObject *self ATTRIBUTE_UNUSED,
@@ -2414,6 +2456,7 @@ static PyMethodDef libvirtMethods[] = {
{(char *) virNetworkGetAutostart, libvirt_virNetworkGetAutostart,
METH_VARARGS, NULL},
{(char *) virDomainBlockStats, libvirt_virDomainBlockStats,
METH_VARARGS, NULL},
{(char *) virDomainInterfaceStats, libvirt_virDomainInterfaceStats,
METH_VARARGS, NULL},
+{(char *) virDomainMemoryStats,
[libvirt] [RFC] New libvirt API for domain memory statistics reporting (V2)
Thanks for the review and comments on V1. This series tries to address most of the feedback I received. I did not add any additional memory stats yet (I feel that with my new method of expanding the API, that can be handled separately). I am not convinced that every memory stat that any hypervisor exports should necessarily be included in this API. I tried to focus on statistics that are useful in the context of managing domains at the hypervisor level. Changes since V1: * New system for maintaining ABI compatibility and API extensibility: Rather than passing around a fixed-size stats structure, work with arrays of stats. An enum of known statistic tags (SWAP_IN, SWAP_OUT, TOTAL_MEM, etc) is defined. A stat is defined as a tag/value pair. When making a call to the API, the caller provides an array of stats and the size of the array. That array is filled with up to the requested number of stats (depending on hypervisor and guest support). The number of stats provided is returned. * Miscellaneous changes: Changed the API function from virDomainMemStats to virDomainMemoryStats Added documentation for each memory stat -- When using ballooning to manage overcommitted memory on a host, a system for guests to communicate their memory usage to the host can provide information that will minimize the impact of ballooning on the guests while maximizing efficient use of host memory. The design of such a communication channel was recently added to version 0.8.2 of the VirtIO Spec (See Appendix G): - http://ozlabs.org/~rusty/virtio-spec/virtio-spec-0.8.2.pdf Host-side and guest-side implementations have been accepted for inclusion in their respective projects: - Guest: http://lkml.org/lkml/2009/11/30/274 - Host: http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00380.html The following patch series implements a new libvirt interface to expose these memory statistics. Thank you for your review and comments. [PATCH 1/6] domMemStats: Add domainMemoryStats method to struct _virDriver [PATCH 2/6] domMemoryStats: Add public symbol to libvirt API [PATCH 3/6] qemu-driver: Enable domainMemStats in the qemu driver [PATCH 4/6] remote-driver: Add domainMemoryStats support [PATCH 5/6] virsh: Enable virDomainMemoryStats as a new command [PATCH 6/6] python: Add python bindings for virDomainMemoryStats -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 4/6] remote-driver: Add domainMemoryStats support
Use a dynamically sized xdr_array to pass memory stats on the wire. This
supports the addition of future memory stats and reduces the message size since
only supported statistics are returned.
Signed-off-by: Adam Litke a...@us.ibm.com
To: libvirt list libvir-list@redhat.com
---
daemon/remote.c | 56 ++
src/remote/remote_driver.c | 44 -
src/remote/remote_protocol.c | 22
src/remote/remote_protocol.h | 22
src/remote/remote_protocol.x | 16 +++-
5 files changed, 158 insertions(+), 2 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 4296fc3..0083c1a 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -688,6 +688,62 @@ remoteDispatchDomainInterfaceStats (struct qemud_server
*server ATTRIBUTE_UNUSED
}
static int
+remoteDispatchDomainMemoryStats (struct qemud_server *server ATTRIBUTE_UNUSED,
+ struct qemud_client *client ATTRIBUTE_UNUSED,
+ virConnectPtr conn,
+ remote_message_header *hdr ATTRIBUTE_UNUSED,
+ remote_error *rerr,
+ remote_domain_memory_stats_args *args,
+ remote_domain_memory_stats_ret *ret)
+{
+virDomainPtr dom;
+struct _virDomainMemoryStat *stats;
+unsigned int nr_stats, i;
+
+if (args-maxStats REMOTE_DOMAIN_MEMORY_STATS_MAX) {
+remoteDispatchFormatError (rerr, %s,
+ _(maxStats REMOTE_DOMAIN_MEMORY_STATS_MAX));
+return -1;
+}
+
+dom = get_nonnull_domain (conn, args-dom);
+if (dom == NULL) {
+remoteDispatchConnError(rerr, conn);
+return -1;
+}
+
+/* Allocate stats array for making dispatch call */
+if (VIR_ALLOC_N(stats, args-maxStats) 0) {
+remoteDispatchOOMError(rerr);
+return -1;
+}
+
+nr_stats = virDomainMemoryStats (dom, stats, args-maxStats);
+virDomainFree (dom);
+if (nr_stats == -1) {
+VIR_FREE(stats);
+remoteDispatchConnError(rerr, conn);
+return -1;
+}
+
+/* Allocate return buffer. We need 2 slots per stat: the tag and value. */
+if (VIR_ALLOC_N(ret-stats.stats_val, nr_stats * 2) 0) {
+VIR_FREE(stats);
+remoteDispatchOOMError(rerr);
+return -1;
+}
+
+/* Copy the stats into the xdr return structure */
+for (i = 0; i nr_stats; i++) {
+ret-stats.stats_val[2 * i] = (uint64_t) stats[i].tag;
+ret-stats.stats_val[2 * i + 1] = stats[i].val;
+}
+ret-stats.stats_len = nr_stats * 2;
+VIR_FREE(stats);
+return 0;
+}
+
+static int
remoteDispatchDomainBlockPeek (struct qemud_server *server ATTRIBUTE_UNUSED,
struct qemud_client *client ATTRIBUTE_UNUSED,
virConnectPtr conn,
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 9ad47ad..38311d8 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -3208,6 +3208,48 @@ done:
}
static int
+remoteDomainMemoryStats (virDomainPtr domain,
+ struct _virDomainMemoryStat *stats,
+ unsigned int nr_stats)
+{
+int rv = -1;
+remote_domain_memory_stats_args args;
+remote_domain_memory_stats_ret ret;
+struct private_data *priv = domain-conn-privateData;
+unsigned int i;
+
+remoteDriverLock(priv);
+
+make_nonnull_domain (args.dom, domain);
+if (nr_stats REMOTE_DOMAIN_MEMORY_STATS_MAX) {
+errorf (domain-conn, VIR_ERR_RPC,
+_(too many memory stats requested: %d %d), nr_stats,
+REMOTE_DOMAIN_MEMORY_STATS_MAX);
+goto done;
+}
+args.maxStats = nr_stats;
+memset (ret, 0, sizeof ret);
+
+if (call (domain-conn, priv, 0, REMOTE_PROC_DOMAIN_MEMORY_STATS,
+ (xdrproc_t) xdr_remote_domain_memory_stats_args,
+(char *) args,
+ (xdrproc_t) xdr_remote_domain_memory_stats_ret,
+(char *) ret) == -1)
+goto done;
+
+for (i = 0; i ret.stats.stats_len / 2; i++) {
+stats[i].tag = (unsigned int) ret.stats.stats_val[i * 2];
+stats[i].val = ret.stats.stats_val[i * 2 + 1];
+}
+rv = ret.stats.stats_len / 2;
+xdr_free((xdrproc_t) xdr_remote_domain_memory_stats_ret, (char *) ret);
+
+done:
+remoteDriverUnlock(priv);
+return rv;
+}
+
+static int
remoteDomainBlockPeek (virDomainPtr domain,
const char *path,
unsigned long long offset,
@@ -8437,7 +8479,7 @@ static virDriver remote_driver = {
remoteDomainMigrateFinish, /* domainMigrateFinish */
remoteDomainBlockStats, /* domainBlockStats */
remoteDomainInterfaceStats, /* domainInterfaceStats */
-NULL, /* domainMemoryStats */
+
[libvirt] [PATCH 5/6] virsh: Enable virDomainMemoryStats as a new command
Define a new command 'dommemstats' to report domain memory statistics. The
output format is inspired by 'domblkstat' and 'domifstat' and consists of
tag/value pairs, one per line. The command can complete successfully and print
no output if virDomainMemoryStats is supported by the driver, but not the guest
operating system.
Sample output:
swap_in 0
swap_out 0
major_fault 54
minor_fault 58259
mem_free 499384320
mem_tot 514531328
All stats referring to a quantity of memory (eg. all above except major and
minor faults) represent the quantity in bytes.
Signed-off-by: Adam Litke a...@us.ibm.com
To: libvirt list libvir-list@redhat.com
---
tools/virsh.c | 55 +++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 46c5454..283f794 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -874,6 +874,60 @@ cmdDomIfstat (vshControl *ctl, const vshCmd *cmd)
}
/*
+ * dommemstats command
+ */
+static const vshCmdInfo info_dommemstats[] = {
+{help, gettext_noop(get memory statistics for a domain)},
+{desc, gettext_noop(Get memory statistics for a runnng domain.)},
+{NULL,NULL}
+};
+
+static const vshCmdOptDef opts_dommemstats[] = {
+{domain, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(domain name, id or
uuid)},
+{NULL, 0, 0, NULL}
+};
+
+static int
+cmdDomMemStats(vshControl *ctl, const vshCmd *cmd)
+{
+virDomainPtr dom;
+char *name;
+struct _virDomainMemoryStat stats[VIR_MEMSTAT_NR_TAGS];
+unsigned int nr_stats, i;
+
+if (!vshConnectionUsability(ctl, ctl-conn, TRUE))
+return FALSE;
+
+if (!(dom = vshCommandOptDomain(ctl, cmd, name)))
+return FALSE;
+
+nr_stats = virDomainMemoryStats (dom, stats, VIR_MEMSTAT_NR_TAGS);
+if (nr_stats == -1) {
+vshError(ctl, _(Failed to get memory statistics for domain %s),
name);
+virDomainFree(dom);
+return FALSE;
+}
+
+for (i = 0; i nr_stats; i++) {
+if (stats[i].tag == VIR_MEMSTAT_SWAP_IN)
+vshPrint (ctl, swap_in %llu\n, stats[i].val);
+if (stats[i].tag == VIR_MEMSTAT_SWAP_OUT)
+vshPrint (ctl, swap_out %llu\n, stats[i].val);
+if (stats[i].tag == VIR_MEMSTAT_MAJOR_FAULT)
+vshPrint (ctl, major_fault %llu\n, stats[i].val);
+if (stats[i].tag == VIR_MEMSTAT_MINOR_FAULT)
+vshPrint (ctl, minor_fault %llu\n, stats[i].val);
+if (stats[i].tag == VIR_MEMSTAT_MEM_FREE)
+vshPrint (ctl, free_memory %llu\n, stats[i].val);
+if (stats[i].tag == VIR_MEMSTAT_MEM_TOTAL)
+vshPrint (ctl, total_memory %llu\n, stats[i].val);
+}
+
+virDomainFree(dom);
+return TRUE;
+}
+
+/*
* suspend command
*/
static const vshCmdInfo info_suspend[] = {
@@ -7183,6 +7237,7 @@ static const vshCmdDef commands[] = {
{domstate, cmdDomstate, opts_domstate, info_domstate},
{domblkstat, cmdDomblkstat, opts_domblkstat, info_domblkstat},
{domifstat, cmdDomIfstat, opts_domifstat, info_domifstat},
+{dommemstats, cmdDomMemStats, opts_dommemstats, info_dommemstats},
{domxml-from-native, cmdDomXMLFromNative, opts_domxmlfromnative,
info_domxmlfromnative},
{domxml-to-native, cmdDomXMLToNative, opts_domxmltonative,
info_domxmltonative},
{dumpxml, cmdDumpXML, opts_dumpxml, info_dumpxml},
--
1.6.5
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/6] qemu-driver: Enable domainMemStats in the qemu driver
Support for memory statistics reporting is accepted for qemu inclusion.
Statistics are reported via the monitor command 'info balloon' as a comma
seprated list:
(qemu) info balloon
balloon:
actual=1024,mem_swapped_in=0,mem_swapped_out=0,major_page_faults=88,minor_page_faults=105535,free_mem=1017065472,total_mem=1045229568
Libvirt, qemu, and the guest operating system may support a subset of the
statistics defined by the virtio spec. Thus, only statistics recognized by all
components will be reported. All others will be returned as -1.
Signed-off-by: Adam Litke a...@us.ibm.com
To: libvirt list libvir-list@redhat.com
---
src/qemu/qemu_driver.c | 32 ++-
src/qemu/qemu_monitor_text.c | 73 ++
src/qemu/qemu_monitor_text.h |3 ++
3 files changed, 107 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index dbf0926..298b236 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5563,6 +5563,36 @@ qemudDomainInterfaceStats (virDomainPtr dom,
#endif
static int
+qemudDomainMemoryStats (virDomainPtr dom,
+struct _virDomainMemoryStat *stats,
+unsigned int nr_stats)
+{
+struct qemud_driver *driver = dom-conn-privateData;
+virDomainObjPtr vm;
+unsigned int nr_stats_ret = -1;
+
+qemuDriverLock(driver);
+vm = virDomainFindByUUID(driver-domains, dom-uuid);
+qemuDriverUnlock(driver);
+
+if (!vm) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+virUUIDFormat(dom-uuid, uuidstr);
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_NO_DOMAIN,
+ _(no domain with matching uuid '%s'), uuidstr);
+goto cleanup;
+}
+
+if (virDomainIsActive(vm))
+nr_stats_ret = qemuMonitorGetMemoryStats(vm, stats, nr_stats);
+
+cleanup:
+if (vm)
+virDomainObjUnlock(vm);
+return nr_stats_ret;
+}
+
+static int
qemudDomainBlockPeek (virDomainPtr dom,
const char *path,
unsigned long long offset, size_t size,
@@ -7124,7 +7154,7 @@ static virDriver qemuDriver = {
NULL, /* domainMigrateFinish */
qemudDomainBlockStats, /* domainBlockStats */
qemudDomainInterfaceStats, /* domainInterfaceStats */
-NULL, /* domainMemoryStats */
+qemudDomainMemoryStats, /* domainMemoryStats */
qemudDomainBlockPeek, /* domainBlockPeek */
qemudDomainMemoryPeek, /* domainMemoryPeek */
nodeGetCellsFreeMemory, /* nodeGetCellsFreeMemory */
diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c
index 66526dc..4482420 100644
--- a/src/qemu/qemu_monitor_text.c
+++ b/src/qemu/qemu_monitor_text.c
@@ -650,6 +650,54 @@ error:
return 0;
}
+static int parseMemoryStat(const char *vm_name, char **text, unsigned int tag,
+ const char *search, virDomainMemoryStatPtr stat)
+{
+char *dummy;
+if (STRPREFIX (*text, search)) {
+*text += strlen(search);
+if (virStrToLong_ull (*text, dummy, 10, stat-val)) {
+DEBUG (%s: error reading %s: %s, vm_name, search, *text);
+return 0;
+}
+stat-tag = tag;
+return 1;
+}
+return 0;
+}
+
+/* The reply from the 'info balloon' command may contain additional memory
+ * statistics in the form: '[,tag=val]*'
+ */
+static int qemuMonitorParseExtraBalloonInfo(const virDomainObjPtr vm,
+char *text,
+virDomainMemoryStatPtr stats,
+unsigned int nr_stats)
+{
+char *p = text;
+unsigned int nr_stats_found = 0;
+
+while (*p nr_stats_found nr_stats) {
+if (parseMemoryStat(vm-def-name, p, VIR_MEMSTAT_SWAP_IN,
+,mem_swapped_in=, stats[nr_stats_found]) ||
+parseMemoryStat(vm-def-name, p, VIR_MEMSTAT_SWAP_OUT,
+,mem_swapped_out=, stats[nr_stats_found]) ||
+parseMemoryStat(vm-def-name, p, VIR_MEMSTAT_MAJOR_FAULT,
+,major_page_faults=, stats[nr_stats_found]) ||
+parseMemoryStat(vm-def-name, p, VIR_MEMSTAT_MINOR_FAULT,
+,minor_page_faults=, stats[nr_stats_found]) ||
+parseMemoryStat(vm-def-name, p, VIR_MEMSTAT_MEM_FREE,
+,free_mem=, stats[nr_stats_found]) ||
+parseMemoryStat(vm-def-name, p, VIR_MEMSTAT_MEM_TOTAL,
+,total_mem=, stats[nr_stats_found]))
+nr_stats_found++;
+
+/* Skip to the next label */
+p = strchr (p, ',');
+if (!p) break;
+}
+return nr_stats_found;
+}
/* The reply from QEMU contains 'ballon: actual=421' where value is in MB */
@@ -697,6 +745,31 @@ cleanup:
return ret;
}
+int qemuMonitorGetMemoryStats(const virDomainObjPtr vm,
+
[libvirt] [PATCH 2/6] domMemoryStats: Add public symbol to libvirt API
Add a new function 'virDomainMemoryStats' to the libvirt API. Export it via
libvirt_public.syms
Signed-off-by: Adam Litke a...@us.ibm.com
To: libvirt list libvir-list@redhat.com
---
src/libvirt.c | 64 +++
src/libvirt_public.syms |2 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index b14942d..0af1ee3 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -4045,6 +4045,70 @@ error:
}
/**
+ * virDomainMemStats:
+ * @dom: pointer to the domain object
+ * @stats: nr_stats-sized array of stat structures (returned)
+ * @nr_stats: number of memory statistics requested
+ *
+ * This function provides memory statistics for the domain.
+ *
+ * Up to 'nr_stats' elements of 'stats' will be populated with memory
statistics
+ * from the domain. Only statistics supported by the domain, the driver, and
+ * this version of libvirt will be returned.
+ *
+ * Memory Statistics:
+ *
+ * VIR_MEMSTAT_SWAP_IN:
+ * The total amount of data read from swap space (in bytes).
+ * VIR_MEMSTAT_SWAP_OUT:
+ * The total amount of memory written out to swap space (in bytes).
+ * VIR_MEMSTAT_MAJOR_FAULT:
+ * The number of page faults that required disk IO to service.
+ * VIR_MEMSTAT_MINOR_FAULT:
+ * The number of page faults serviced without disk IO.
+ * VIR_MEMSTAT_MEM_FREE:
+ * The amount of memory which is not being used for any purpose (in bytes).
+ * VIR_MEMSTAT_MEM_TOTAL:
+ * The total amount of memory recognized by the domain's OS (in bytes).
+ *
+ * Returns: The number of stats provided or -1 in case of failure.
+ */
+int virDomainMemoryStats (virDomainPtr dom, virDomainMemoryStatPtr stats,
+ unsigned int nr_stats)
+{
+virConnectPtr conn;
+unsigned long nr_stats_ret = 0;
+DEBUG(domain=%p, stats=%p, nr_stats=%u, dom, stats, nr_stats);
+
+virResetLastError();
+
+if (!VIR_IS_CONNECTED_DOMAIN (dom)) {
+virLibDomainError (NULL, VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
+return -1;
+}
+if (!stats || nr_stats == 0)
+return 0;
+
+if (nr_stats VIR_MEMSTAT_NR_TAGS)
+nr_stats = VIR_MEMSTAT_NR_TAGS;
+
+conn = dom-conn;
+if (conn-driver-domainMemoryStats) {
+nr_stats_ret = conn-driver-domainMemoryStats (dom, stats, nr_stats);
+if (nr_stats_ret == -1)
+goto error;
+return nr_stats_ret;
+}
+
+virLibDomainError (dom, VIR_ERR_NO_SUPPORT, __FUNCTION__);
+
+error:
+/* Copy to connection error object for back compatability */
+virSetConnError(dom-conn);
+return -1;
+}
+
+/**
* virDomainBlockPeek:
* @dom: pointer to the domain object
* @path: path to the block device
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 8921c1a..5761a7e 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -327,6 +327,8 @@ LIBVIRT_0.7.2 {
virStreamAbort;
virStreamFree;
virDomainMigrateToURI;
+# XXX: For testing only -- Move to 0.7.3 section
+virDomainMemoryStats;
} LIBVIRT_0.7.1;
# define new API here using predicted next version number
--
1.6.5
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] implement --pool option for virsh vol-path
This patch fixes the problem reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=509306
The bug reporter says that vol-delete does not support the --pool
option, but that's not the case in the current head. This patch makes
vol-path behave the same way as vol-delete.
Dave
From 97199f44caeeeb38e64079c88fb02fcef35eadaa Mon Sep 17 00:00:00 2001
From: David Allan dal...@redhat.com
Date: Thu, 10 Dec 2009 15:22:20 -0500
Subject: [PATCH 1/1] Add --pool option to vol-path
* Modified vol-path to use the same logic as vol-delete, allowing the syntax:
virsh vol-path --pool testdirpool testvol0
---
tools/virsh.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 94a99e9..7d81c68 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -5275,12 +5275,14 @@ static int
cmdVolPath(vshControl *ctl, const vshCmd *cmd)
{
virStorageVolPtr vol;
+char *name = NULL;
if (!vshConnectionUsability(ctl, ctl-conn, TRUE))
return FALSE;
-if (!(vol = vshCommandOptVolBy(ctl, cmd, vol, pool, NULL,
- VSH_BYUUID)))
+
+if (!(vol = vshCommandOptVol(ctl, cmd, vol, pool, name))) {
return FALSE;
+}
vshPrint(ctl, %s\n, virStorageVolGetPath(vol));
virStorageVolFree(vol);
--
1.6.5.2
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Out of band channels
On Fri, Dec 11, 2009 at 02:32:36PM +, Matthew Booth wrote: A libvirt client can connect to libvirt on a remote host. However, on its own this doesn't give the client a usable level of access. The reason for this is that libvirt doesn't expose some critical management interfaces. For QEMU this amounts to pretty much anything provided directly by the QEMU process, including: * VNC console [1] * Any character device [2] I'm undecided as to whether access to underlying storage falls into this bucket. It would certainly be convenient in certain circumstances. This means, for example that I need out of band access to: * See a graphical console * Connect to a serial console * Connect to a guest channel As these are fairly fundamental operations, I wonder if there has been any thought towards creating tunnels over a libvirt connection. The long term vision that I've had for remote access is that we should aim for 2 network services. The first providing host management. The second providing guest interaction. Currently libvirt RPC (or any of the bindings mentioned below) provide the former, while VNC provides the latter. VNC has already gained the ability to tunnel audio streams, and we've done a proof of concept to make it tunnel serial/guest consoles over the same channel too. There are a handful of other services that could be tunnelled over VNC too, in particular it would be compelling to tunnel a remote CDROM over it as you typically find with bladecenter mgmt consoles. I think it is important to keep the guest interaction vs host management network services separate for a security POV. The libvirtd daemon already arguably has too many privileges with all the APIs it has to support, but at least all those are targetted at the system administrator. Adding the guest admin access into libvirtd makes the consquences of any flaw in it far higher, because the guest admin is a totally untrusted user. This would give them an avenue to raise their privileges. From a network architecture POV too, the two services will likely be delivered separately. For a cloud deployment, the guest services would be exposed to the internet, but host mgmt would certainly be local to the management LAN only. The libvirtd daemon is specifically single host focused. With guest migration, the guest services should really be thought of as host independant. We have had thought about writing a VNC server proxy, to which end users. This proxy would run off node and connection to arbitrary VNC servers in QEMU. Thus end users would never be connecting to a single node, as they do with libvirt. In the first instance, I think this would require a generic method to multiplex multiple streams over a single remote connection. This would obviously be a significant protocol change. Would a messaging protocol, AMQP for instance, be a good candidate here? As Chris notes, the libvirt RPC protocol already allows for tunnelling different things over it, not even requiring them to be API calls. The question though is whether we really want libvirt to become a general purpose RPC service, when there plenty of others out there already ? Taking AMQP as an example, there is already the libvirt-qpid.git agent which exposes libvirt's API over AMQP. There is libvirt CIM which exposes libvirt over CIM. Someone could create a libvirt XMLRPC agent which exposed the APIs over HTTP. I don't think libvirt's RPC needs any changes, since it has already demonstrated the flexibility to integrate as needed. Secondly, I think interfaces which currently create local resources should have a default which is managed by libvirt itself. So you'd have: serial target port='0'/ /serial or serial type='managed' target port='0'/ /serial This would cause libvirt to create whichever host-side chardev is most convenient to it and connect itself. The API would then expose read and write APIs for the named connection. e.g: With the way we are exposing audio (and in the future serial/guest console) to VNC in QEMU there is not neccesarily any need for a particular config. The VNC audio extension implementation in QEMU captures all data from the guest sound cards, no matter how it is configured to output to the host. Likewise our proof of ceontp for serial/guest console tunnelling over VNC captured all data, regardless of where the chardev config was pointing [2] e.g. virsh # console RHEL3.FV.64.IDE error: Cannot connect to a remote console device This is the one thing where I would make an exception to everything I have just said. Serial console access is an important recovery tool for the virtualization host administrator. This implies that we should make it available via the libvirt API. So I think we should try to add a data stream for the serial console over libvirt, if only to make virsh console work. For guest administrators though, I still think they should be accessing the serial console over VNC.
Re: [libvirt] Toward the next 0.7.5 release
On Fri, Dec 11, 2009 at 05:41:12PM +0100, Daniel Veillard wrote: The last release was 0.7.4 on Nov 20, so if we try to keep with the one month release cycle, we would end up with a release on Friday 25, but I really plan on celebrating Chrismas with my familly that day instead of spending time in front of a computer (I plan to roast a pig and that requires all my attention :-) I would prefer to not wait too much, as there were some serious locking bugs in 0.7.4, and I would rather not wait until the end of the vacations either. So I'm tempted to push on Wed 23, with possibly a smaller timeframe for the bug fixes only window. We didn't (yet!) introduce major changes inside (except maybe for the VirtualBox driver and early bug have been reported) and Matthias has been debugging seriously with the TCK so things should be in relatively good shape out of git. So my plan right nw would be to enter freeze, next Friday the 18th and push the release 0f 0.7.5 on the 23rd. So send those patches along and if we forgot to ACK patches please raise our attention about them, thanks ! FYI, after discussions with QEMU community I'm going to force the JSON code to be disabled for all versions of QEMU. Although JSON code exists for all of the monitor commands in QEMU, it does not look like the 0.12 release will have merged them all. So we will aim to enable the JSON code for QEMU 0.13 instead. 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Python script and extension module directory handling
Commit 66137344feb488ea87b0d92f3c03844d9a7a7786 changed the Python detection mechanism in configure. This results in a changed install location for the Python bindings at least on Fedora 12 64bit systems. For the explanation below I assume a Fedora 12 64bit systems, libvirt is configured with prefix /usr and Python 2.6 is installed. Before this commit libvirt.py and libvirtmod.so were installed to /usr/lib64/python2.6/site-packages. After this commit both are installed to /usr/lib/python2.6/site-packages. This is at least wrong for libvirtmod.so, as it should be installed to /usr/lib64/python2.6/site-packages on a 64bit system. Before this commit pythondir was set manually to /usr/lib64/python2.6/site-packages and python/Makefile.am contains 'python_LTLIBRARIES = libvirtmod.la' that results in installing libvirtmod.so to pythondir. AM_PATH_PYTHON defines two variables: pythondir and pyexecdir. But according to the AM_PATH_PYTHON documentation [1] pythondir is the directory where Python scripts should be installed. /usr/lib/python2.6/site-packages in this case, because Python scripts are not architecture dependent in general. pyexecdir is the directory where Python extension modules (shared libraries) should be installed. AM_PATH_PYTHON detects pyexecdir correctly as /usr/lib64/python2.6/site-packages, but python/Makefile.am contains 'python_LTLIBRARIES = libvirtmod.la' that results in installing libvirtmod.so to pythondir. So python/Makefile.am must be changed: diff --git a/python/Makefile.am b/python/Makefile.am index 736631e..04342b7 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -32,7 +32,7 @@ mylibs = $(top_builddir)/src/libvirt.la all-local: libvirt.py -python_LTLIBRARIES = libvirtmod.la +pyexec_LTLIBRARIES = libvirtmod.la libvirtmod_la_SOURCES = libvirt-override.c typewrappers.c libvirt.c libvirt.h # Python = 2.4 header files contain a redundant decl, hence we Now libvirtmod.so is installed to the correct directory: /usr/lib64/python2.6/site-packages But libvirt.py gets installed to /usr/lib/python2.6/site-packages, this is different from the installation directory before the commit. A default Fedora 12 64bit installation has *.py files installed to /usr/lib/python2.6/site-packages and /usr/lib64/python2.6/site-packages. By looking at both directories the policy it pretty obvious: Packages that are pure Python go to /usr/lib/python2.6/site-packages and packages that are mixed (Python and shared libraries) go completely to /usr/lib64/python2.6/site-packages. So we restore the behavior from before the commit completely by applying this additional patch: diff --git a/python/Makefile.am b/python/Makefile.am index 736631e..04342b7 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -60,14 +60,14 @@ $(GENERATED): generated.stamp $(libvirtmod_la_OBJECTS): $(GENERATED) install-data-local: - $(mkinstalldirs) $(DESTDIR)$(pythondir) - @INSTALL@ -m 0644 libvirt.py $(DESTDIR)$(pythondir) + $(mkinstalldirs) $(DESTDIR)$(pyexecdir) + @INSTALL@ -m 0644 libvirt.py $(DESTDIR)$(pyexecdir) $(mkinstalldirs) $(DESTDIR)$(DOCS_DIR) @(for doc in $(DOCS) ; \ do @INSTALL@ -m 0644 $$doc $(DESTDIR)$(DOCS_DIR) ; done) uninstall-local: - rm -f $(DESTDIR)$(pythondir)/libvirt.py + rm -f $(DESTDIR)$(pyexecdir)/libvirt.py CLEANFILES= $(GENERATED) generated.stamp I discussed this with Daniel Veillard on IRC and there was some confusion what the actual problem was and how to solve it, so I wanted to recap it here. Also thanks to Daniel Hokka Zakrisson, who gave the important hint about pythondir vs pyexecdir on IRC. [1] http://www.gnu.org/software/hello/manual/automake/Python.html Matthias From 1f5083be1dcbf6877dfbae44e9ea4e50ebaec708 Mon Sep 17 00:00:00 2001 From: Matthias Bolte matthias.bo...@googlemail.com Date: Sat, 12 Dec 2009 00:11:31 +0100 Subject: [PATCH] Fix install location for Python bindings Commit 66137344feb488ea87b0d92f3c03844d9a7a7786 changed the Python detection mechanism in configure to use AM_PATH_PYTHON. This results in a changed install location for the Python bindings, at least on Fedora 12 64bit systems. Before this commit libvirt.py and libvirtmod.so were installed to /usr/lib64/python2.6/site-packages After this commit they are installed to /usr/lib/python2.6/site-packages Mixed Python packages (containing *.py and *.so files) should be installed to the pyexecdir directory detected by AM_PATH_PYTHON. This restores the install location from before the AM_PATH_PYTHON commit. * configure.in: remove unnecessary pythondir export * python/Makefile.am: switch from pythondir to pyexecdir --- configure.in |2 -- python/Makefile.am |8 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/configure.in b/configure.in index fe9834d..d80cebf 100644 --- a/configure.in +++ b/configure.in @@ -1443,7 +1443,6 @@ AC_ARG_WITH([python], PYTHON_VERSION=
[libvirt] [PATCH] Eliminate failure to delete empty storage pools
virStorageBackendFileSystemDelete was incorrectly calling unlink() in
an attempt to remove a directory. It should be calling rmdir()
instead. (remove() would also work, but could potentially succeed on a
non-empty pool if the pool was a symlink to somewhere else).
---
src/storage/storage_backend_fs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/storage/storage_backend_fs.c b/src/storage/storage_backend_fs.c
index 16e4bd9..b7d4bd6 100644
--- a/src/storage/storage_backend_fs.c
+++ b/src/storage/storage_backend_fs.c
@@ -693,9 +693,9 @@ virStorageBackendFileSystemDelete(virConnectPtr conn,
{
/* XXX delete all vols first ? */
-if (unlink(pool-def-target.path) 0) {
+if (rmdir(pool-def-target.path) 0) {
virReportSystemError(conn, errno,
- _(cannot unlink path '%s'),
+ _(failed to remove pool '%s'),
pool-def-target.path);
return -1;
}
--
1.6.6.rc2.5.g49666
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
