Re: [libvirt] [PATCHv2] security: properly chown/label bidirectional and unidirectional fifos
On Tue, Sep 27, 2011 at 09:00:15PM -0400, Laine Stump wrote:
> (v2: change to only relabel the uni-direction fifo pair if they're
> found, otherwise only relabel the bidirectional fifo, per comment in BZ
> by Dan Berrange)
>
> This patch fixes the regression with using named pipes for qemu serial
> devices noted in:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=740478
>
> The problem was that, while new code in libvirt looks for a single
> bidirectional fifo of the name given in the config, then relabels that
> and continues without looking for / relabelling the two unidirectional
> fifos named ${name}.in and ${name}.out, qemu looks in the opposite
> order. So if the user had naively created all three fifos, libvirt
> would relabel the bidirectional fifo to allow qemu access, but qemu
> would attempt to use the two unidirectional fifos and fail (because it
> didn't have proper permissions/rights).
>
> This patch changes the order that libvirt looks for the fifos to match
> what qemu does - first it looks for the dual fifos, then it looks for
> the single bidirectional fifo. If it finds the dual unidirectional
> fifos first, it labels/chowns them and ignores any possible
> bidirectional fifo.
>
> (Note commit d37c6a3a (which first appeared in libvirt-0.9.2) added
> the code that checked for a bidirectional fifo. Prior to that commit,
> bidirectional fifos fdor serial devices didn't work unless the fifo
> was pre-owned/labelled such that qemu could access it.)
> ---
> src/security/security_dac.c | 30 ++
> src/security/security_selinux.c | 29 +
> 2 files changed, 35 insertions(+), 24 deletions(-)
>
> diff --git a/src/security/security_dac.c b/src/security/security_dac.c
> index af02236..ac79e70 100644
> --- a/src/security/security_dac.c
> +++ b/src/security/security_dac.c
> @@ -406,18 +406,19 @@ virSecurityDACSetChardevLabel(virSecurityManagerPtr mgr,
> break;
>
> case VIR_DOMAIN_CHR_TYPE_PIPE:
> -if (virFileExists(dev->data.file.path)) {
> -if (virSecurityDACSetOwnership(dev->data.file.path, priv->user,
> priv->group) < 0)
> -goto done;
> -} else {
> -if ((virAsprintf(&in, "%s.in", dev->data.file.path) < 0) ||
> -(virAsprintf(&out, "%s.out", dev->data.file.path) < 0)) {
> -virReportOOMError();
> -goto done;
> -}
> +if ((virAsprintf(&in, "%s.in", dev->data.file.path) < 0) ||
> +(virAsprintf(&out, "%s.out", dev->data.file.path) < 0)) {
> +virReportOOMError();
> +goto done;
> +}
> +if (virFileExists(in) || virFileExists(out)) {
Actually the qemu code of qemu_chr_open_pipe() does
if (fd_in < 0 || fd_out < 0) {
close either if they opened and try to open the main file
so the logic in libvirt should be
if (virFileExists(in) && virFileExists(out)) {
> if ((virSecurityDACSetOwnership(in, priv->user, priv->group) <
> 0) ||
> -(virSecurityDACSetOwnership(out, priv->user, priv->group) <
> 0))
> +(virSecurityDACSetOwnership(out, priv->user, priv->group) <
> 0)) {
> goto done;
> +}
> +} else if (virSecurityDACSetOwnership(dev->data.file.path,
> + priv->user, priv->group) < 0) {
> +goto done;
> }
> ret = 0;
> break;
> @@ -452,9 +453,14 @@ virSecurityDACRestoreChardevLabel(virSecurityManagerPtr
> mgr ATTRIBUTE_UNUSED,
> virReportOOMError();
> goto done;
> }
> -if ((virSecurityDACRestoreSecurityFileLabel(out) < 0) ||
> -(virSecurityDACRestoreSecurityFileLabel(in) < 0))
> +if (virFileExists(in) || virFileExists(out)) {
Same
> +if ((virSecurityDACRestoreSecurityFileLabel(out) < 0) ||
> +(virSecurityDACRestoreSecurityFileLabel(in) < 0)) {
> goto done;
> +}
> +} else if
> (virSecurityDACRestoreSecurityFileLabel(dev->data.file.path) < 0) {
> +goto done;
> +}
> ret = 0;
> break;
>
> diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
> index 0807a34..9e5b668 100644
> --- a/src/security/security_selinux.c
> +++ b/src/security/security_selinux.c
> @@ -806,18 +806,18 @@ SELinuxSetSecurityChardevLabel(virDomainObjPtr vm,
> break;
>
> case VIR_DOMAIN_CHR_TYPE_PIPE:
> -if (virFileExists(dev->data.file.path)) {
> -if (SELinuxSetFilecon(dev->data.file.path, secdef->imagelabel) <
> 0)
> -goto done;
> -} else {
> -if ((virAsprintf(&in, "%s.in", dev->data.file.path) < 0) ||
> -(virAsprintf(&out, "%s.out", dev->data.file.path) < 0)) {
> -virReportOOMError();
> -goto done;
> -
Re: [libvirt] [PATCH] qemu: qxl devices don't support multifunction yet
On 09/27/2011 05:13 AM, Daniel P. Berrange wrote:
On Tue, Sep 27, 2011 at 01:19:20AM -0400, Laine Stump wrote:
On 09/19/2011 01:32 PM, Daniel P. Berrange wrote:
On Mon, Sep 19, 2011 at 07:16:22PM +0200, Marc-André Lureau wrote:
Hi hi
On Fri, Sep 16, 2011 at 1:38 PM, Marc-André Lureau wrote:
How do we allow other devices to share the slot? It seems to me that
qemuDomainPCIAddressSetNextAddr() only allocate whole slot, while
making sure there is no conflicts on the same slot.
So, if the user wants to use multi function pci device, he should
specify the
pci address.
So adding a check such as:
if (!multiFunc&& info->addr.pci.function != 0)
return error("The %s device doesn't support multifunction address")
Wen, does that sound reasonable to you?
Daniel, did you had time to verify that PCI allocation is per-slot?
(It would be nice to get this "workaround" for the next release)
IMHO this kind of hack doesn't belong in libvirt. It is fine for distro
vendors to consider as a one off quick-hack for their packages of libvirt,
if they don't have time to fix the real QXL bug, but not for libvirt
upstream releases. QXL/QEMU should really be fixed since that's where the
problem appears to lie.
As it stands, Fedora 16 (currently using unpatched libvirt-0.9.6)
will be going into beta with QXL video broken for Windows guests, so
we need some kind of Fedora-only patch very soon (see the schedule
here: https://fedoraproject.org/wiki/Releases/16/Schedule -
fortunately just delayed another week)
The original patch in this thread:
https://www.redhat.com/archives/libvir-list/2011-September/msg00534.html
of course doesn't include the above mentioned additional code, and
there isn't a followup patch. It would be very good to push a patch
to the F16 git for this so it would hopefully get into the beta, but
want to make sure what I push is the "right" thing, so a "final"
patch (and some testing by people with F16 hosts) would be very
helpful!
When we originally enabled multifunction for all PCI devices, we did so
in the belief that this was effectively a no-op for guest OSes. ie it
should not have changed guest OS behaviour at all, unless multiple devices
were actually inserted in the slot.
Evidentally this turns out to be incorrect. In other words we introduced
a guest ABI change. This is very bad, because our stated goal is to have
a stable guest ABI across libvirt& QEMU releases.
Thus IMHO we need to disable *all* setting of the 'multifunction=on'
parameter for all guests by default, to unbreak the ABI compatibility.
Of course this has been in since 0.9.3, meaning there are official
releases with broken ABI compatibility :-(. Still, the sooner it's fixed
the better.
Then we should introduce a new parameter 'multifunction='on' in the
element to allow it to be optionally enabled per
device.
Will it be acceptable to put that in a patch on top of 0.9.6 for Fedora
16? (I think the answer is "yes", since it's only an XML change, but
just want to make sure).
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix AppArmor driver for pipe character devices
On Tue, Sep 27, 2011 at 01:44:59PM -0500, Jamie Strandboge wrote:
> The AppArmor security driver adds only the path specified in the domain
> XML for character devices of type 'pipe'. It should be using .in
> and .out. We do this by creating a new vah_add_file_chardev() and
> use it for char devices instead of vah_add_file(). Also adjust
> valid_path() to accept S_FIFO (since qemu chardevs of type 'pipe' use
> fifos). This is https://launchpad.net/bugs/832507
>
> --
> Jamie Strandboge | http://www.canonical.com
> Author: Jamie Strandboge
> Description: fix AppArmor driver for pipe character devices
> The AppArmor security driver adds only the path specified in the domain XML
> for character devices of type 'pipe'. It should be using .in and
> .out. We do this by creating a new vah_add_file_chardev() and use
> it for char devices instead of vah_add_file(). Also adjust valid_path() to
> accept S_FIFO (since qemu chardevs of type 'pipe' use fifos).
> Bug-Ubuntu: https://launchpad.net/bugs/832507
>
> diff -Naurp libvirt.orig/src/security/virt-aa-helper.c
> libvirt/src/security/virt-aa-helper.c
> --- libvirt.orig/src/security/virt-aa-helper.c2011-09-27
> 11:24:27.0 -0500
> +++ libvirt/src/security/virt-aa-helper.c 2011-09-27 13:23:00.0
> -0500
> @@ -3,7 +3,7 @@
> * virt-aa-helper: wrapper program used by AppArmor security driver.
> *
> * Copyright (C) 2010-2011 Red Hat, Inc.
> - * Copyright (C) 2009-2010 Canonical Ltd.
> + * Copyright (C) 2009-2011 Canonical Ltd.
> *
> * See COPYING.LIB for the License of this software
> *
> @@ -568,9 +568,6 @@ valid_path(const char *path, const bool
> case S_IFDIR:
> return 1;
> break;
> -case S_IFIFO:
> -return 1;
> -break;
> case S_IFSOCK:
> return 1;
> break;
> @@ -796,6 +793,51 @@ vah_add_file(virBufferPtr buf, const cha
> }
>
> static int
> +vah_add_file_chardev(virBufferPtr buf,
> + const char *path,
> + const char *perms,
> + const int type)
> +{
> +char *pipe_in;
> +char *pipe_out;
> +int rc = -1;
> +
> +if (type == VIR_DOMAIN_CHR_TYPE_PIPE) {
> +/* add the pipe input */
> +if (virAsprintf(&pipe_in, "%s.in", path) == -1) {
> +vah_error(NULL, 0, _("could not allocate memory"));
> +goto clean;
> +}
> +
> +if (vah_add_file(buf, pipe_in, perms) != 0)
> +goto clean_pipe_in;
> +
> +/* add the pipe output */
> +if (virAsprintf(&pipe_out, "%s.out", path) == -1) {
> +vah_error(NULL, 0, _("could not allocate memory"));
> +goto clean_pipe_in;
> +}
> +
> +if (vah_add_file(buf, pipe_out, perms) != 0)
> +goto clean_pipe_out;
> +
> +rc = 0;
> + clean_pipe_out:
> +VIR_FREE(pipe_out);
> + clean_pipe_in:
> +VIR_FREE(pipe_in);
> +} else {
> +/* add the file */
> +if (vah_add_file(buf, path, perms) != 0)
> +goto clean;
> +rc = 0;
> +}
> +
> + clean:
> +return rc;
> +}
> +
> +static int
> file_iterate_hostdev_cb(usbDevice *dev ATTRIBUTE_UNUSED,
> const char *file, void *opaque)
> {
> @@ -835,7 +877,6 @@ add_file_path(virDomainDiskDefPtr disk,
> return ret;
> }
>
> -
> static int
> get_files(vahControl * ctl)
> {
> @@ -878,12 +919,17 @@ get_files(vahControl * ctl)
> ctl->def->serials[i]->source.type == VIR_DOMAIN_CHR_TYPE_FILE ||
> ctl->def->serials[i]->source.type == VIR_DOMAIN_CHR_TYPE_PIPE)
> &&
> ctl->def->serials[i]->source.data.file.path)
> -if (vah_add_file(&buf,
> - ctl->def->serials[i]->source.data.file.path,
> "rw") != 0)
> +if (vah_add_file_chardev(&buf,
> +
> ctl->def->serials[i]->source.data.file.path,
> + "rw",
> + ctl->def->serials[i]->source.type) != 0)
> goto clean;
>
> if (ctl->def->console && ctl->def->console->source.data.file.path)
> -if (vah_add_file(&buf, ctl->def->console->source.data.file.path,
> "rw") != 0)
> +if (vah_add_file_chardev(&buf,
> + ctl->def->console->source.data.file.path,
> + "rw",
> + ctl->def->console->source.type) != 0)
> goto clean;
>
> for (i = 0 ; i < ctl->def->nparallels; i++)
> @@ -893,9 +939,10 @@ get_files(vahControl * ctl)
> ctl->def->parallels[i]->source.type == VIR_DOMAIN_CHR_TYPE_FILE
> ||
> ctl->def->parallels[i]->source.type ==
> VIR_DOMAIN_CHR_TYPE_PIPE) &&
> ctl->def->parallels[i]->source.data.file.path)
> -
[libvirt] [PATCH] qemu: Init the pci device before reattachment
This patch is just like commit 2ce90ea296, to init the member of
pciDevice before reattachment, otherwise the device won't be unbound
from pci_stub, and won't get the original driver (no probing).
---
src/qemu/qemu_hostdev.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c
index 6f77717..74c817c 100644
--- a/src/qemu/qemu_hostdev.c
+++ b/src/qemu/qemu_hostdev.c
@@ -292,6 +292,7 @@ void qemuDomainReAttachHostdevDevices(struct qemud_driver
*driver,
for (i = 0; i < pciDeviceListCount(pcidevs); i++) {
pciDevice *dev = pciDeviceListGet(pcidevs, i);
+pciDeviceReAttachInit(dev);
qemuReattachPciDevice(dev, driver);
}
--
1.7.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: Allow using complete elements with cpu-baseline
Dňa 27.9.2011 17:26, Eric Blake wrote / napísal(a): ACK if you squash this in: diff --git i/tools/virsh.c w/tools/virsh.c index 3e05ce9..1863db3 100644 --- i/tools/virsh.c +++ w/tools/virsh.c @@ -384,9 +384,6 @@ static void *_vshMalloc(vshControl *ctl, size_t sz, const char *filename, int li static void *_vshCalloc(vshControl *ctl, size_t nmemb, size_t sz, const char *filename, int line); #define vshCalloc(_ctl, _nmemb, _sz) _vshCalloc(_ctl, _nmemb, _sz, __FILE__, __LINE__) Uh, thanks for noticing that. I somehow forgot to fix that even after I saw gcc complaining :( Thanks, pushed. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: Allow using domain and capabilities XMLs with cpu-compare
Dňa 27.9.2011 17:29, Eric Blake wrote / napísal(a):
On 09/15/2011 03:40 AM, Peter Krempa wrote:
+ if (virFileReadAll(from, VIRSH_MAX_XML_FILE,&buffer)< 0) {
+ vshError(ctl, _("Failed to read file '%s' to compare."),
Generally we don't use trailing . in error messages.
ACK with that nit fixed.
Thanks, fixed and pushed.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Init the pci device before reattachment
At 09/28/2011 03:47 PM, Osier Yang Write:
> This patch is just like commit 2ce90ea296, to init the member of
> pciDevice before reattachment, otherwise the device won't be unbound
> from pci_stub, and won't get the original driver (no probing).
> ---
> src/qemu/qemu_hostdev.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c
> index 6f77717..74c817c 100644
> --- a/src/qemu/qemu_hostdev.c
> +++ b/src/qemu/qemu_hostdev.c
> @@ -292,6 +292,7 @@ void qemuDomainReAttachHostdevDevices(struct qemud_driver
> *driver,
>
> for (i = 0; i < pciDeviceListCount(pcidevs); i++) {
> pciDevice *dev = pciDeviceListGet(pcidevs, i);
> +pciDeviceReAttachInit(dev);
> qemuReattachPciDevice(dev, driver);
> }
>
The user runs 'virsh attach-device' to pass through host pci device to guest
os. We will call the function qemuPrepareHostdevPCIDevices() to bind the pci
device to pci-stub, and reset it. If the pci device does not support reset
function,
we will call pciReAttachDevice() to rollback the things we have done.
If the device is alread bound to pci-stub before the user runs 'virsh
attach-device',
we should do nothing. If the device is not bound to any driver, we should
unbound it from pci-stub. If the device is bound to other driver, we should
unbound it from pci-stub, and reprobe it.
With your patch, we can not rollback the things we have done.
What problems do you meet?
Thanks
Wen Congyang.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix AppArmor driver for pipe character devices
On Wed, Sep 28, 2011 at 03:07:16PM +0800, Daniel Veillard wrote: > On Tue, Sep 27, 2011 at 01:44:59PM -0500, Jamie Strandboge wrote: > > The AppArmor security driver adds only the path specified in the domain > > XML for character devices of type 'pipe'. It should be using .in > > and .out. We do this by creating a new vah_add_file_chardev() and > > use it for char devices instead of vah_add_file(). Also adjust > > valid_path() to accept S_FIFO (since qemu chardevs of type 'pipe' use > > fifos). This is https://launchpad.net/bugs/832507 [...] > Sounds familiar, ACK ... And pushed now ! 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] [libvirt-glib] Plug a leak
On Tue, Sep 27, 2011 at 11:47:06PM +0300, Zeeshan Ali (Khattak) wrote: > From: "Zeeshan Ali (Khattak)" > > --- > libvirt-gobject/libvirt-gobject-connection.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/libvirt-gobject/libvirt-gobject-connection.c > b/libvirt-gobject/libvirt-gobject-connection.c > index 074fe53..f97b50a 100644 > --- a/libvirt-gobject/libvirt-gobject-connection.c > +++ b/libvirt-gobject/libvirt-gobject-connection.c > @@ -645,6 +645,8 @@ gboolean > gvir_connection_fetch_storage_pools(GVirConnection *conn, > ret = TRUE; > > cleanup: > +for (i = 0 ; i < nactive ; i++) > +g_free(active[i]); > g_free(active); > for (i = 0 ; i < ninactive ; i++) > g_free(inactive[i]); ACK Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2] qemu: add return value check
From: Alex Jia
* src/qemu/qemu_migration.c: if 'vmdef' is NULL, the function
virDomainSaveConfig still dereferences it, it doesn't make
sense, so should add return value check to make sure 'vmdef'
is non-NULL before calling virDomainSaveConfig, in addition,
in order to debug later, also should record error information
into log.
Signed-off-by: Alex Jia
---
src/qemu/qemu_migration.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index ef48d65..a009a57 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2582,7 +2582,7 @@ qemuMigrationFinish(struct qemud_driver *driver,
vm->newDef = vmdef = mig->persistent;
else
vmdef = virDomainObjGetPersistentDef(driver->caps, vm);
-if (virDomainSaveConfig(driver->configDir, vmdef) < 0) {
+if (!vmdef || virDomainSaveConfig(driver->configDir, vmdef) < 0) {
/* Hmpf. Migration was successful, but making it persistent
* was not. If we report successful, then when this domain
* shuts down, management tools are in for a surprise. On the
@@ -2603,6 +2603,9 @@ qemuMigrationFinish(struct qemud_driver *driver,
if (newVM)
vm->persistent = 0;
}
+if (!vmdef)
+qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+_("can't get vmdef"));
goto endjob;
}
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Qemu/KVM is 3x slower under libvirt
On Tue, Sep 27, 2011 at 08:10:21PM +0200, Reeted wrote: > I repost this, this time by also including the libvirt mailing list. > > Info on my libvirt: it's the version in Ubuntu 11.04 Natty which is > 0.8.8-1ubuntu6.5 . I didn't recompile this one, while Kernel and > qemu-kvm are vanilla and compiled by hand as described below. > > My original message follows: > > This is really strange. > > I just installed a new host with kernel 3.0.3 and Qemu-KVM 0.14.1 > compiled by me. > > I have created the first VM. > This is on LVM, virtio etc... if I run it directly from bash > console, it boots in 8 seconds (it's a bare ubuntu with no > graphics), while if I boot it under virsh (libvirt) it boots in > 20-22 seconds. This is the time from after Grub to the login prompt, > or from after Grub to the ssh-server up. > > I was almost able to replicate the whole libvirt command line on the > bash console, and it still goes almost 3x faster when launched from > bash than with virsh start vmname. The part I wasn't able to > replicate is the -netdev part because I still haven't understood the > semantics of it. -netdev is just an alternative way of setting up networking that avoids QEMU's nasty VLAN concept. Using -netdev allows QEMU to use more efficient codepaths for networking, which should improve the network performance. > This is my bash commandline: > > /opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm > -m 2002 -smp 2,sockets=2,cores=1,threads=1 -name vmname1-1 -uuid > ee75e28a-3bf3-78d9-3cba-65aa63973380 -nodefconfig -nodefaults > -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/vmname1-1.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc > -boot order=dc,menu=on -drive > file=/dev/mapper/vgPtpVM-lvVM_Vmname1_d1,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none,aio=native > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 > -drive > if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,cache=none,aio=native > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 > -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no > -usb -vnc 127.0.0.1:0 -vga cirrus -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 This shows KVM is being requested, but we should validate that KVM is definitely being activated when under libvirt. You can test this by doing: virsh qemu-monitor-command vmname1 'info kvm' > Which was taken from libvirt's command line. The only modifications > I did to the original libvirt commandline (seen with ps aux) were: > > - Removed -S Fine, has no effect on performance. > - Network was: -netdev tap,fd=17,id=hostnet0,vhost=on,vhostfd=18 > -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3 > Has been simplified to: -net nic,model=virtio -net > tap,ifname=tap0,script=no,downscript=no > and manual bridging of the tap0 interface. You could have equivalently used -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3 That said, I don't expect this has anything todo with the performance since booting a guest rarely involves much network I/O unless you're doing something odd like NFS-root / iSCSI-root. > Firstly I had thought that this could be fault of the VNC: I have > compiled qemu-kvm with no separate vnc thread. I thought that > libvirt might have connected to the vnc server at all times and this > could have slowed down the whole VM. > But then I also tried connecting vith vncviewer to the KVM machine > launched directly from bash, and the speed of it didn't change. So > no, it doesn't seem to be that. Yeah, I have never seen VNC be responsible for the kind of slowdown you describe. > BTW: is the slowdown of the VM on "no separate vnc thread" only in > effect when somebody is actually connected to VNC, or always? Probably, but again I dont think it is likely to be relevant here. > Also, note that the time difference is not visible in dmesg once the > machine has booted. So it's not a slowdown in detecting devices. > Devices are always detected within the first 3 seconds, according to > dmesg, at 3.6 seconds the first ext4 mount begins. It seems to be > really the OS boot that is slow... it seems an hard disk performance > problem. There are a couple of things that would be different between running the VM directly, vs via libvirt. - Security drivers - SELinux/AppArmour - CGroups If it is was AppArmour causing this slowdown I don't think you would have been the first person to complain, so lets ignore that. Which leaves cgroups as a likely culprit. Do a grep cgroup /proc/mounts if any of them are mounted, then for each cgroups mount in turn, - Umount the cgroup - Restart libvirtd - Test your guest boot performance Regards, Daniel -- |: http://berrange.com -o-h
Re: [libvirt] [PATCH] Allow use of file images for LXC container filesystems
On Tue, Sep 27, 2011 at 05:27:42PM -0600, Eric Blake wrote:
> On 08/04/2011 09:41 AM, Daniel P. Berrange wrote:
> >From: "Daniel P. Berrange"
> >
> >A previous commit gave the LXC driver the ability to mount
> >block devices for the container filesystem. Through use of
> >the loopback device functionality, we can build on this to
> >support use of plain file images for LXC filesytems.
> >
> >By setting the LO_FLAGS_AUTOCLEAR flag we can ensure that
> >the loop device automatically disappears when the container
> >dies / shuts down
> >
>
> >+static int lxcSetupLoopDevice(virDomainFSDefPtr fs)
> >+{
> >+int lofd = -1;
> >+int fsfd = -1;
> >+struct loop_info64 lo;
> >+char *loname = NULL;
> >+int ret = -1;
> >+
> >+if ((lofd = lxcGetLoopFD(&loname))< 0)
> >+return -1;
> >+
> >+memset(&lo, 0, sizeof(lo));
> >+lo.lo_flags = LO_FLAGS_AUTOCLEAR;
>
> The kernel headers available on RHEL 5 or CentOS 5 lack this enum
> value, which causes compilation to fail if you are trying to build
> lxc support for these older systems. When I have some time, I will
> probably just write a patch that adds a configure.ac probe for
> LO_FLAGS_AUTOCLEAR, and where it is missing, make any attempt to do
> plan9 file system passthrough to lxc guests fail since they are
> unsupported on these old kernels. You should still be able to use
> the other aspects of lxc that don't involve file system passthrough,
> although obviously lxc isn't getting much testing on these older
> systems.
plan9 FS is only a KVM thing.
This code shouldn't ever be being compiled on RHEL5, since it does not
have any kernel container namespace support at all. So if we have a new
enough kernel for LXC, we should have LO_FLAGS_AUTOCLEAR
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib] Refactor two very huge functions a bit
On Wed, Sep 28, 2011 at 12:36:48AM +0300, Zeeshan Ali (Khattak) wrote:
> From: "Zeeshan Ali (Khattak)"
>
> ---
> libvirt-gobject/libvirt-gobject-connection.c | 126
> ++
> 1 files changed, 69 insertions(+), 57 deletions(-)
>
> diff --git a/libvirt-gobject/libvirt-gobject-connection.c
> b/libvirt-gobject/libvirt-gobject-connection.c
> index f97b50a..c0c47da 100644
> --- a/libvirt-gobject/libvirt-gobject-connection.c
> +++ b/libvirt-gobject/libvirt-gobject-connection.c
> @@ -374,6 +374,51 @@ void gvir_connection_close(GVirConnection *conn)
> g_signal_emit_by_name(conn, "vir-connection-closed");
> }
>
> +typedef gint (* CountFunction) (virConnectPtr vconn);
> +typedef gint (* ListFunction) (virConnectPtr vconn, gchar **lst, gint max);
> +
> +static gchar ** fetch_list(virConnectPtr vconn,
> + const char *name,
> + CountFunction count_func,
> + ListFunction list_func,
> + GCancellable *cancellable,
> + gint *length,
> + GError **err)
> +{
> +gchar **lst = NULL;
> +gint n = 0;
> +gint i;
> +
> +if ((n = count_func(vconn)) < 0) {
> +*err = gvir_error_new(GVIR_CONNECTION_ERROR,
> + 0,
> + "Unable to count %s", name);
> +goto error;
> +}
> +
> +if (n) {
> +if (g_cancellable_set_error_if_cancelled(cancellable, err))
> +goto error;
> +
> +lst = g_new(gchar *, n);
> +if ((n = list_func(vconn, lst, n)) < 0) {
> +*err = gvir_error_new(GVIR_CONNECTION_ERROR,
> + 0,
> + "Unable to list %s %d", name, n);
> +goto error;
> +}
> +}
> +
> +*length = n;
> +return lst;
> +
> +error:
> +for (i = 0 ; i < n; i++)
> +g_free(lst[i]);
> +g_free(lst);
> +return NULL;
> +}
> +
> /**
> * gvir_connection_fetch_domains:
> * @conn: the connection
> @@ -431,25 +476,15 @@ gboolean gvir_connection_fetch_domains(GVirConnection
> *conn,
> if (g_cancellable_set_error_if_cancelled(cancellable, err))
> goto cleanup;
>
> -if ((ninactive = virConnectNumOfDefinedDomains(vconn)) < 0) {
> -*err = gvir_error_new(GVIR_CONNECTION_ERROR,
> - 0,
> - "Unable to count domains");
> +inactive = fetch_list(vconn,
> + "Domains",
> + virConnectNumOfDefinedDomains,
> + virConnectListDefinedDomains,
> + cancellable,
> + &ninactive,
> + err);
> +if (*err != NULL)
> goto cleanup;
> -}
> -
> -if (ninactive) {
> -if (g_cancellable_set_error_if_cancelled(cancellable, err))
> -goto cleanup;
> -
> -inactive = g_new(gchar *, ninactive);
> -if ((ninactive = virConnectListDefinedDomains(vconn, inactive,
> ninactive)) < 0) {
> -*err = gvir_error_new(GVIR_CONNECTION_ERROR,
> - 0,
> - "Unable to list domains %d", ninactive);
> -goto cleanup;
> -}
> -}
>
> doms = g_hash_table_new_full(g_str_hash,
> g_str_equal,
> @@ -544,51 +579,28 @@ gboolean
> gvir_connection_fetch_storage_pools(GVirConnection *conn,
> if (g_cancellable_set_error_if_cancelled(cancellable, err))
> goto cleanup;
>
> -if ((nactive = virConnectNumOfStoragePools(vconn)) < 0) {
> -*err = gvir_error_new(GVIR_CONNECTION_ERROR,
> - 0,
> - "Unable to count pools");
> +active = fetch_list(vconn,
> +"Storage Pools",
> +virConnectNumOfStoragePools,
> +virConnectListStoragePools,
> +cancellable,
> +&nactive,
> +err);
> +if (*err != NULL)
> goto cleanup;
> -}
> -if (nactive) {
> -if (g_cancellable_set_error_if_cancelled(cancellable, err))
> -goto cleanup;
> -
> -active = g_new(gchar *, nactive);
> -if ((nactive = virConnectListStoragePools(vconn,
> - active,
> - nactive)) < 0) {
> -*err = gvir_error_new(GVIR_CONNECTION_ERROR,
> - 0,
> - "Unable to list pools");
> -goto cleanup;
> -}
> -}
>
> if (g_cancellable_set_error_if_cancelled(cancellable, err))
> goto cleanup;
>
> -if ((ninactive = virConnectNumOfDefinedStoragePools(vconn)) < 0
Re: [libvirt] [PATCH v2] qemu: Always remove domain object if MigratePrepare fails
On Tue, Sep 27, 2011 at 09:26:59 -0600, Eric Blake wrote: > On 09/27/2011 07:23 AM, Jiri Denemark wrote: > > If migration failed in Prepare phase after virDomainAssignDef and before > > a job is started, the domain object was not properly removed. > > --- > > Notes: > > Version 2: > > - only remove the inactive domain if ret< 0 > > > > src/qemu/qemu_migration.c | 11 ++- > > 1 files changed, 6 insertions(+), 5 deletions(-) > > ACK. Pushed, thanks. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Finish domain shutdown on reconnect
On Tue, Sep 27, 2011 at 09:23:03 -0600, Eric Blake wrote: > On 09/27/2011 07:04 AM, Jiri Denemark wrote: > > If a domain started with -no-shutdown shuts down while libvirtd is not > > running, it will be seen as paused when libvirtd reconnects to it. Use > > the paused reason to detect if a domain was stopped because of shutdown > > and finish the process just as if a SHUTDOWN event is delivered from > > qemu. > > --- > > src/qemu/qemu_process.c | 50 > > -- > > 1 files changed, 35 insertions(+), 15 deletions(-) > > ACK. Pushed, thanks. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] AHCI support in qemu driver
On Tue, Sep 27, 2011 at 10:22:48PM -0600, Jim Fehlig wrote:
> I have some time this week to work on libvirt and thought Daniel's
> suggestion [1] for adding AHCI support in the qemu driver would be a
> useful endeavor.
>
> I've managed to start a qemu instance using AHCI with attached hackery,
> iff I have a controller defined. E.g.
>
>
>
>
>
>
>
> function='0x0'/>
>
>
> which results in qemu args
>
> -device ahci,id=ahci0,bus=pci.0,multifunction=on,addr=0x3.0x0 -drive
> file=/var/lib/libvirt/images/test/disk0.raw,if=none,id=drive-sata-dik0,format=raw
> -device
> ide-drive,bus=ahci0.0,drive=drive-sata-disk0,id=sata-disk0,bootindex=1
>
> If the controller is not explicitly defined, the AHCI device (-device
> ahci,...) is not created and qemu fails with
>
> qemu-kvm: -device
> ide-drive,bus=ahci0.0,drive=drive-sata-disk0,id=sata-disk0,bootindex=1:
> Bus 'a
> hci0.0' not found
>
> I'm not quite sure how to create the controller when not explicitly
> defined in the config.
There is a function virDomainDefAddImplicitControllers() in the
domain_conf.c which looks to be missing the SATA case.
> Also, I suspect there are many things I'm missing in adding support for
> this controller. E.g., I've ignored hotplug for the moment. What would
> be considered minimal functionality for supporting this controller?
Just being able to launch a guest + the test data files for qemuxml2argvtest
would be the minimum. Hotplug would be desirable if it works in QEMU, but
not critical.
> >From 02c793bdc86e3f7f1775f58ef4776e32512ecdb8 Mon Sep 17 00:00:00 2001
> From: Jim Fehlig
> Date: Tue, 27 Sep 2011 21:46:08 -0600
> Subject: [PATCH] Add AHCI support to qemu driver
>
> ---
> src/qemu/qemu_capabilities.c |3 +++
> src/qemu/qemu_capabilities.h |1 +
> src/qemu/qemu_command.c | 32 +---
> 3 files changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 8e20e3f..7122756 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -139,6 +139,7 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST,
>"no-shutdown",
>
>"cache-unsafe", /* 75 */
> + "ich9-ahci",
> );
>
> struct qemu_feature_flags {
> @@ -1241,6 +1242,8 @@ qemuCapsParseDeviceStr(const char *str, virBitmapPtr
> flags)
> qemuCapsSet(flags, QEMU_CAPS_USB_REDIR);
> if (strstr(str, "name \"usb-hub\""))
> qemuCapsSet(flags, QEMU_CAPS_USB_HUB);
> +if (strstr(str, "name \"ich9-ahci\""))
> +qemuCapsSet(flags, QEMU_CAPS_ICH9_AHCI);
>
> /* Prefer -chardev spicevmc (detected earlier) over -device spicevmc */
> if (!qemuCapsGet(flags, QEMU_CAPS_CHARDEV_SPICEVMC) &&
> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
> index ae3de90..1e23451 100644
> --- a/src/qemu/qemu_capabilities.h
> +++ b/src/qemu/qemu_capabilities.h
> @@ -113,6 +113,7 @@ enum qemuCapsFlags {
> QEMU_CAPS_NO_SHUTDOWN = 74, /* usable -no-shutdown */
>
> QEMU_CAPS_DRIVE_CACHE_UNSAFE = 75, /* Is cache=unsafe supported? */
> +QEMU_CAPS_ICH9_AHCI = 76, /* -device ich9-ahci */
>
> QEMU_CAPS_LAST, /* this must always be the last item */
> };
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 9174a5f..86c3f86 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -1702,6 +1702,12 @@ qemuBuildDriveDevStr(virDomainDiskDefPtr disk,
>disk->info.addr.drive.bus,
>disk->info.addr.drive.unit);
> break;
> +case VIR_DOMAIN_DISK_BUS_SATA:
> +virBufferAddLit(&opt, "ide-drive");
Oh, AHCI still wants the 'ide-drive' devices ? I always figured it would
have a new type of device there too, but perhaps not.
> +virBufferAsprintf(&opt, ",bus=ahci%d.%d",
> + disk->info.addr.drive.controller,
> + disk->info.addr.drive.bus);
> +break;
> case VIR_DOMAIN_DISK_BUS_VIRTIO:
> virBufferAddLit(&opt, "virtio-blk-pci");
> qemuBuildIoEventFdStr(&opt, disk->ioeventfd, qemuCaps);
> @@ -1902,6 +1908,10 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr
> def,
> virBufferAsprintf(&buf, "usb-ccid,id=ccid%d", def->idx);
> break;
>
> +case VIR_DOMAIN_CONTROLLER_TYPE_SATA:
> +virBufferAsprintf(&buf, "ahci,id=ahci%d", def->idx);
> +break;
> +
> case VIR_DOMAIN_CONTROLLER_TYPE_USB:
> if (qemuBuildUSBControllerDevStr(def, qemuCaps, &buf) == -1)
> goto error;
> @@ -3683,14 +3693,22 @@ qemuBuildCommandLine(virConnectPtr conn,
> cont->type == VIR_DOMAIN_CONTROLLER_TYPE_FDC)
> continue;
>
> -/* QEMU doesn't implement a SATA driver */
> +/* Only recent QEMU implements a SATA (AHCI) co
Re: [libvirt] [PATCH] qemu: Check domain status details when reconnecting monitor
On Tue, Sep 27, 2011 at 09:11:57 -0600, Eric Blake wrote: > On 09/27/2011 03:51 AM, Jiri Denemark wrote: > > Current qemu is able to give us detailed domain status (not just if it > > is running or not) which we can translate into a status reason. > > --- > > src/qemu/qemu_monitor.c | 66 > > +++-- > > src/qemu/qemu_monitor.h | 25 +++- > > src/qemu/qemu_monitor_json.c | 15 +- > > src/qemu/qemu_monitor_json.h |4 ++- > > src/qemu/qemu_monitor_text.c | 20 - > > src/qemu/qemu_monitor_text.h |4 ++- > > src/qemu/qemu_process.c | 15 ++ > > 7 files changed, 134 insertions(+), 15 deletions(-) > > Nice. ACK. Pushed, thanks. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2 2/1] docs: document node device XML
On Tue, Sep 27, 2011 at 11:29:04AM -0600, Eric Blake wrote: > Coupled with the recent virsh nodedev-* doc patch, this should now > give a better picture of libvirt node device handling. > > * docs/formatnode.html.in: Fill in page. > --- > > Done mostly by scraping docs/schemas/nodedev.rng, and examples > provided from my laptop with some slight munging (hopefully I'm > not exposing my laptop to attacks by publishing details like that :) > > docs/formatnode.html.in | 219 > +++ > 1 files changed, 219 insertions(+), 0 deletions(-) > > diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in > index 91882ca..2e98245 100644 > --- a/docs/formatnode.html.in > +++ b/docs/formatnode.html.in > @@ -1,5 +1,224 @@ > > > Node devices XML format > + > + > + > +Node Device XML > + > + > + There are several libvirt functions, all with the > + prefix virNodeDevice, which deal with management of > + host devices that can be handed to guests via passthrough as > +elements > + in the domain XML. > + These devices are represented as a hierarchy, where a device on > + a bus has a parent of the bus controller device; the root of the > + hierarchy is the node named "computer". > + > + > + > + When represented in XML, a node device uses the > + top-level device element, with the following > + elements present according to the type of device: > + > + > + name > + The name for this device. The name will be alphanumeric, > +with words separated by underscore. For many devices, the > +name is just the bus type and address, as in > +"pci__00_02_1" or "usb_1_5_3", but some devices are able > +to provide more specific names, such as > +"net_eth1_00_27_13_6a_fe_00". > + > + parent > + If this element is present, it names the parent device (that > +is, a controller to which this node belongs). > + > + capability > + This node appears for each capability that libvirt > +associates with a node. A mandatory > +attribute type lists which category the device > +belongs to, and controls which further subelements will be > +present to describe the node: > + > + system > + Describes the overall host. Sub-elements include: > + > + product > + If present, a simple text string giving the product > +name of the system. > + hardware > + Describes the hardware of the system, including > +sub-elements for vendor, version, > +serial, and uuid. > + firmware > + Describes the firmware of the system, including > +sub-elements for vendor, version, > +and release_date. > + > + > + pci > + Describes a device on the host's PCI bus. Sub-elements > +include: > + > + domain > + Which domain the device belongs to. > + bus > + Which bus within the domain. > + slot > + Which slot within the bus. > + function > + Which function within the slot. > + product > + Product details from the device ROM, including an > +attribute id with the hexadecimal product > +id, and an optional text description of that id. > + vendor > + Vendor details from the device ROM, including an > +attribute id with the hexadecimal vendor > +id, and an optional text name of that vendor. > + > + > + usb_device > + Describes a device on the host's USB bus, based on its > +location within the bus. Sub-elements include: > + > + bus > + Which bus the device belongs to. > + device > + Which device within the bus. > + product > + Product details from the device ROM, including an > +attribute id with the hexadecimal product > +id, and an optional text description of that id. > + vendor > + Vendor details from the device ROM, including an > +attribute id with the hexadecimal vendor > +id, and an optional text name of that vendor. > + > + > + usb > + Describes a USB device, based on its advertised driver > +interface. Sub-elements include: > + > + number > + The device number. > + number > + The device class. > + number > + The device subclass. > + number > +
Re: [libvirt] [PATCH] qemu: qxl devices don't support multifunction yet
On Wed, Sep 28, 2011 at 03:02:59AM -0400, Laine Stump wrote:
> On 09/27/2011 05:13 AM, Daniel P. Berrange wrote:
> >On Tue, Sep 27, 2011 at 01:19:20AM -0400, Laine Stump wrote:
> >>On 09/19/2011 01:32 PM, Daniel P. Berrange wrote:
> >>>On Mon, Sep 19, 2011 at 07:16:22PM +0200, Marc-André Lureau wrote:
> Hi hi
>
> On Fri, Sep 16, 2011 at 1:38 PM, Marc-André Lureau
> wrote:
> >>>How do we allow other devices to share the slot? It seems to me that
> >>>qemuDomainPCIAddressSetNextAddr() only allocate whole slot, while
> >>>making sure there is no conflicts on the same slot.
> >>So, if the user wants to use multi function pci device, he should
> >>specify the
> >>pci address.
> >So adding a check such as:
> >
> >if (!multiFunc&& info->addr.pci.function != 0)
> > return error("The %s device doesn't support multifunction address")
> >
> Wen, does that sound reasonable to you?
>
> Daniel, did you had time to verify that PCI allocation is per-slot?
>
> (It would be nice to get this "workaround" for the next release)
> >>>IMHO this kind of hack doesn't belong in libvirt. It is fine for distro
> >>>vendors to consider as a one off quick-hack for their packages of libvirt,
> >>>if they don't have time to fix the real QXL bug, but not for libvirt
> >>>upstream releases. QXL/QEMU should really be fixed since that's where the
> >>>problem appears to lie.
> >>As it stands, Fedora 16 (currently using unpatched libvirt-0.9.6)
> >>will be going into beta with QXL video broken for Windows guests, so
> >>we need some kind of Fedora-only patch very soon (see the schedule
> >>here: https://fedoraproject.org/wiki/Releases/16/Schedule -
> >>fortunately just delayed another week)
> >>
> >>The original patch in this thread:
> >>
> >> https://www.redhat.com/archives/libvir-list/2011-September/msg00534.html
> >>
> >>of course doesn't include the above mentioned additional code, and
> >>there isn't a followup patch. It would be very good to push a patch
> >>to the F16 git for this so it would hopefully get into the beta, but
> >>want to make sure what I push is the "right" thing, so a "final"
> >>patch (and some testing by people with F16 hosts) would be very
> >>helpful!
> >When we originally enabled multifunction for all PCI devices, we did so
> >in the belief that this was effectively a no-op for guest OSes. ie it
> >should not have changed guest OS behaviour at all, unless multiple devices
> >were actually inserted in the slot.
> >
> >Evidentally this turns out to be incorrect. In other words we introduced
> >a guest ABI change. This is very bad, because our stated goal is to have
> >a stable guest ABI across libvirt& QEMU releases.
> >
> >Thus IMHO we need to disable *all* setting of the 'multifunction=on'
> >parameter for all guests by default, to unbreak the ABI compatibility.
>
> Of course this has been in since 0.9.3, meaning there are official
> releases with broken ABI compatibility :-(. Still, the sooner it's
> fixed the better.
Fortunately it has only affected guests with a QXL device, to the best
of our knowledge.
> >Then we should introduce a new parameter 'multifunction='on' in the
> > element to allow it to be optionally enabled per
> >device.
>
> Will it be acceptable to put that in a patch on top of 0.9.6 for
> Fedora 16? (I think the answer is "yes", since it's only an XML
> change, but just want to make sure).
Yep.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Init the pci device before reattachment
于 2011年09月28日 15:39, Wen Congyang 写道:
At 09/28/2011 03:47 PM, Osier Yang Write:
This patch is just like commit 2ce90ea296, to init the member of
pciDevice before reattachment, otherwise the device won't be unbound
from pci_stub, and won't get the original driver (no probing).
---
src/qemu/qemu_hostdev.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c
index 6f77717..74c817c 100644
--- a/src/qemu/qemu_hostdev.c
+++ b/src/qemu/qemu_hostdev.c
@@ -292,6 +292,7 @@ void qemuDomainReAttachHostdevDevices(struct qemud_driver
*driver,
for (i = 0; i< pciDeviceListCount(pcidevs); i++) {
pciDevice *dev = pciDeviceListGet(pcidevs, i);
+pciDeviceReAttachInit(dev);
qemuReattachPciDevice(dev, driver);
}
The user runs 'virsh attach-device' to pass through host pci device to guest
os. We will call the function qemuPrepareHostdevPCIDevices() to bind the pci
device to pci-stub, and reset it. If the pci device does not support reset
function,
we will call pciReAttachDevice() to rollback the things we have done.
True
If the device is alread bound to pci-stub before the user runs 'virsh
attach-device',
we should do nothing. If the device is not bound to any driver, we should
unbound it from pci-stub. If the device is bound to other driver, we should
unbound it from pci-stub, and reprobe it.
Ok, I guess you mean this patch breaks following 2 scenarios:
1) the device is bound to pci-stub before attach-device
2) the device is not bound to any driver before attach-device
For3), the patch is fine.
With your patch, we can not rollback the things we have done.
What problems do you meet?
The problem is if we attach a device bound to other driver with
"managed=yes", if it fails on attachment, it will never be reattached
to host successfully.
As a simple reproduce method, you can try to attach a PCI device
after turn off VT-d support.
I didn't realize the patch breaks 1) and 2) scenarios. Thanks for
pointing it out.
Then I guess we lost the original dev->ubind_from_stub/dev->remove_slot/
dev->probe (all of some of them) in manged mode. Need to track more.
Osier
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/4] api: Add new public api for 'reset'
Add new public api for 'reset'.
It can reset domain immediately without any guest shutdown.
Signed-off-by: Xu He Jie
---
include/libvirt/libvirt.h.in |2 +
src/driver.h |3 ++
src/libvirt.c| 44 ++
src/libvirt_public.syms |5
4 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 39155a6..3d60023 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -1031,6 +1031,8 @@ virDomainPtrvirDomainLookupByUUIDString
(virConnectPtr conn,
int virDomainShutdown (virDomainPtr domain);
int virDomainReboot (virDomainPtr domain,
unsigned int flags);
+int virDomainReset (virDomainPtr domain);
+
int virDomainDestroy(virDomainPtr domain);
int virDomainDestroyFlags (virDomainPtr domain,
unsigned int flags);
diff --git a/src/driver.h b/src/driver.h
index 3792003..fd0d3a1 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -124,6 +124,8 @@ typedef int
(*virDrvDomainReboot) (virDomainPtr domain,
unsigned int flags);
typedef int
+(*virDrvDomainReset)(virDomainPtr domain);
+typedef int
(*virDrvDomainDestroy) (virDomainPtr domain);
typedef int
(*virDrvDomainDestroyFlags) (virDomainPtr domain,
@@ -755,6 +757,7 @@ struct _virDriver {
virDrvDomainResume domainResume;
virDrvDomainShutdown domainShutdown;
virDrvDomainReboot domainReboot;
+virDrvDomainReset domainReset;
virDrvDomainDestroydomainDestroy;
virDrvDomainDestroyFlagsdomainDestroyFlags;
virDrvDomainGetOSType domainGetOSType;
diff --git a/src/libvirt.c b/src/libvirt.c
index 8f94b11..3c5cd5e 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -3017,6 +3017,50 @@ error:
}
/**
+ * virDomainReset:
+ * @domain: a domain object
+ *
+ * Reset a domain immediately without any guest shutdown
+ *
+ * Returns 0 in case of success and -1 in case of failure.
+ */
+int
+virDomainReset(virDomainPtr domain)
+{
+virConnectPtr conn;
+
+VIR_DOMAIN_DEBUG(domain);
+
+virResetLastError();
+
+if (!VIR_IS_CONNECTED_DOMAIN(domain)) {
+virLibDomainError(VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
+virDispatchError(NULL);
+return -1;
+}
+if (domain->conn->flags & VIR_CONNECT_RO) {
+virLibDomainError(VIR_ERR_OPERATION_DENIED, __FUNCTION__);
+goto error;
+}
+
+conn = domain->conn;
+
+if (conn->driver->domainReset) {
+int ret;
+ret = conn->driver->domainReset (domain);
+if (ret < 0)
+goto error;
+return ret;
+}
+
+virLibConnError(VIR_ERR_NO_SUPPORT, __FUNCTION__);
+
+error:
+virDispatchError(domain->conn);
+return -1;
+}
+
+/**
* virDomainGetName:
* @domain: a domain object
*
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 8a6d55a..dffa33f 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -489,4 +489,9 @@ LIBVIRT_0.9.5 {
virDomainSnapshotGetName;
} LIBVIRT_0.9.4;
+LIBVIRT_0.9.7 {
+global:
+virDomainReset;
+} LIBVIRT_0.9.5;
+
# define new API here using predicted next version number
--
1.7.4.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib] Remove redundant 'Config' in GIR identifiers
On Tue, Sep 27, 2011 at 04:03:13PM +0300, Zeeshan Ali (Khattak) wrote: > From: "Zeeshan Ali (Khattak)" > > libvirt-gconfig is in a separate namespace than libvirt-gobject so there > is not reason to expose 'Config' part of identifiers to high-level > languages. > --- > libvirt-gconfig/Makefile.am |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/libvirt-gconfig/Makefile.am b/libvirt-gconfig/Makefile.am > index fbcb7ba..6f1c628 100644 > --- a/libvirt-gconfig/Makefile.am > +++ b/libvirt-gconfig/Makefile.am > @@ -64,7 +64,7 @@ LibvirtGConfig-1.0.gir: libvirt-gconfig-1.0.la > $(G_IR_SCANNER) Makefile.am > --namespace LibvirtGConfig \ > --nsversion 1.0 \ > --include GObject-2.0 \ > ---identifier-prefix=GVir \ > +--identifier-prefix=GVirConfig \ > --symbol-prefix=gvir \ > --library=$(builddir)/libvirt-gconfig-1.0.la \ > --output $@ \ ACK Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 4/4] virsh: Add 'reset' command for virsh
Signed-off-by: Xu He Jie
---
tools/virsh.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 13be03b..13b10cd 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -3188,6 +3188,44 @@ cmdReboot(vshControl *ctl, const vshCmd *cmd)
}
/*
+ * "reset" command
+ */
+static const vshCmdInfo info_reset[] = {
+{"help", N_("reset a domain")},
+{"desc", N_("Reset the target domain immediately without any guest
shutdown.")},
+{NULL, NULL}
+};
+
+static const vshCmdOptDef opts_reset[] = {
+{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")},
+{NULL, 0, 0, NULL}
+};
+
+static bool
+cmdReset(vshControl *ctl, const vshCmd *cmd)
+{
+virDomainPtr dom;
+bool ret = true;
+const char *name;
+
+if (!vshConnectionUsability(ctl, ctl->conn))
+return false;
+
+if (!(dom = vshCommandOptDomain(ctl, cmd, &name)))
+return false;
+
+if (virDomainReset(dom) == 0) {
+vshPrint(ctl, _("Domain %s is being reseted\n"), name);
+} else {
+vshError(ctl, _("Failed to reset domain %s"), name);
+ret = false;
+}
+
+virDomainFree(dom);
+return ret;
+}
+
+/*
* "destroy" command
*/
static const vshCmdInfo info_destroy[] = {
@@ -13574,6 +13612,7 @@ static const vshCmdDef domManagementCmds[] = {
{"migrate-getspeed", cmdMigrateGetMaxSpeed,
opts_migrate_getspeed, info_migrate_getspeed, 0},
{"reboot", cmdReboot, opts_reboot, info_reboot, 0},
+{"reset", cmdReset, opts_reset, info_reset, 0},
{"restore", cmdRestore, opts_restore, info_restore, 0},
{"resume", cmdResume, opts_resume, info_resume, 0},
{"save", cmdSave, opts_save, info_save, 0},
--
1.7.4.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/4] remote: Implement 'reset' for remote driver
Signed-off-by: Xu He Jie
---
src/remote/remote_driver.c |1 +
src/remote/remote_protocol.x |7 ++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 1217d94..372341c 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -4313,6 +4313,7 @@ static virDriver remote_driver = {
.domainResume = remoteDomainResume, /* 0.3.0 */
.domainShutdown = remoteDomainShutdown, /* 0.3.0 */
.domainReboot = remoteDomainReboot, /* 0.3.0 */
+.domainReset = remoteDomainReset, /* 0.3.0 */
.domainDestroy = remoteDomainDestroy, /* 0.3.0 */
.domainDestroyFlags = remoteDomainDestroyFlags, /* 0.9.4 */
.domainGetOSType = remoteDomainGetOSType, /* 0.3.0 */
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index 455e324..ee84b51 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -688,6 +688,10 @@ struct remote_domain_reboot_args {
unsigned int flags;
};
+struct remote_domain_reset_args {
+remote_nonnull_domain dom;
+};
+
struct remote_domain_destroy_args {
remote_nonnull_domain dom;
};
@@ -2509,7 +2513,8 @@ enum remote_procedure {
REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB = 241, /* skipgen skipgen */
REMOTE_PROC_DOMAIN_MIGRATE_GET_MAX_SPEED = 242, /* autogen autogen */
-REMOTE_PROC_DOMAIN_BLOCK_STATS_FLAGS = 243 /* skipgen skipgen */
+REMOTE_PROC_DOMAIN_BLOCK_STATS_FLAGS = 243, /* skipgen skipgen */
+REMOTE_PROC_DOMAIN_RESET = 244 /* autogen autogen */
/*
* Notice how the entries are grouped in sets of 10 ?
--
1.7.4.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/4] qemu: Implement 'reset' for qemu driver
Signed-off-by: Xu He Jie
---
src/qemu/qemu_driver.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 0d0bea2..dc719ac 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1595,6 +1595,51 @@ cleanup:
}
+static int qemuDomainReset(virDomainPtr dom) {
+struct qemud_driver *driver = dom->conn->privateData;
+virDomainObjPtr vm;
+int ret = -1;
+qemuDomainObjPrivatePtr priv;
+
+qemuDriverLock(driver);
+vm = virDomainFindByUUID(&driver->domains, dom->uuid);
+qemuDriverUnlock(driver);
+
+if (!vm) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+virUUIDFormat(dom->uuid, uuidstr);
+qemuReportError(VIR_ERR_NO_DOMAIN,
+_("no domain with matching uuid '%s'"), uuidstr);
+goto cleanup;
+}
+
+if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0)
+goto cleanup;
+
+if (!virDomainObjIsActive(vm)) {
+qemuReportError(VIR_ERR_OPERATION_INVALID,
+"%s", _("domain is not running"));
+goto endjob;
+}
+
+priv = vm->privateData;
+qemuDomainObjEnterMonitor(driver, vm);
+ret = qemuMonitorSystemReset(priv->mon);
+qemuDomainObjExitMonitor(driver, vm);
+
+priv->fakeReboot = false;
+
+endjob:
+if (qemuDomainObjEndJob(driver, vm) == 0)
+vm = NULL;
+
+cleanup:
+if (vm)
+virDomainObjUnlock(vm);
+return ret;
+}
+
+
/* Count how many snapshots in a set have external disk snapshots. */
static void
qemuDomainSnapshotCountExternal(void *payload,
@@ -10335,6 +10380,7 @@ static virDriver qemuDriver = {
.domainResume = qemudDomainResume, /* 0.2.0 */
.domainShutdown = qemuDomainShutdown, /* 0.2.0 */
.domainReboot = qemuDomainReboot, /* 0.9.3 */
+.domainReset = qemuDomainReset, /* 0.9.7 */
.domainDestroy = qemuDomainDestroy, /* 0.2.0 */
.domainDestroyFlags = qemuDomainDestroyFlags, /* 0.9.4 */
.domainGetOSType = qemudDomainGetOSType, /* 0.2.2 */
--
1.7.4.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Qemu/KVM is 3x slower under libvirt
On 09/28/11 09:51, Daniel P. Berrange wrote:
On Tue, Sep 27, 2011 at 08:10:21PM +0200, Reeted wrote:
I repost this, this time by also including the libvirt mailing list.
Info on my libvirt: it's the version in Ubuntu 11.04 Natty which is
0.8.8-1ubuntu6.5 . I didn't recompile this one, while Kernel and
qemu-kvm are vanilla and compiled by hand as described below.
My original message follows:
This is really strange.
I just installed a new host with kernel 3.0.3 and Qemu-KVM 0.14.1
compiled by me.
I have created the first VM.
This is on LVM, virtio etc... if I run it directly from bash
console, it boots in 8 seconds (it's a bare ubuntu with no
graphics), while if I boot it under virsh (libvirt) it boots in
20-22 seconds. This is the time from after Grub to the login prompt,
or from after Grub to the ssh-server up.
I was almost able to replicate the whole libvirt command line on the
bash console, and it still goes almost 3x faster when launched from
bash than with virsh start vmname. The part I wasn't able to
replicate is the -netdev part because I still haven't understood the
semantics of it.
-netdev is just an alternative way of setting up networking that
avoids QEMU's nasty VLAN concept. Using -netdev allows QEMU to
use more efficient codepaths for networking, which should improve
the network performance.
This is my bash commandline:
/opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm
-m 2002 -smp 2,sockets=2,cores=1,threads=1 -name vmname1-1 -uuid
ee75e28a-3bf3-78d9-3cba-65aa63973380 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/vmname1-1.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc
-boot order=dc,menu=on -drive
file=/dev/mapper/vgPtpVM-lvVM_Vmname1_d1,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none,aio=native
-device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
-drive
if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,cache=none,aio=native
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
-net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no
-usb -vnc 127.0.0.1:0 -vga cirrus -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
This shows KVM is being requested, but we should validate that KVM is
definitely being activated when under libvirt. You can test this by
doing:
virsh qemu-monitor-command vmname1 'info kvm'
kvm support: enabled
I think I would see a higher impact if it was KVM not enabled.
Which was taken from libvirt's command line. The only modifications
I did to the original libvirt commandline (seen with ps aux) were:
- Removed -S
Fine, has no effect on performance.
- Network was: -netdev tap,fd=17,id=hostnet0,vhost=on,vhostfd=18
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3
Has been simplified to: -net nic,model=virtio -net
tap,ifname=tap0,script=no,downscript=no
and manual bridging of the tap0 interface.
You could have equivalently used
-netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0,vhost=on
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3
It's this! It's this!! (thanks for the line)
It raises boot time by 10-13 seconds
But now I don't know where to look During boot there is a pause
usually between /scripts/init-bottom (Ubuntu 11.04 guest) and the
appearance of login prompt, however that is not really meaningful
because there is probably much background activity going on there, with
init etc. which don't display messages
init-bottom does just this
-
#!/bin/sh -e
# initramfs init-bottom script for udev
PREREQ=""
# Output pre-requisites
prereqs()
{
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
# Stop udevd, we'll miss a few events while we run init, but we catch up
pkill udevd
# Move /dev to the real filesystem
mount -n -o move /dev ${rootmnt}/dev
-
It doesn't look like it should take time to execute.
So there is probably some other background activity going on... and that
is slower, but I don't know what that is.
Another thing that can be noticed is that the dmesg message:
[ 13.290173] eth0: no IPv6 routers present
(which is also the last message)
happens on average 1 (one) second earlier in the fast case (-net) than
in the slow case (-netdev)
That said, I don't expect this has anything todo with the performance
since booting a guest rarely involves much network I/O unless you're
doing something odd like NFS-root / iSCSI-root.
No there is nothing like that. No network disks or nfs.
I had ntpdate, but I removed that and it changed nothing.
Firstly I had thought that this could be fault of the VNC: I have
compiled qemu-kvm with no separate vnc thread. I thought that
libvirt might have connected to the vnc server at all times a
Re: [libvirt] Qemu/KVM is 3x slower under libvirt
On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote:
> On 09/28/11 09:51, Daniel P. Berrange wrote:
> >>This is my bash commandline:
> >>
> >>/opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm
> >>-m 2002 -smp 2,sockets=2,cores=1,threads=1 -name vmname1-1 -uuid
> >>ee75e28a-3bf3-78d9-3cba-65aa63973380 -nodefconfig -nodefaults
> >>-chardev
> >>socket,id=charmonitor,path=/var/lib/libvirt/qemu/vmname1-1.monitor,server,nowait
> >>-mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc
> >>-boot order=dc,menu=on -drive
> >>file=/dev/mapper/vgPtpVM-lvVM_Vmname1_d1,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none,aio=native
> >>-device
> >>virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
> >>-drive
> >>if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,cache=none,aio=native
> >>-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
> >>-net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no
> >>-usb -vnc 127.0.0.1:0 -vga cirrus -device
> >>virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
> >
> >This shows KVM is being requested, but we should validate that KVM is
> >definitely being activated when under libvirt. You can test this by
> >doing:
> >
> > virsh qemu-monitor-command vmname1 'info kvm'
>
> kvm support: enabled
>
> I think I would see a higher impact if it was KVM not enabled.
>
> >>Which was taken from libvirt's command line. The only modifications
> >>I did to the original libvirt commandline (seen with ps aux) were:
> >>- Network was: -netdev tap,fd=17,id=hostnet0,vhost=on,vhostfd=18
> >>-device
> >>virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3
> >>Has been simplified to: -net nic,model=virtio -net
> >>tap,ifname=tap0,script=no,downscript=no
> >>and manual bridging of the tap0 interface.
> >You could have equivalently used
> >
> > -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0,vhost=on
> > -device
> > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3
>
> It's this! It's this!! (thanks for the line)
>
> It raises boot time by 10-13 seconds
Ok, that is truely bizarre and I don't really have any explanation
for why that is. I guess you could try 'vhost=off' too and see if that
makes the difference.
>
> But now I don't know where to look During boot there is a pause
> usually between /scripts/init-bottom (Ubuntu 11.04 guest) and the
> appearance of login prompt, however that is not really meaningful
> because there is probably much background activity going on there,
> with init etc. which don't display messages
>
>
> init-bottom does just this
>
> -
> #!/bin/sh -e
> # initramfs init-bottom script for udev
>
> PREREQ=""
>
> # Output pre-requisites
> prereqs()
> {
> echo "$PREREQ"
> }
>
> case "$1" in
> prereqs)
> prereqs
> exit 0
> ;;
> esac
>
>
> # Stop udevd, we'll miss a few events while we run init, but we catch up
> pkill udevd
>
> # Move /dev to the real filesystem
> mount -n -o move /dev ${rootmnt}/dev
> -
>
> It doesn't look like it should take time to execute.
> So there is probably some other background activity going on... and
> that is slower, but I don't know what that is.
>
>
> Another thing that can be noticed is that the dmesg message:
>
> [ 13.290173] eth0: no IPv6 routers present
>
> (which is also the last message)
>
> happens on average 1 (one) second earlier in the fast case (-net)
> than in the slow case (-netdev)
Hmm, none of that looks particularly suspect. So I don't really have
much idea what else to try apart from the 'vhost=off' possibilty.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/4] api: Add new public api for 'reset'
On Wed, Sep 28, 2011 at 05:03:05PM +0800, Xu He Jie wrote:
> Add new public api for 'reset'.
> It can reset domain immediately without any guest shutdown.
>
> Signed-off-by: Xu He Jie
> ---
> include/libvirt/libvirt.h.in |2 +
> src/driver.h |3 ++
> src/libvirt.c| 44
> ++
> src/libvirt_public.syms |5
> 4 files changed, 54 insertions(+), 0 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index 39155a6..3d60023 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -1031,6 +1031,8 @@ virDomainPtrvirDomainLookupByUUIDString
> (virConnectPtr conn,
> int virDomainShutdown (virDomainPtr domain);
> int virDomainReboot (virDomainPtr domain,
> unsigned int flags);
> +int virDomainReset (virDomainPtr domain);
> +
I would add flags even if unused yet
> int virDomainDestroy(virDomainPtr domain);
> int virDomainDestroyFlags (virDomainPtr domain,
> unsigned int flags);
> diff --git a/src/driver.h b/src/driver.h
> index 3792003..fd0d3a1 100644
> --- a/src/driver.h
> +++ b/src/driver.h
> @@ -124,6 +124,8 @@ typedef int
> (*virDrvDomainReboot)(virDomainPtr domain,
> unsigned int flags);
> typedef int
> +(*virDrvDomainReset)(virDomainPtr domain);
> +typedef int
> (*virDrvDomainDestroy) (virDomainPtr domain);
> typedef int
> (*virDrvDomainDestroyFlags) (virDomainPtr domain,
> @@ -755,6 +757,7 @@ struct _virDriver {
> virDrvDomainResume domainResume;
> virDrvDomainShutdown domainShutdown;
> virDrvDomainReboot domainReboot;
> +virDrvDomainReset domainReset;
> virDrvDomainDestroy domainDestroy;
> virDrvDomainDestroyFlagsdomainDestroyFlags;
> virDrvDomainGetOSTypedomainGetOSType;
> diff --git a/src/libvirt.c b/src/libvirt.c
> index 8f94b11..3c5cd5e 100644
> --- a/src/libvirt.c
> +++ b/src/libvirt.c
> @@ -3017,6 +3017,50 @@ error:
> }
>
> /**
> + * virDomainReset:
> + * @domain: a domain object
> + *
> + * Reset a domain immediately without any guest shutdown
Hum, so the goal of the reset operation is that it resets the
domain. That's a bit light in terms of semantic. What does that
mean actually ?
Does that emulate the power reset of a button on a machine, i.e.
all hardware see the RST line set and reinitialize their internal state
?
If yes the obvious danger of this operation about loss of data should be
made very clear.
> + * Returns 0 in case of success and -1 in case of failure.
> + */
> +int
> +virDomainReset(virDomainPtr domain)
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] Qemu/KVM is 3x slower under libvirt
On 09/28/11 11:28, Daniel P. Berrange wrote: On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote: On 09/28/11 09:51, Daniel P. Berrange wrote: This is my bash commandline: /opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm -m 2002 -smp 2,sockets=2,cores=1,threads=1 -name vmname1-1 -uuid ee75e28a-3bf3-78d9-3cba-65aa63973380 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/vmname1-1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -boot order=dc,menu=on -drive file=/dev/mapper/vgPtpVM-lvVM_Vmname1_d1,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,cache=none,aio=native -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no -usb -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 This shows KVM is being requested, but we should validate that KVM is definitely being activated when under libvirt. You can test this by doing: virsh qemu-monitor-command vmname1 'info kvm' kvm support: enabled I think I would see a higher impact if it was KVM not enabled. Which was taken from libvirt's command line. The only modifications I did to the original libvirt commandline (seen with ps aux) were: - Network was: -netdev tap,fd=17,id=hostnet0,vhost=on,vhostfd=18 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3 Has been simplified to: -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no and manual bridging of the tap0 interface. You could have equivalently used -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3 It's this! It's this!! (thanks for the line) It raises boot time by 10-13 seconds Ok, that is truely bizarre and I don't really have any explanation for why that is. I guess you could try 'vhost=off' too and see if that makes the difference. YES! It's the vhost. With vhost=on it takes about 12 seconds more time to boot. ...meaning? :-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote: > On 09/28/11 11:28, Daniel P. Berrange wrote: > >On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote: > >>On 09/28/11 09:51, Daniel P. Berrange wrote: > This is my bash commandline: > > /opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm > -m 2002 -smp 2,sockets=2,cores=1,threads=1 -name vmname1-1 -uuid > ee75e28a-3bf3-78d9-3cba-65aa63973380 -nodefconfig -nodefaults > -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/vmname1-1.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc > -boot order=dc,menu=on -drive > file=/dev/mapper/vgPtpVM-lvVM_Vmname1_d1,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none,aio=native > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 > -drive > if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,cache=none,aio=native > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 > -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no > -usb -vnc 127.0.0.1:0 -vga cirrus -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 > >>>This shows KVM is being requested, but we should validate that KVM is > >>>definitely being activated when under libvirt. You can test this by > >>>doing: > >>> > >>> virsh qemu-monitor-command vmname1 'info kvm' > >>kvm support: enabled > >> > >>I think I would see a higher impact if it was KVM not enabled. > >> > Which was taken from libvirt's command line. The only modifications > I did to the original libvirt commandline (seen with ps aux) were: > > > - Network was: -netdev tap,fd=17,id=hostnet0,vhost=on,vhostfd=18 > -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3 > Has been simplified to: -net nic,model=virtio -net > tap,ifname=tap0,script=no,downscript=no > and manual bridging of the tap0 interface. > >>>You could have equivalently used > >>> > >>> -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0,vhost=on > >>> -device > >>> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:36:60,bus=pci.0,addr=0x3 > >>It's this! It's this!! (thanks for the line) > >> > >>It raises boot time by 10-13 seconds > >Ok, that is truely bizarre and I don't really have any explanation > >for why that is. I guess you could try 'vhost=off' too and see if that > >makes the difference. > > YES! > It's the vhost. With vhost=on it takes about 12 seconds more time to boot. > > ...meaning? :-) I've no idea. I was always under the impression that 'vhost=on' was the 'make it go much faster' switch. So something is going wrong here that I cna't explain. Perhaps one of the network people on this list can explain... To turn vhost off in the libvirt XML, you should be able to use for the interface in question,eg Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/1] [RFC] Parallels Server Bare Metal driver stub
Eric,
Thank you for your comments!
I'll check related to HyperV adoption commits and will try to fix necessary
things in the next patch series.
Links to product pages:
http://www.parallels.com/products/server/baremetal/sp/resources/
http://www.parallels.com/download/server/
> Is this driver more like qemu,
> where it requires talking to a daemon like libvirtd (and where remote
> access is provided by libvirt), or more like esx, where it is
> translating things at the client level while talking to an esx protocol
> (and where remote access is provided by the hypervisor)?
We have a userspace daemon on PSBM node which is responsible for incoming
requests management (like libvirtd) and client library (libprl_sdk.so) for
remote/local access to it. Communication protocol is XML-based over TCP.
> Is it really Linux-only, or if those
> programs someday exist on other platforms, have you artificially
> restricted this driver?
Virtualization SDK is available for 3 platforms (Linux, Windows and Mac OS X)
already. I decided to restrict it initially in order to achieve something
usable on the single platform first, than extend it to others. Patches for
extension will be small - just remove this restriction and add load of the
shared library on appropriate paths. Just want to avoid additional testing on
the adoption stage.
--
Thanks,
Dmitry.
On Tuesday, September 27, 2011 09:39:14 PM Eric Blake wrote:
> On 09/26/2011 05:59 AM, Dmitry Mishin wrote:
> > Parallels Server Bare Metal is a virtualization solution which allows to
> > run both Containers (OpenVZ-like) and virtual machines (like any other
> > hardware hypervisor).
>
> Any web page link so we can familiarize ourselves with the project?
>
> > This patch implements initial driver stub with almost no functionality
> > except an ability to open and close driver. At the same time it contains
> > initialization of Parallels API and clearly demonstrates supposed
> > approach to future driver implementation. In particular, I suppose to
> > use parallels-virtualization-sdk library provisioned with the PSBM
> > distribution (and separately also) for PSBM's virtual servers
> > management.
> >
> > Signed-off-by: Dmitry Mishin
> > ---
> >
> > autobuild.sh|1 +
> > configure.ac| 21 +
> > include/libvirt/virterror.h |1 +
> > src/Makefile.am | 22 +
> > src/README |1 +
> > src/driver.h|1 +
> > src/libvirt.c |9 ++
> > src/psbm/psbm_api.c | 117
> > src/psbm/psbm_api.h | 59
> > src/psbm/psbm_driver.c | 208
> > +++ src/psbm/psbm_driver.h
> >| 32 +++
> > src/psbm/psbm_private.h | 49 ++
> > src/util/virterror.c|3 +
>
> Missing a hypervisor stub page under docs/ (that would be a good place
> to include the link I mentioned above). Is this driver more like qemu,
> where it requires talking to a daemon like libvirtd (and where remote
> access is provided by libvirt), or more like esx, where it is
> translating things at the client level while talking to an esx protocol
> (and where remote access is provided by the hypervisor)?
>
> Missing changes to libvirt.spec.in and mingw32-libvirt.spec.in for
> making compilation of the new driver conditional when building for
> Fedora and friends.
>
> I'd feel a bit more comfortable reviewing this patch if you also had a
> followon patch that can do some basic APIs, such as start and stop
> guests, or even just list the names of running guests. Of course, those
> should be separate patches, but it is better to push a patch series that
> makes the hypervisor driver useful, rather than just pushing this patch
> in isolation where the hypervisor driver can't do anything at all. Look
> at the recent HyperV hypervisor driver addition (around commit 5e3b0f8)
> for an example of what all is needed to make this driver addition
> successful.
>
> > +
> > +if test "$with_psbm" = "yes"&& test "$with_linux" = "no"; then
> > +AC_MSG_ERROR([The PSBM driver can be enabled on Linux only.])
>
> Are there any libraries that have to be linked in? Is this all calls to
> third-party program(s) (in which case, should configure probe for the
> absolute path of that program)? Is it really Linux-only, or if those
> programs someday exist on other platforms, have you artificially
> restricted this driver?
>
> > +int psbmApiInit(struct psbm_driver *driver)
> > +{
> > +const char *libname = "libprl_sdk.so";
>
> Looks like you are using library calls, so configure needs to probe for
> the existence of this library.
>
> > +
> > +static virDriver psbmDriver = {
> > +.no = VIR_DRV_PSBM,
> > +.name = "PSBM",
> > +.open = psbmOpen, /* 0.3.1 */
> > +.close = psbmClose, /* 0.3.1 */
> > +.type = psbmGetType, /* 0.3.1 */
> > +.vers
[libvirt] [PATCH] qemu: Preserve fakeReboot flag in domain status
Thus, when libvirtd is restarted, it will know if a domain is supposed
to be killed or reset when it shuts down.
---
src/qemu/qemu_domain.c | 21 +
src/qemu/qemu_domain.h |4
src/qemu/qemu_driver.c | 11 +--
src/qemu/qemu_process.c |4 ++--
4 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 4023648..320a35c 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -302,6 +302,9 @@ static int qemuDomainObjPrivateXMLFormat(virBufferPtr buf,
void *data)
virBufferAddLit(buf, "/>\n");
}
+if (priv->fakeReboot)
+virBufferAsprintf(buf, " \n");
+
return 0;
}
@@ -445,6 +448,8 @@ static int qemuDomainObjPrivateXMLParse(xmlXPathContextPtr
ctxt, void *data)
}
}
+priv->fakeReboot = virXPathBoolean("boolean(./fakereboot)", ctxt) == 1;
+
return 0;
error:
@@ -1566,3 +1571,19 @@ qemuDomainRemoveInactive(struct qemud_driver *driver,
}
virDomainRemoveInactive(&driver->domains, vm);
}
+
+void
+qemuDomainSetFakeReboot(struct qemud_driver *driver,
+virDomainObjPtr vm,
+bool value)
+{
+qemuDomainObjPrivatePtr priv = vm->privateData;
+
+if (priv->fakeReboot == value)
+return;
+
+priv->fakeReboot = value;
+
+if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0)
+VIR_WARN("Failed to save status on vm %s", vm->def->name);
+}
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index 00cfa3a..3b09419 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -273,4 +273,8 @@ int qemuDomainSnapshotDiscardAllMetadata(struct
qemud_driver *driver,
void qemuDomainRemoveInactive(struct qemud_driver *driver,
virDomainObjPtr vm);
+void qemuDomainSetFakeReboot(struct qemud_driver *driver,
+ virDomainObjPtr vm,
+ bool value);
+
#endif /* __QEMU_DOMAIN_H__ */
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 0d0bea2..8cbb850 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1512,13 +1512,13 @@ static int qemuDomainShutdown(virDomainPtr dom) {
goto endjob;
}
+qemuDomainSetFakeReboot(driver, vm, false);
+
priv = vm->privateData;
qemuDomainObjEnterMonitor(driver, vm);
ret = qemuMonitorSystemPowerdown(priv->mon);
qemuDomainObjExitMonitor(driver, vm);
-priv->fakeReboot = false;
-
endjob:
if (qemuDomainObjEndJob(driver, vm) == 0)
vm = NULL;
@@ -1575,7 +1575,8 @@ static int qemuDomainReboot(virDomainPtr dom, unsigned
int flags) {
ret = qemuMonitorSystemPowerdown(priv->mon);
qemuDomainObjExitMonitor(driver, vm);
-priv->fakeReboot = true;
+if (ret == 0)
+qemuDomainSetFakeReboot(driver, vm, true);
endjob:
if (qemuDomainObjEndJob(driver, vm) == 0)
@@ -1616,7 +1617,6 @@ qemuDomainDestroyFlags(virDomainPtr dom,
virDomainObjPtr vm;
int ret = -1;
virDomainEventPtr event = NULL;
-qemuDomainObjPrivatePtr priv;
virCheckFlags(0, -1);
@@ -1630,8 +1630,7 @@ qemuDomainDestroyFlags(virDomainPtr dom,
goto cleanup;
}
-priv = vm->privateData;
-priv->fakeReboot = false;
+qemuDomainSetFakeReboot(driver, vm, false);
/* Although qemuProcessStop does this already, there may
* be an outstanding job active. We want to make sure we
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 106a47c..4c6b4a4 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -442,7 +442,7 @@ qemuProcessShutdownOrReboot(virDomainObjPtr vm)
priv->gotShutdown = true;
if (priv->fakeReboot) {
-priv->fakeReboot = false;
+qemuDomainSetFakeReboot(qemu_driver, vm, false);
virDomainObjRef(vm);
virThread th;
if (virThreadCreate(&th,
@@ -2846,7 +2846,7 @@ int qemuProcessStart(virConnectPtr conn,
goto cleanup;
vm->def->id = driver->nextvmid++;
-priv->fakeReboot = false;
+qemuDomainSetFakeReboot(driver, vm, false);
virDomainObjSetState(vm, VIR_DOMAIN_SHUTOFF, VIR_DOMAIN_SHUTOFF_UNKNOWN);
/* Run an early hook to set-up missing devices */
--
1.7.6.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libguestfs integration: rich disk access for libvirt applications
On Tue, Sep 27, 2011 at 12:55 PM, Richard W.M. Jones wrote: > To put this all into one place: > > (1) An ugly new libvirt API that runs febootstrap-supermin-helper to > create the appliance. [...] > I'm worried about item (1) in this list ... This is the only instance where libvirt knows about libguestfs. All other steps are libguest only or involve libguestfs knowing about libvirt. Would it be possible introduce a "domain-builder" concept into libvirt? When libguestfs is installed it drops a domain-builder configuration/script that libvirt can pick up. Then you can say something like virDomainBuild(name="guestfs-appliance", builder="guestfs"). Does febootstrap-supermin-helper need to be dynamic or could libguestfs create a /var/lib/guestfs/appliance-initramfs.gz on install? Then libguestfs on the client can create the appliance domain and point at that static initramfs file path. Stefan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
On 09/28/11 11:53, Daniel P. Berrange wrote: On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote: YES! It's the vhost. With vhost=on it takes about 12 seconds more time to boot. ...meaning? :-) I've no idea. I was always under the impression that 'vhost=on' was the 'make it go much faster' switch. So something is going wrong here that I cna't explain. Perhaps one of the network people on this list can explain... To turn vhost off in the libvirt XML, you should be able to use for the interface in question,eg Ok that seems to work: it removes the vhost part in the virsh launch hence cutting down 12secs of boot time. If nobody comes out with an explanation of why, I will open another thread on the kvm list for this. I would probably need to test disk performance on vhost=on to see if it degrades or it's for another reason that boot time is increased. Thanks so much for your help Daniel, Reeted -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote: > On 09/28/11 11:53, Daniel P. Berrange wrote: > >On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote: > >>YES! > >>It's the vhost. With vhost=on it takes about 12 seconds more time to boot. > >> > >>...meaning? :-) > >I've no idea. I was always under the impression that 'vhost=on' was > >the 'make it go much faster' switch. So something is going wrong > >here that I cna't explain. > > > >Perhaps one of the network people on this list can explain... > > > > > >To turn vhost off in the libvirt XML, you should be able to use > > for the interface in question,eg > > > > > > > > > > > > > > > > > Ok that seems to work: it removes the vhost part in the virsh launch > hence cutting down 12secs of boot time. > > If nobody comes out with an explanation of why, I will open another > thread on the kvm list for this. I would probably need to test disk > performance on vhost=on to see if it degrades or it's for another > reason that boot time is increased. Be sure to CC the qemu-devel mailing list too next time, since that has a wider audience who might be able to help Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libguestfs integration: rich disk access for libvirt applications
On Wed, Sep 28, 2011 at 11:14:57AM +0100, Stefan Hajnoczi wrote: > Does febootstrap-supermin-helper need to be dynamic or could > libguestfs create a /var/lib/guestfs/appliance-initramfs.gz on > install? Then libguestfs on the client can create the appliance > domain and point at that static initramfs file path. This is how the Debian package of libguestfs works (Hilko's official package, not my one). However this is troublesome because it means any security problem in a dependent program is baked into the appliance. Applying a security update to the host wouldn't update this libguestfs appliance. Compare this to the way febootstrap-supermin-helper normally works (eg upstream, Fedora and RHEL): the appliance is rebuilt whenever any change is noticed in a dependent program. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote: > On 09/28/11 11:53, Daniel P. Berrange wrote: > >On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote: > >>YES! > >>It's the vhost. With vhost=on it takes about 12 seconds more time to boot. > >> > >>...meaning? :-) > >I've no idea. I was always under the impression that 'vhost=on' was > >the 'make it go much faster' switch. So something is going wrong > >here that I cna't explain. > > > >Perhaps one of the network people on this list can explain... > > > > > >To turn vhost off in the libvirt XML, you should be able to use > > for the interface in question,eg > > > > > > > > > > > > > > > > > Ok that seems to work: it removes the vhost part in the virsh launch > hence cutting down 12secs of boot time. > > If nobody comes out with an explanation of why, I will open another > thread on the kvm list for this. I would probably need to test disk > performance on vhost=on to see if it degrades or it's for another > reason that boot time is increased. Is it using CPU during this time, or is the qemu-kvm process idle? It wouldn't be the first time that a network option ROM sat around waiting for an imaginary console user to press a key. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Preserve fakeReboot flag in domain status
On Wed, Sep 28, 2011 at 12:13:35PM +0200, Jiri Denemark wrote:
> Thus, when libvirtd is restarted, it will know if a domain is supposed
> to be killed or reset when it shuts down.
> ---
> src/qemu/qemu_domain.c | 21 +
> src/qemu/qemu_domain.h |4
> src/qemu/qemu_driver.c | 11 +--
> src/qemu/qemu_process.c |4 ++--
> 4 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 4023648..320a35c 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -302,6 +302,9 @@ static int qemuDomainObjPrivateXMLFormat(virBufferPtr
> buf, void *data)
> virBufferAddLit(buf, "/>\n");
> }
>
> +if (priv->fakeReboot)
> +virBufferAsprintf(buf, " \n");
> +
> return 0;
> }
>
> @@ -445,6 +448,8 @@ static int
> qemuDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt, void *data)
> }
> }
>
> +priv->fakeReboot = virXPathBoolean("boolean(./fakereboot)", ctxt) == 1;
> +
> return 0;
>
> error:
> @@ -1566,3 +1571,19 @@ qemuDomainRemoveInactive(struct qemud_driver *driver,
> }
> virDomainRemoveInactive(&driver->domains, vm);
> }
> +
> +void
> +qemuDomainSetFakeReboot(struct qemud_driver *driver,
> +virDomainObjPtr vm,
> +bool value)
> +{
> +qemuDomainObjPrivatePtr priv = vm->privateData;
> +
> +if (priv->fakeReboot == value)
> +return;
> +
> +priv->fakeReboot = value;
> +
> +if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0)
> +VIR_WARN("Failed to save status on vm %s", vm->def->name);
> +}
> diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
> index 00cfa3a..3b09419 100644
> --- a/src/qemu/qemu_domain.h
> +++ b/src/qemu/qemu_domain.h
> @@ -273,4 +273,8 @@ int qemuDomainSnapshotDiscardAllMetadata(struct
> qemud_driver *driver,
> void qemuDomainRemoveInactive(struct qemud_driver *driver,
>virDomainObjPtr vm);
>
> +void qemuDomainSetFakeReboot(struct qemud_driver *driver,
> + virDomainObjPtr vm,
> + bool value);
> +
> #endif /* __QEMU_DOMAIN_H__ */
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 0d0bea2..8cbb850 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -1512,13 +1512,13 @@ static int qemuDomainShutdown(virDomainPtr dom) {
> goto endjob;
> }
>
> +qemuDomainSetFakeReboot(driver, vm, false);
> +
> priv = vm->privateData;
> qemuDomainObjEnterMonitor(driver, vm);
> ret = qemuMonitorSystemPowerdown(priv->mon);
> qemuDomainObjExitMonitor(driver, vm);
>
> -priv->fakeReboot = false;
> -
> endjob:
> if (qemuDomainObjEndJob(driver, vm) == 0)
> vm = NULL;
> @@ -1575,7 +1575,8 @@ static int qemuDomainReboot(virDomainPtr dom, unsigned
> int flags) {
> ret = qemuMonitorSystemPowerdown(priv->mon);
> qemuDomainObjExitMonitor(driver, vm);
>
> -priv->fakeReboot = true;
> +if (ret == 0)
> +qemuDomainSetFakeReboot(driver, vm, true);
>
> endjob:
> if (qemuDomainObjEndJob(driver, vm) == 0)
> @@ -1616,7 +1617,6 @@ qemuDomainDestroyFlags(virDomainPtr dom,
> virDomainObjPtr vm;
> int ret = -1;
> virDomainEventPtr event = NULL;
> -qemuDomainObjPrivatePtr priv;
>
> virCheckFlags(0, -1);
>
> @@ -1630,8 +1630,7 @@ qemuDomainDestroyFlags(virDomainPtr dom,
> goto cleanup;
> }
>
> -priv = vm->privateData;
> -priv->fakeReboot = false;
> +qemuDomainSetFakeReboot(driver, vm, false);
>
> /* Although qemuProcessStop does this already, there may
> * be an outstanding job active. We want to make sure we
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 106a47c..4c6b4a4 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -442,7 +442,7 @@ qemuProcessShutdownOrReboot(virDomainObjPtr vm)
>
> priv->gotShutdown = true;
> if (priv->fakeReboot) {
> -priv->fakeReboot = false;
> +qemuDomainSetFakeReboot(qemu_driver, vm, false);
> virDomainObjRef(vm);
> virThread th;
> if (virThreadCreate(&th,
> @@ -2846,7 +2846,7 @@ int qemuProcessStart(virConnectPtr conn,
> goto cleanup;
>
> vm->def->id = driver->nextvmid++;
> -priv->fakeReboot = false;
> +qemuDomainSetFakeReboot(driver, vm, false);
> virDomainObjSetState(vm, VIR_DOMAIN_SHUTOFF, VIR_DOMAIN_SHUTOFF_UNKNOWN);
>
> /* Run an early hook to set-up missing devices */
ACK, that sounds right, and look so too :-)
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
Re: [libvirt] [PATCH 1/5] snapshot: new virDomainSnapshotGetParent API
On Sat, Sep 24, 2011 at 06:30:02PM -0600, Eric Blake wrote:
> Although a client can already obtain a snapshot's parent by
> dumping and parsing the xml, then doing a snapshot lookup by
> name, it is more efficient to get the parent in one step, which
> in turn will make operations that must traverse a snapshot
> hierarchy easier to perform.
>
> * include/libvirt/libvirt.h.in (virDomainSnapshotGetParent):
> Declare.
> * src/libvirt.c (virDomainSnapshotGetParent): New function.
> * src/libvirt_public.syms: Export it.
> * src/driver.h (virDrvDomainSnapshotGetParent): New callback.
> ---
> include/libvirt/libvirt.h.in |4 +++
> src/driver.h |5
> src/libvirt.c| 44
> ++
> src/libvirt_public.syms |5
> 4 files changed, 58 insertions(+), 0 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index 39155a6..afeb83f 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -2711,6 +2711,10 @@ int virDomainHasCurrentSnapshot(virDomainPtr domain,
> unsigned int flags);
> virDomainSnapshotPtr virDomainSnapshotCurrent(virDomainPtr domain,
>unsigned int flags);
>
> +/* Get a handle to the parent snapshot, if one exists */
> +virDomainSnapshotPtr virDomainSnapshotGetParent(virDomainSnapshotPtr
> snapshot,
> +unsigned int flags);
> +
> typedef enum {
> VIR_DOMAIN_SNAPSHOT_REVERT_RUNNING = 1 << 0, /* Run after revert */
> VIR_DOMAIN_SNAPSHOT_REVERT_PAUSED = 1 << 1, /* Pause after revert */
> diff --git a/src/driver.h b/src/driver.h
> index 3792003..7dcab8f 100644
> --- a/src/driver.h
> +++ b/src/driver.h
> @@ -590,6 +590,10 @@ typedef int
> (*virDrvDomainHasCurrentSnapshot)(virDomainPtr domain, unsigned int
> flags);
>
> typedef virDomainSnapshotPtr
> +(*virDrvDomainSnapshotGetParent)(virDomainSnapshotPtr snapshot,
> + unsigned int flags);
> +
> +typedef virDomainSnapshotPtr
> (*virDrvDomainSnapshotCurrent)(virDomainPtr domain,
> unsigned int flags);
>
> @@ -854,6 +858,7 @@ struct _virDriver {
> virDrvDomainSnapshotListNames domainSnapshotListNames;
> virDrvDomainSnapshotLookupByName domainSnapshotLookupByName;
> virDrvDomainHasCurrentSnapshot domainHasCurrentSnapshot;
> +virDrvDomainSnapshotGetParent domainSnapshotGetParent;
> virDrvDomainSnapshotCurrent domainSnapshotCurrent;
> virDrvDomainRevertToSnapshot domainRevertToSnapshot;
> virDrvDomainSnapshotDelete domainSnapshotDelete;
> diff --git a/src/libvirt.c b/src/libvirt.c
> index 8f94b11..38fcfbc 100644
> --- a/src/libvirt.c
> +++ b/src/libvirt.c
> @@ -16150,6 +16150,50 @@ error:
> }
>
> /**
> + * virDomainSnapshotGetParent:
> + * @snapshot: a snapshot object
> + * @flags: unused flag parameters; callers should pass 0
> + *
> + * Get the parent snapshot for @snapshot, if any.
> + *
> + * Returns a domain snapshot object or NULL in case of failure. If the
> + * given snapshot is a root (no parent), then the VIR_ERR_NO_DOMAIN_SNAPSHOT
> + * error is raised.
> + */
> +virDomainSnapshotPtr
> +virDomainSnapshotGetParent(virDomainSnapshotPtr snapshot,
> + unsigned int flags)
> +{
> +virConnectPtr conn;
> +
> +VIR_DEBUG("snapshot=%p, flags=%x", snapshot, flags);
> +
> +virResetLastError();
> +
> +if (!VIR_IS_DOMAIN_SNAPSHOT(snapshot)) {
> +virLibDomainSnapshotError(VIR_ERR_INVALID_DOMAIN_SNAPSHOT,
> + __FUNCTION__);
> +virDispatchError(NULL);
> +return NULL;
> +}
> +
> +conn = snapshot->domain->conn;
> +
> +if (conn->driver->domainSnapshotGetParent) {
> +virDomainSnapshotPtr snap;
> +snap = conn->driver->domainSnapshotGetParent(snapshot, flags);
> +if (!snap)
> +goto error;
> +return snap;
> +}
> +
> +virLibConnError(VIR_ERR_NO_SUPPORT, __FUNCTION__);
> +error:
> +virDispatchError(conn);
> +return NULL;
> +}
> +
> +/**
> * virDomainRevertToSnapshot:
> * @snapshot: a domain snapshot object
> * @flags: bitwise-OR of virDomainSnapshotRevertFlags
> diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
> index 8a6d55a..cef14f0 100644
> --- a/src/libvirt_public.syms
> +++ b/src/libvirt_public.syms
> @@ -489,4 +489,9 @@ LIBVIRT_0.9.5 {
> virDomainSnapshotGetName;
> } LIBVIRT_0.9.4;
>
> +LIBVIRT_0.9.7 {
> +global:
> +virDomainSnapshotGetParent;
> +} LIBVIRT_0.9.5;
> +
> # define new API here using predicted next version number
> --
> 1.7.4.4
ACK, interface and intent looks fine !
I have seen another patch today touching the libvirt_public.syms
though, tweaking may be needed by someone :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit htt
Re: [libvirt] [PATCH 2/5] snapshot: remote protocol for getparent
On Sat, Sep 24, 2011 at 06:30:03PM -0600, Eric Blake wrote:
> Mostly straight-forward, although this is the first API that
> returns a new snapshot based on a snapshot rather than a domain.
>
> * src/remote/remote_protocol.x
> (REMOTE_PROC_DOMAIN_SNAPSHOT_GET_PARENT): New rpc.
> (remote_domain_snapshot_get_parent_args)
> (remote_domain_snapshot_get_parent_ret): New structs.
> * src/rpc/gendispatch.pl: Adjust generator.
> * src/remote/remote_driver.c (remote_driver): Use it.
> * src/remote_protocol-structs: Update.
> ---
> src/remote/remote_driver.c |1 +
> src/remote/remote_protocol.x | 12 +++-
> src/remote_protocol-structs |8
> src/rpc/gendispatch.pl |4 +++-
> 4 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
> index 1217d94..740dd75 100644
> --- a/src/remote/remote_driver.c
> +++ b/src/remote/remote_driver.c
> @@ -4412,6 +4412,7 @@ static virDriver remote_driver = {
> .domainSnapshotListNames = remoteDomainSnapshotListNames, /* 0.8.0 */
> .domainSnapshotLookupByName = remoteDomainSnapshotLookupByName, /* 0.8.0
> */
> .domainHasCurrentSnapshot = remoteDomainHasCurrentSnapshot, /* 0.8.0 */
> +.domainSnapshotGetParent = remoteDomainSnapshotGetParent, /* 0.9.7 */
> .domainSnapshotCurrent = remoteDomainSnapshotCurrent, /* 0.8.0 */
> .domainRevertToSnapshot = remoteDomainRevertToSnapshot, /* 0.8.0 */
> .domainSnapshotDelete = remoteDomainSnapshotDelete, /* 0.8.0 */
> diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
> index 455e324..3504e34 100644
> --- a/src/remote/remote_protocol.x
> +++ b/src/remote/remote_protocol.x
> @@ -2081,6 +2081,15 @@ struct remote_domain_has_current_snapshot_ret {
> int result;
> };
>
> +struct remote_domain_snapshot_get_parent_args {
> +remote_nonnull_domain_snapshot snap;
> +unsigned int flags;
> +};
> +
> +struct remote_domain_snapshot_get_parent_ret {
> +remote_nonnull_domain_snapshot snap;
> +};
> +
> struct remote_domain_snapshot_current_args {
> remote_nonnull_domain dom;
> unsigned int flags;
> @@ -2509,7 +2518,8 @@ enum remote_procedure {
>
> REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB = 241, /* skipgen skipgen */
> REMOTE_PROC_DOMAIN_MIGRATE_GET_MAX_SPEED = 242, /* autogen autogen */
> -REMOTE_PROC_DOMAIN_BLOCK_STATS_FLAGS = 243 /* skipgen skipgen */
> +REMOTE_PROC_DOMAIN_BLOCK_STATS_FLAGS = 243, /* skipgen skipgen */
> +REMOTE_PROC_DOMAIN_SNAPSHOT_GET_PARENT = 244 /* autogen autogen */
>
> /*
> * Notice how the entries are grouped in sets of 10 ?
> diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs
> index 810b19c..53705bf 100644
> --- a/src/remote_protocol-structs
> +++ b/src/remote_protocol-structs
> @@ -1568,6 +1568,13 @@ struct remote_domain_has_current_snapshot_args {
> struct remote_domain_has_current_snapshot_ret {
> intresult;
> };
> +struct remote_domain_snapshot_get_parent_args {
> +remote_nonnull_domain_snapshot snap;
> +u_int flags;
> +};
> +struct remote_domain_snapshot_get_parent_ret {
> +remote_nonnull_domain_snapshot snap;
> +};
> struct remote_domain_snapshot_current_args {
> remote_nonnull_domain dom;
> u_int flags;
> @@ -1958,4 +1965,5 @@ enum remote_procedure {
> REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB = 241,
> REMOTE_PROC_DOMAIN_MIGRATE_GET_MAX_SPEED = 242,
> REMOTE_PROC_DOMAIN_BLOCK_STATS_FLAGS = 243,
> +REMOTE_PROC_DOMAIN_SNAPSHOT_GET_PARENT = 244,
> };
> diff --git a/src/rpc/gendispatch.pl b/src/rpc/gendispatch.pl
> index fcd1a26..039d785 100755
> --- a/src/rpc/gendispatch.pl
> +++ b/src/rpc/gendispatch.pl
> @@ -1273,7 +1273,9 @@ elsif ($opt_k) {
> $single_ret_type = "int";
> } else {
> if ($name eq "domain_snapshot") {
> -push(@ret_list, "rv = get_nonnull_$name(dom,
> ret.$arg_name);");
> +my $dom = "$priv_src";
> +$dom =~ s/->conn//;
> +push(@ret_list, "rv = get_nonnull_$name($dom,
> ret.$arg_name);");
> } else {
> push(@ret_list, "rv =
> get_nonnull_$name($priv_src, ret.$arg_name);");
> }
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 4/5] snapshot: add virsh snapshot-list --tree
On Sat, Sep 24, 2011 at 06:30:05PM -0600, Eric Blake wrote:
> Reuse the tree listing of nodedev-list, coupled with the new helper
> function to efficiently grab snapshot parent names, to produce
> tree output for a snapshot hierarchy. For example:
>
> $ virsh snapshot-list dom --tree
> root1
> |
> +- sibling1
> +- sibling2
> | |
> | +- grandchild
> |
> +- sibling3
>
> root2
> |
> +- child
>
> * tools/virsh.c (cmdSnapshotList): Add --tree.
> * tools/virsh.pod (snapshot-list): Document it.
> ---
> tools/virsh.c | 83 +-
> tools/virsh.pod | 14 +
> 2 files changed, 77 insertions(+), 20 deletions(-)
>
> diff --git a/tools/virsh.c b/tools/virsh.c
> index 035b209..7e7b65d 100644
> --- a/tools/virsh.c
> +++ b/tools/virsh.c
> @@ -12987,7 +12987,7 @@ vshGetSnapshotParent(vshControl *ctl,
> virDomainSnapshotPtr snapshot)
> parent = virDomainSnapshotGetParent(snapshot, 0);
> if (parent) {
> /* API works, and virDomainSnapshotGetName will succeed */
> -parent_name = vshStrdup(ctl, virDomainSnapshotGetName(snapshot));
> +parent_name = vshStrdup(ctl, virDomainSnapshotGetName(parent));
> goto cleanup;
> }
> if (last_error->code == VIR_ERR_NO_DOMAIN_SNAPSHOT) {
That looks like a bug fix squashed in here instead of previous patch,
what am I missing ?
> @@ -13032,6 +13032,7 @@ static const vshCmdOptDef opts_snapshot_list[] = {
> {"roots", VSH_OT_BOOL, 0, N_("list only snapshots without parents")},
> {"metadata", VSH_OT_BOOL, 0,
> N_("list only snapshots that have metadata that would prevent
> undefine")},
> +{"tree", VSH_OT_BOOL, 0, N_("list snapshots in a tree")},
> {NULL, 0, 0, NULL}
> };
>
> @@ -13057,6 +13058,7 @@ cmdSnapshotList(vshControl *ctl, const vshCmd *cmd)
> time_t creation_time_t;
> char timestr[100];
> struct tm time_info;
> +bool tree = vshCommandOptBool(cmd, "tree");
>
> if (vshCommandOptBool(cmd, "parent")) {
> if (vshCommandOptBool(cmd, "roots")) {
> @@ -13064,8 +13066,18 @@ cmdSnapshotList(vshControl *ctl, const vshCmd *cmd)
> _("--parent and --roots are mutually exlusive"));
> return false;
> }
> +if (tree) {
> +vshError(ctl, "%s",
> + _("--parent and --tree are mutually exlusive"));
> +return false;
> +}
> parent_filter = 1;
> } else if (vshCommandOptBool(cmd, "roots")) {
> +if (tree) {
> +vshError(ctl, "%s",
> + _("--roots and --tree are mutually exlusive"));
> +return false;
> +}
> flags |= VIR_DOMAIN_SNAPSHOT_LIST_ROOTS;
> }
>
> @@ -13095,23 +13107,66 @@ cmdSnapshotList(vshControl *ctl, const vshCmd *cmd)
> if (numsnaps < 0)
> goto cleanup;
>
> -if (parent_filter > 0)
> -vshPrintExtra(ctl, " %-20s %-25s %-15s %s",
> - _("Name"), _("Creation Time"), _("State"),
> _("Parent"));
> -else
> -vshPrintExtra(ctl, " %-20s %-25s %s",
> - _("Name"), _("Creation Time"), _("State"));
> -vshPrintExtra(ctl, "\n\
> +if (!tree) {
> +if (parent_filter > 0)
> +vshPrintExtra(ctl, " %-20s %-25s %-15s %s",
> + _("Name"), _("Creation Time"), _("State"),
> + _("Parent"));
> +else
> +vshPrintExtra(ctl, " %-20s %-25s %s",
> + _("Name"), _("Creation Time"), _("State"));
> +vshPrintExtra(ctl, "\n\
> \n");
> +}
>
> -if (numsnaps) {
> -if (VIR_ALLOC_N(names, numsnaps) < 0)
> -goto cleanup;
> +if (!numsnaps) {
> +ret = true;
> +goto cleanup;
> +}
>
> -actual = virDomainSnapshotListNames(dom, names, numsnaps, flags);
> -if (actual < 0)
> -goto cleanup;
> +if (VIR_ALLOC_N(names, numsnaps) < 0)
> +goto cleanup;
> +
> +actual = virDomainSnapshotListNames(dom, names, numsnaps, flags);
> +if (actual < 0)
> +goto cleanup;
>
> +if (tree) {
> +char indentBuf[INDENT_BUFLEN];
> +char **parents = vshMalloc(ctl, sizeof(char *) * actual);
> +for (i = 0; i < actual; i++) {
> +/* free up memory from previous iterations of the loop */
> +if (snapshot)
> +virDomainSnapshotFree(snapshot);
> +snapshot = virDomainSnapshotLookupByName(dom, names[i], 0);
> +if (!snapshot) {
> +while (--i >= 0)
> +VIR_FREE(parents[i]);
> +VIR_FREE(parents);
> +goto cleanup;
> +}
> +parents[i] = vshGetSnapshotParent(ctl, snapshot);
> +}
> +for (i = 0 ; i < actual ; i+
Re: [libvirt] [PATCH 5/5] snapshot: implement getparent in qemu
On Sat, Sep 24, 2011 at 06:30:06PM -0600, Eric Blake wrote:
> First hypervisor implementation of the new API.
> Allows 'virsh snapshot-list --tree' to be more efficient.
>
> * src/qemu/qemu_driver.c (qemuDomainSnapshotGetParent): New
> function.
> ---
> src/qemu/qemu_driver.c | 46 ++
> 1 files changed, 46 insertions(+), 0 deletions(-)
>
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 08310b4..47dde3f 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -9451,6 +9451,51 @@ cleanup:
> return ret;
> }
>
> +static virDomainSnapshotPtr
> +qemuDomainSnapshotGetParent(virDomainSnapshotPtr snapshot,
> +unsigned int flags)
> +{
> +struct qemud_driver *driver = snapshot->domain->conn->privateData;
> +virDomainObjPtr vm;
> +virDomainSnapshotObjPtr snap = NULL;
> +virDomainSnapshotPtr parent = NULL;
> +
> +virCheckFlags(0, NULL);
> +
> +qemuDriverLock(driver);
> +vm = virDomainFindByUUID(&driver->domains, snapshot->domain->uuid);
> +if (!vm) {
> +char uuidstr[VIR_UUID_STRING_BUFLEN];
> +virUUIDFormat(snapshot->domain->uuid, uuidstr);
> +qemuReportError(VIR_ERR_NO_DOMAIN,
> +_("no domain with matching uuid '%s'"), uuidstr);
> +goto cleanup;
> +}
> +
> +snap = virDomainSnapshotFindByName(&vm->snapshots, snapshot->name);
> +if (!snap) {
> +qemuReportError(VIR_ERR_NO_DOMAIN_SNAPSHOT,
> +_("no domain snapshot with matching name '%s'"),
> +snapshot->name);
> +goto cleanup;
> +}
> +
> +if (!snap->def->parent) {
> +qemuReportError(VIR_ERR_NO_DOMAIN_SNAPSHOT,
> +_("snapshot '%s' does not have a parent"),
> +snap->def->name);
> +goto cleanup;
> +}
> +
> +parent = virGetDomainSnapshot(snapshot->domain, snap->def->parent);
> +
> +cleanup:
> +if (vm)
> +virDomainObjUnlock(vm);
> +qemuDriverUnlock(driver);
> +return parent;
> +}
> +
> static virDomainSnapshotPtr qemuDomainSnapshotCurrent(virDomainPtr domain,
>unsigned int flags)
> {
> @@ -10432,6 +10477,7 @@ static virDriver qemuDriver = {
> .domainSnapshotListNames = qemuDomainSnapshotListNames, /* 0.8.0 */
> .domainSnapshotLookupByName = qemuDomainSnapshotLookupByName, /* 0.8.0 */
> .domainHasCurrentSnapshot = qemuDomainHasCurrentSnapshot, /* 0.8.0 */
> +.domainSnapshotGetParent = qemuDomainSnapshotGetParent, /* 0.9.7 */
> .domainSnapshotCurrent = qemuDomainSnapshotCurrent, /* 0.8.0 */
> .domainRevertToSnapshot = qemuDomainRevertToSnapshot, /* 0.8.0 */
> .domainSnapshotDelete = qemuDomainSnapshotDelete, /* 0.8.0 */
ACK, any change to get this implemented for other drivers ?
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 3/5] snapshot: refactor virsh snapshot parent computation
On Sat, Sep 24, 2011 at 06:30:04PM -0600, Eric Blake wrote:
> Make parent computation reusable, using virDomainSnapshotGetParent
> when possible.
>
> * tools/virsh.c (vshGetSnapshotParent): New helper.
> (cmdSnapshotParent): Use it.
> ---
> tools/virsh.c | 66
> -
> 1 files changed, 51 insertions(+), 15 deletions(-)
>
> diff --git a/tools/virsh.c b/tools/virsh.c
> index 7b0533d..035b209 100644
> --- a/tools/virsh.c
> +++ b/tools/virsh.c
> @@ -246,6 +246,8 @@ typedef struct __vshControl {
> char *historyfile; /* readline history file name */
> bool useGetInfo;/* must use virDomainGetInfo, since
> virDomainGetState is not supported */
> +bool useSnapshotGetXML; /* must use virDomainSnapshotGetXMLDesc,
> since
> + virDomainSnapshotGetParent is missing */
> } __vshControl;
>
> typedef struct vshCmdGrp {
> @@ -613,6 +615,7 @@ vshReconnect(vshControl *ctl)
> vshError(ctl, "%s", _("Reconnected to the hypervisor"));
> disconnected = 0;
> ctl->useGetInfo = false;
> +ctl->useSnapshotGetXML = false;
> }
>
> /* ---
> @@ -760,6 +763,7 @@ cmdConnect(vshControl *ctl, const vshCmd *cmd)
> ctl->name = vshStrdup(ctl, name);
>
> ctl->useGetInfo = false;
> +ctl->useSnapshotGetXML = false;
> ctl->readonly = ro;
>
> ctl->conn = virConnectOpenAuth(ctl->name, virConnectAuthPtrDefault,
> @@ -12967,6 +12971,52 @@ cleanup:
> return ret;
> }
>
> +/* Helper function to get the name of a snapshot's parent. Caller
> + * must free the result. */
> +static char *
> +vshGetSnapshotParent(vshControl *ctl, virDomainSnapshotPtr snapshot)
> +{
> +virDomainSnapshotPtr parent = NULL;
> +char *xml = NULL;
> +xmlDocPtr xmldoc = NULL;
> +xmlXPathContextPtr ctxt = NULL;
> +char *parent_name = NULL;
> +
> +/* Try new API, since it is faster. */
> +if (!ctl->useSnapshotGetXML) {
> +parent = virDomainSnapshotGetParent(snapshot, 0);
> +if (parent) {
> +/* API works, and virDomainSnapshotGetName will succeed */
> +parent_name = vshStrdup(ctl, virDomainSnapshotGetName(snapshot));
> +goto cleanup;
> +}
> +if (last_error->code == VIR_ERR_NO_DOMAIN_SNAPSHOT) {
> +/* API works, and we found a root with no parent */
> +goto cleanup;
> +}
> +/* API didn't work, fall back to XML scraping. */
> +ctl->useSnapshotGetXML = true;
> +}
> +
> +xml = virDomainSnapshotGetXMLDesc(snapshot, 0);
> +if (!xml)
> +goto cleanup;
> +
> +xmldoc = virXMLParseStringCtxt(xml, _("(domain_snapshot)"), &ctxt);
> +if (!xmldoc)
> +goto cleanup;
> +
> +parent_name = virXPathString("string(/domainsnapshot/parent/name)",
> ctxt);
> +
> +cleanup:
> +if (parent)
> +virDomainSnapshotFree(parent);
> +xmlXPathFreeContext(ctxt);
> +xmlFreeDoc(xmldoc);
> +VIR_FREE(xml);
> +return parent_name;
> +}
> +
> /*
> * "snapshot-list" command
> */
> @@ -13220,10 +13270,7 @@ cmdSnapshotParent(vshControl *ctl, const vshCmd *cmd)
> bool ret = false;
> const char *name = NULL;
> virDomainSnapshotPtr snapshot = NULL;
> -char *xml = NULL;
> char *parent = NULL;
> -xmlDocPtr xmldoc = NULL;
> -xmlXPathContextPtr ctxt = NULL;
>
> if (!vshConnectionUsability(ctl, ctl->conn))
> goto cleanup;
> @@ -13239,15 +13286,7 @@ cmdSnapshotParent(vshControl *ctl, const vshCmd *cmd)
> if (snapshot == NULL)
> goto cleanup;
>
> -xml = virDomainSnapshotGetXMLDesc(snapshot, 0);
> -if (!xml)
> -goto cleanup;
> -
> -xmldoc = virXMLParseStringCtxt(xml, _("(domain_snapshot)"), &ctxt);
> -if (!xmldoc)
> -goto cleanup;
> -
> -parent = virXPathString("string(/domainsnapshot/parent/name)", ctxt);
> +parent = vshGetSnapshotParent(ctl, snapshot);
> if (!parent)
> goto cleanup;
>
> @@ -13257,9 +13296,6 @@ cmdSnapshotParent(vshControl *ctl, const vshCmd *cmd)
>
> cleanup:
> VIR_FREE(parent);
> -xmlXPathFreeContext(ctxt);
> -xmlFreeDoc(xmldoc);
> -VIR_FREE(xml);
> if (snapshot)
> virDomainSnapshotFree(snapshot);
> if (dom)
Okay, that works even if one reopen a different connection in shell mode
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] qemu: Preserve fakeReboot flag in domain status
On Wed, Sep 28, 2011 at 21:06:29 +0800, Daniel Veillard wrote: > On Wed, Sep 28, 2011 at 12:13:35PM +0200, Jiri Denemark wrote: > > Thus, when libvirtd is restarted, it will know if a domain is supposed > > to be killed or reset when it shuts down. > > --- > > src/qemu/qemu_domain.c | 21 + > > src/qemu/qemu_domain.h |4 > > src/qemu/qemu_driver.c | 11 +-- > > src/qemu/qemu_process.c |4 ++-- > > 4 files changed, 32 insertions(+), 8 deletions(-) > > ACK, that sounds right, and look so too :-) Thanks, pushed. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/1] [RFC] Parallels Server Bare Metal driver stub
On Mon, Sep 26, 2011 at 03:59:05PM +0400, Dmitry Mishin wrote:
> Parallels Server Bare Metal is a virtualization solution which allows to run
> both Containers (OpenVZ-like) and virtual machines (like any other hardware
> hypervisor).
>
> This patch implements initial driver stub with almost no functionality except
> an
> ability to open and close driver. At the same time it contains initialization
> of
> Parallels API and clearly demonstrates supposed approach to future driver
> implementation. In particular, I suppose to use parallels-virtualization-sdk
> library provisioned with the PSBM distribution (and separately also) for
> PSBM's
> virtual servers management.
>
> Signed-off-by: Dmitry Mishin
[...]
> diff --git a/src/psbm/psbm_api.c b/src/psbm/psbm_api.c
> new file mode 100644
> index 000..b5a89f1
> --- /dev/null
> +++ b/src/psbm/psbm_api.c
> @@ -0,0 +1,117 @@
> +/*
> + * psbm_api.c: core driver methods for managing PSBM virtual servers
> + *
> + * Copyright (C) 2011 Parallels, Inc.
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + * Authors:
> + * Dmitry Mishin
> + *
> + */
Copyrights and licencing terms looks okay :)
> +int psbmApiInit(struct psbm_driver *driver)
> +{
> +const char *libname = "libprl_sdk.so";
> +void *handle = NULL;
> +PRL_RESULT res;
That I dislike, sorry this must not be dlopen'ed in at runtime,
but checked in at configure time and properly linked in. Also
means that proper dependancies and packaging have to be in place.
> +handle = dlopen(libname, RTLD_LAZY);
> +if (!handle) {
> +psbmError(VIR_ERR_INTERNAL_ERROR,
> + _("Failed to load SDK library %s %s"), libname, dlerror());
> +return VIR_ERR_INTERNAL_ERROR;
> +}
So what is that SDK library, how is it distributed and what is the
licencing for it ? As much as I like adding a driver, I would like to
make sure the deployement is clean and there is no licencing issues.
Any pointers ? All I found was
http://www.parallels.com/ptn/download/sdk/
and it's quite silent on code availability and Licence for the
libraries.
thanks in advance !
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 1/1] [RFC] Parallels Server Bare Metal driver stub
On Wed, Sep 28, 2011 at 09:34:47PM +0800, Daniel Veillard wrote: > On Mon, Sep 26, 2011 at 03:59:05PM +0400, Dmitry Mishin wrote: > > Parallels Server Bare Metal is a virtualization solution which allows to run > > both Containers (OpenVZ-like) and virtual machines (like any other hardware > > hypervisor). > > > > This patch implements initial driver stub with almost no functionality > > except an > > ability to open and close driver. At the same time it contains > > initialization of > > Parallels API and clearly demonstrates supposed approach to future driver > > implementation. In particular, I suppose to use parallels-virtualization-sdk > > library provisioned with the PSBM distribution (and separately also) for > > PSBM's > > virtual servers management. After looking a bit and since I didn't find any packaging of your SDK in Fedora, I guess you're a bit as in the same situation as VMWare support, the best would be to implement the RPC ans allow to talk directly to the server as Matthias did for ESX. This will also drop the dependancy on that package and allow remote access directly. HTTP and XML libraries are already linked to libvirt that sounds the right way to proceed, 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 1/1] [RFC] Parallels Server Bare Metal driver stub
On Wednesday, September 28, 2011 05:34:47 PM Daniel Veillard wrote:
[...]
> > +int psbmApiInit(struct psbm_driver *driver)
> > +{
> > +const char *libname = "libprl_sdk.so";
> > +void *handle = NULL;
> > +PRL_RESULT res;
>
> That I dislike, sorry this must not be dlopen'ed in at runtime,
> but checked in at configure time and properly linked in. Also
> means that proper dependancies and packaging have to be in place.
I exactly want to avoid dependencies.
Library can be used both remotely (for example, on Fedora host) and locally
(on PSBM host). And if in the local case we can create special libvirt rpm
with enabled PSBM support and integrate it to distribution, in remote case we
force user to download not only Parallels SDK rpm (which will hardly be
included to Fedora due to proprietary license), but also fixed libvirt package
instead of already installed one. Is it preferable way from your point of
view?
>
> > +handle = dlopen(libname, RTLD_LAZY);
> > +if (!handle) {
> > +psbmError(VIR_ERR_INTERNAL_ERROR,
> > + _("Failed to load SDK library %s %s"), libname,
> > dlerror()); +return VIR_ERR_INTERNAL_ERROR;
> > +}
>
> So what is that SDK library, how is it distributed and what is the
> licencing for it ? As much as I like adding a driver, I would like to
> make sure the deployement is clean and there is no licencing issues.
>
> Any pointers ? All I found was
> http://www.parallels.com/ptn/download/sdk/
> and it's quite silent on code availability and Licence for the
> libraries.
It has a proprietary license and not open sourced now. Is it a problem?
>
> thanks in advance !
>
> Daniel
--
Thanks,
Dmitry.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/1] [RFC] Parallels Server Bare Metal driver stub
On Wed, Sep 28, 2011 at 06:01:24PM +0400, Dmitry Mishin wrote:
>
> On Wednesday, September 28, 2011 05:34:47 PM Daniel Veillard wrote:
> [...]
> > > +int psbmApiInit(struct psbm_driver *driver)
> > > +{
> > > +const char *libname = "libprl_sdk.so";
> > > +void *handle = NULL;
> > > +PRL_RESULT res;
> >
> > That I dislike, sorry this must not be dlopen'ed in at runtime,
> > but checked in at configure time and properly linked in. Also
> > means that proper dependancies and packaging have to be in place.
> I exactly want to avoid dependencies.
>
> Library can be used both remotely (for example, on Fedora host) and locally
> (on PSBM host). And if in the local case we can create special libvirt rpm
> with enabled PSBM support and integrate it to distribution, in remote case we
> force user to download not only Parallels SDK rpm (which will hardly be
> included to Fedora due to proprietary license), but also fixed libvirt
> package
> instead of already installed one. Is it preferable way from your point of
> view?
That sounds fairly evil, I guess I would make a fuss if you started
shipping libvirt rpms with non libvirt code in it. I think you need to
go the XML-RPC way since that how access to the server seems to work,
see my second mail, Matthias did this for VMWare support...
> >
> > > +handle = dlopen(libname, RTLD_LAZY);
> > > +if (!handle) {
> > > +psbmError(VIR_ERR_INTERNAL_ERROR,
> > > + _("Failed to load SDK library %s %s"), libname,
> > > dlerror()); +return VIR_ERR_INTERNAL_ERROR;
> > > +}
> >
> > So what is that SDK library, how is it distributed and what is the
> > licencing for it ? As much as I like adding a driver, I would like to
> > make sure the deployement is clean and there is no licencing issues.
> >
> > Any pointers ? All I found was
> > http://www.parallels.com/ptn/download/sdk/
> > and it's quite silent on code availability and Licence for the
> > libraries.
> It has a proprietary license and not open sourced now. Is it a problem?
Yes our code is LGPL or GPL, we can't link with your SDK if it's
not released under a compatible licence. See my second mail,
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 1/1] [RFC] Parallels Server Bare Metal driver stub
On Wed, Sep 28, 2011 at 06:01:24PM +0400, Dmitry Mishin wrote:
>
> On Wednesday, September 28, 2011 05:34:47 PM Daniel Veillard wrote:
> [...]
> > > +int psbmApiInit(struct psbm_driver *driver)
> > > +{
> > > +const char *libname = "libprl_sdk.so";
> > > +void *handle = NULL;
> > > +PRL_RESULT res;
> >
> > That I dislike, sorry this must not be dlopen'ed in at runtime,
> > but checked in at configure time and properly linked in. Also
> > means that proper dependancies and packaging have to be in place.
> I exactly want to avoid dependencies.
>
> Library can be used both remotely (for example, on Fedora host) and locally
> (on PSBM host). And if in the local case we can create special libvirt rpm
> with enabled PSBM support and integrate it to distribution, in remote case we
> force user to download not only Parallels SDK rpm (which will hardly be
> included to Fedora due to proprietary license), but also fixed libvirt
> package
> instead of already installed one. Is it preferable way from your point of
> view?
>
> >
> > > +handle = dlopen(libname, RTLD_LAZY);
> > > +if (!handle) {
> > > +psbmError(VIR_ERR_INTERNAL_ERROR,
> > > + _("Failed to load SDK library %s %s"), libname,
> > > dlerror()); +return VIR_ERR_INTERNAL_ERROR;
> > > +}
> >
> > So what is that SDK library, how is it distributed and what is the
> > licencing for it ? As much as I like adding a driver, I would like to
> > make sure the deployement is clean and there is no licencing issues.
> >
> > Any pointers ? All I found was
> > http://www.parallels.com/ptn/download/sdk/
> > and it's quite silent on code availability and Licence for the
> > libraries.
> It has a proprietary license and not open sourced now. Is it a problem?
If the license is not LGPLv2+ compatible, then it can't be used
by libvirt, regardless of whether it is directly linked, or
dlopened. In other words using 'dlopen' doesn't magically solve
the license compatibility problem.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Improve LXC startup error messages
From: "Daniel P. Berrange"
The LXC controller and container attempt to run in lockstep
using a series of handshakes. There was a flaw in the container
side though, causing it todo partial setup work, before waiting
for the initial controller handshake.
This in turn meant some of the controller setup could fail,
and obscure the real error from the container setup. Moving
the lxcContainerWaitForContinue call to be the first thing
the container does solves that.
The controller still, however, pollutes the log with a message
about the container handshake failing, when the container
shuts down during startup.
To deal with this requires special handling of the EOF condition
on the controllers lxcContainerWaitForContinue() call.
* src/lxc/lxc_container.c: Wait for continue message from
controller before doing anything at all
* src/lxc/lxc_controller.c: Don't pollute log with error
message if EOF was returned from lxcContainerWaitForContinue.
* src/lxc/lxc_driver.c: Handle EOF from controller handshake
---
src/lxc/lxc_container.c | 38 ++
src/lxc/lxc_controller.c | 31 ---
src/lxc/lxc_driver.c |2 +-
3 files changed, 55 insertions(+), 16 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 787df9a..ee5ca9f 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -214,7 +214,7 @@ error_out:
* parent process. It will send this message on the socket pair stored in
* the vm structure once it has completed the post clone container setup.
*
- * Returns 0 on success or -1 in case of error
+ * Returns 1 on success, 0 on EOF, or -1 in case of error
*/
int lxcContainerWaitForContinue(int control)
{
@@ -222,12 +222,18 @@ int lxcContainerWaitForContinue(int control)
int readLen;
readLen = saferead(control, &msg, sizeof(msg));
-if (readLen != sizeof(msg) ||
-msg != LXC_CONTINUE_MSG) {
+if (readLen < 0)
+return -1;
+
+if (readLen != sizeof(msg))
+return 0;
+
+if (msg != LXC_CONTINUE_MSG) {
+errno = EINVAL;
return -1;
}
-return 0;
+return 1;
}
@@ -1036,6 +1042,20 @@ static int lxcContainerChild( void *data )
char *ttyPath = NULL;
virDomainFSDefPtr root;
virCommandPtr cmd = NULL;
+int rc;
+
+/* Wait for interface devices to show up */
+if ((rc = lxcContainerWaitForContinue(argv->monitor)) <= 0) {
+if (rc < 0)
+virReportSystemError(errno, "%s",
+ _("Failed to read the container continue
message"));
+else
+lxcError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("Controller unexpectedly quit"));
+goto cleanup;
+}
+
+VIR_DEBUG("Received container continue message");
if (NULL == vmDef) {
lxcError(VIR_ERR_INTERNAL_ERROR,
@@ -1079,14 +1099,6 @@ static int lxcContainerChild( void *data )
goto cleanup;
}
-/* Wait for interface devices to show up */
-if (lxcContainerWaitForContinue(argv->monitor) < 0) {
-virReportSystemError(errno, "%s",
- _("Failed to read the container continue
message"));
-goto cleanup;
-}
-VIR_DEBUG("Received container continue message");
-
/* rename and enable interfaces */
if (lxcContainerRenameAndEnableInterfaces(argv->nveths,
argv->veths) < 0) {
@@ -1120,6 +1132,8 @@ cleanup:
}
virCommandFree(cmd);
+if (ret < 0)
+virDispatchError(NULL);
return ret;
}
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 52d382e..8c3a54f 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -780,6 +780,9 @@ static int lxcSetPersonality(virDomainDefPtr def)
# define MS_SLAVE (1<<19)
#endif
+/*
+ * Returns -1 on error, 0 if container quit unexpected, 1 on success
+ */
static int
lxcControllerRun(virDomainDefPtr def,
unsigned int nveths,
@@ -801,6 +804,7 @@ lxcControllerRun(virDomainDefPtr def,
size_t nloopDevs = 0;
int *loopDevs = NULL;
size_t i;
+int ret;
if (socketpair(PF_UNIX, SOCK_STREAM, 0, control) < 0) {
virReportSystemError(errno, "%s",
@@ -935,12 +939,25 @@ lxcControllerRun(virDomainDefPtr def,
goto cleanup;
}
-if (lxcContainerWaitForContinue(containerhandshake[0]) < 0) {
+if ((ret = lxcContainerWaitForContinue(containerhandshake[0])) < 0) {
virReportSystemError(errno, "%s",
_("error receiving signal from container"));
goto cleanup;
}
+if (ret == 0) {
+rc = 0;
+/* We're not raising an error, since the container will have
+ * done that already and we don't want to confuse the driver
+ * when it fetches the error message from logs
+ */
+#if 0
+lxcError(VIR_ERR_INTERNAL
Re: [libvirt] [PATCH 1/1] [RFC] Parallels Server Bare Metal driver stub
OK, I got it.
Will think how to resolve this.
On Wednesday, September 28, 2011 06:10:19 PM Daniel P. Berrange wrote:
> On Wed, Sep 28, 2011 at 06:01:24PM +0400, Dmitry Mishin wrote:
> > On Wednesday, September 28, 2011 05:34:47 PM Daniel Veillard wrote:
> > [...]
> >
> > > > +int psbmApiInit(struct psbm_driver *driver)
> > > > +{
> > > > +const char *libname = "libprl_sdk.so";
> > > > +void *handle = NULL;
> > > > +PRL_RESULT res;
> > > >
> > > That I dislike, sorry this must not be dlopen'ed in at runtime,
> > >
> > > but checked in at configure time and properly linked in. Also
> > > means that proper dependancies and packaging have to be in place.
> >
> > I exactly want to avoid dependencies.
> >
> > Library can be used both remotely (for example, on Fedora host) and
> > locally (on PSBM host). And if in the local case we can create special
> > libvirt rpm with enabled PSBM support and integrate it to distribution,
> > in remote case we force user to download not only Parallels SDK rpm
> > (which will hardly be included to Fedora due to proprietary license),
> > but also fixed libvirt package instead of already installed one. Is it
> > preferable way from your point of view?
> >
> > > > +handle = dlopen(libname, RTLD_LAZY);
> > > > +if (!handle) {
> > > > +psbmError(VIR_ERR_INTERNAL_ERROR,
> > > > + _("Failed to load SDK library %s %s"), libname,
> > > > dlerror()); +return VIR_ERR_INTERNAL_ERROR;
> > > > +}
> > > >
> > > So what is that SDK library, how is it distributed and what is the
> > >
> > > licencing for it ? As much as I like adding a driver, I would like to
> > > make sure the deployement is clean and there is no licencing issues.
> > >
> > > Any pointers ? All I found was
> > > http://www.parallels.com/ptn/download/sdk/
> > >
> > > and it's quite silent on code availability and Licence for the
> > > libraries.
> >
> > It has a proprietary license and not open sourced now. Is it a problem?
>
> If the license is not LGPLv2+ compatible, then it can't be used
> by libvirt, regardless of whether it is directly linked, or
> dlopened. In other words using 'dlopen' doesn't magically solve
> the license compatibility problem.
>
> Daniel
--
Thanks,
Dmitry.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC] Adding new filesystem 'proxy' to 9p
Pass-through security model in QEMU 9p server needs root privilege to do few file operations (like chown, chmod to any mode/uid:gid). There are two issues in pass-through security model 1) TOCTTOU vulnerability: Following symbolic links in the server could provide access to files beyond 9p export path. 2) When libvirt is configured to run qemu as non-root user (for example, if qemu is configured to run as normal user 'qemu'), running file operations on pass-through security model would fail because it needs root privileges. To overcome above issues, following approach is suggested: A new filesytem type 'proxy' is introduced. Proxy FS uses chroot + socket combination for securing the vulnerability known with following symbolic links. Intention of adding a new filesystem type is to allow qemu to run in non-root mode, but doing privileged operations using socket IO. A new binary (known as proxy helper) will be provided as part of qemu. Proxy helper will chroot into 9p export path and create a socket pair or a named socket based on the command line parameter. Qemu and proxy helper will communicate using this socket. We need following changes in the libvirt code to accomodate new 'proxy' filesystem type: If qemu 9p server is configured to use 'proxy' FS, libvirt will do * Create a socket pair * invoke proxy_helper binary with one of the socket id from the pair as command line parameters to it with root privilege * invoke qemu with one of socket id from the pair as paramter to qemu virtfs after dropping to the configured user privilege. ie, libvirt will invoke proxy_helper as: proxy_helper -i -p <9p-path-to-export> and qemu will be invoked with following virtfs parameter: -virtfs proxy,id=,sock_fd= ,path=/tmp/,security_model=prox,mount_tag=v_pass People who want to use proxy_helper without libvirt can use following interface: $ proxy_helper -s -p <9p-path-to-export> With following qemu fsdev parameter: -virtfs proxy,id=,socket=,path=/tmp/, security_model=prox,mount_tag=v_pass -- Regards, M. Mohan Kumar -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] Improve timestamps in log messages
Jiri Denemark (2): logging: Do not log timestamp through syslog logging: Add date to log timestamp src/util/logging.c | 123 +++ src/util/logging.h |9 ++-- 2 files changed, 80 insertions(+), 52 deletions(-) -- 1.7.6.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] logging: Do not log timestamp through syslog
Syslog puts the timestamp to every message anyway so this removes
redundant data.
---
src/util/logging.c | 121 +++
src/util/logging.h |9 ++--
2 files changed, 78 insertions(+), 52 deletions(-)
diff --git a/src/util/logging.c b/src/util/logging.c
index a638510..4ffaf75 100644
--- a/src/util/logging.c
+++ b/src/util/logging.c
@@ -98,7 +98,8 @@ static int virLogResetFilters(void);
static int virLogResetOutputs(void);
static int virLogOutputToFd(const char *category, int priority,
const char *funcname, long long linenr,
-const char *str, int len, void *data);
+const char *timestamp, const char *str,
+void *data);
/*
* Logs accesses must be serialized though a mutex
@@ -282,16 +283,16 @@ void virLogShutdown(void) {
/*
* Store a string in the ring buffer
*/
-static void virLogStr(const char *str, int len) {
+static void virLogStr(const char *str)
+{
int tmp;
+int len;
if ((str == NULL) || (virLogBuffer == NULL) || (virLogSize <= 0))
return;
-if (len <= 0)
-len = strlen(str);
+len = strlen(str);
if (len >= virLogSize)
return;
-virLogLock();
/*
* copy the data and reset the end, we cycle over the end of the buffer
@@ -317,7 +318,6 @@ static void virLogStr(const char *str, int len) {
if (virLogStart >= virLogSize)
virLogStart -= virLogSize;
}
-virLogUnlock();
}
static void virLogDumpAllFD(const char *msg, int len) {
@@ -618,12 +618,28 @@ cleanup:
return ret;
}
+static char *
+virLogFormatTimestamp(void)
+{
+struct timeval cur_time;
+struct tm time_info;
+char *str = NULL;
+
+gettimeofday(&cur_time, NULL);
+localtime_r(&cur_time.tv_sec, &time_info);
+
+if (virAsprintf(&str, "%02d:%02d:%02d.%03d",
+time_info.tm_hour, time_info.tm_min, time_info.tm_sec,
+(int) (cur_time.tv_usec / 1000)) < 0)
+return NULL;
+
+return str;
+}
+
static int
virLogFormatString(char **msg,
const char *funcname,
long long linenr,
- struct tm *time_info,
- struct timeval *cur_time,
int priority,
const char *str)
{
@@ -637,25 +653,19 @@ virLogFormatString(char **msg,
* to just grep for it to find the right place.
*/
if ((funcname != NULL)) {
-ret = virAsprintf(msg, "%02d:%02d:%02d.%03d: %d: %s : %s:%lld : %s\n",
- time_info->tm_hour, time_info->tm_min,
- time_info->tm_sec, (int) cur_time->tv_usec / 1000,
- virThreadSelfID(),
- virLogPriorityString(priority), funcname, linenr,
str);
+ret = virAsprintf(msg, "%d: %s : %s:%lld : %s\n",
+ virThreadSelfID(), virLogPriorityString(priority),
+ funcname, linenr, str);
} else {
-ret = virAsprintf(msg, "%02d:%02d:%02d.%03d: %d: %s : %s\n",
- time_info->tm_hour, time_info->tm_min,
- time_info->tm_sec, (int) cur_time->tv_usec / 1000,
- virThreadSelfID(),
- virLogPriorityString(priority), str);
+ret = virAsprintf(msg, "%d: %s : %s\n",
+ virThreadSelfID(), virLogPriorityString(priority),
+ str);
}
return ret;
}
static int
-virLogVersionString(char **msg,
-struct tm *time_info,
-struct timeval *cur_time)
+virLogVersionString(char **msg)
{
#ifdef PACKAGER_VERSION
# ifdef PACKAGER
@@ -670,9 +680,7 @@ virLogVersionString(char **msg,
"libvirt version: " VERSION
#endif
-return virLogFormatString(msg, NULL, 0,
- time_info, cur_time,
- VIR_LOG_INFO, LOG_VERSION_STRING);
+return virLogFormatString(msg, NULL, 0, VIR_LOG_INFO, LOG_VERSION_STRING);
}
/**
@@ -694,9 +702,8 @@ void virLogMessage(const char *category, int priority,
const char *funcname,
static bool logVersionStderr = true;
char *str = NULL;
char *msg = NULL;
-struct timeval cur_time;
-struct tm time_info;
-int len, fprio, i, ret;
+char *timestamp = NULL;
+int fprio, i, ret;
int saved_errno = errno;
int emit = 1;
va_list ap;
@@ -730,16 +737,15 @@ void virLogMessage(const char *category, int priority,
const char *funcname,
goto cleanup;
}
va_end(ap);
-gettimeofday(&cur_time, NULL);
-localtime_r(&cur_time.tv_sec, &time_info);
-ret = virLogFormatString(&msg, funcname, linenr,
- &time_info, &cur_time,
- priority, str);
+ret = virLogFormatString(&msg, funcnam
Re: [libvirt] [PATCH 4/4] virsh: Add 'reset' command for virsh
On 28.09.2011 11:06, Xu He Jie wrote: > > Signed-off-by: Xu He Jie > --- > tools/virsh.c | 39 +++ > 1 files changed, 39 insertions(+), 0 deletions(-) I think this needs to be documented in man-page as well. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/4] remote: Implement 'reset' for remote driver
On 28.09.2011 11:05, Xu He Jie wrote:
>
> Signed-off-by: Xu He Jie
> ---
> src/remote/remote_driver.c |1 +
> src/remote/remote_protocol.x |7 ++-
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
> index 1217d94..372341c 100644
> --- a/src/remote/remote_driver.c
> +++ b/src/remote/remote_driver.c
> @@ -4313,6 +4313,7 @@ static virDriver remote_driver = {
> .domainResume = remoteDomainResume, /* 0.3.0 */
> .domainShutdown = remoteDomainShutdown, /* 0.3.0 */
> .domainReboot = remoteDomainReboot, /* 0.3.0 */
> +.domainReset = remoteDomainReset, /* 0.3.0 */
One small nit, the number in comment means the version when
corresponding API was introduced. So please change this to 0.9.7
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] logging: Add date to log timestamp
--- src/util/logging.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/util/logging.c b/src/util/logging.c index 4ffaf75..9df9003 100644 --- a/src/util/logging.c +++ b/src/util/logging.c @@ -627,8 +627,10 @@ virLogFormatTimestamp(void) gettimeofday(&cur_time, NULL); localtime_r(&cur_time.tv_sec, &time_info); +time_info.tm_year += 1900; -if (virAsprintf(&str, "%02d:%02d:%02d.%03d", +if (virAsprintf(&str, "%4d-%02d-%02d %02d:%02d:%02d.%03d", +time_info.tm_year, time_info.tm_mon, time_info.tm_mday, time_info.tm_hour, time_info.tm_min, time_info.tm_sec, (int) (cur_time.tv_usec / 1000)) < 0) return NULL; -- 1.7.6.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
On 09/28/11 14:56, Richard W.M. Jones wrote: On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote: Ok that seems to work: it removes the vhost part in the virsh launch hence cutting down 12secs of boot time. If nobody comes out with an explanation of why, I will open another thread on the kvm list for this. I would probably need to test disk performance on vhost=on to see if it degrades or it's for another reason that boot time is increased. Is it using CPU during this time, or is the qemu-kvm process idle? It wouldn't be the first time that a network option ROM sat around waiting for an imaginary console user to press a key. Rich. Of the two qemu-kvm processes (threads?) which I see consuming CPU for that VM, one is at about 20%, the other at about 10%. I think it's doing something but maybe not much, or maybe it's really I/O bound and the I/O is slow (as I originarily thought). I will perform some disk benchmarks and follow up, but I can't do that right now... Thank you -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Adding new filesystem 'proxy' to 9p
On Wed, Sep 28, 2011 at 07:49:34PM +0530, M. Mohan Kumar wrote: > Pass-through security model in QEMU 9p server needs root privilege to do few > file operations (like chown, chmod to any mode/uid:gid). There are two issues > in pass-through security model > > 1) TOCTTOU vulnerability: Following symbolic links in the server could > provide access to files beyond 9p export path. > > 2) When libvirt is configured to run qemu as non-root user (for example, if > qemu is configured to run as normal user 'qemu'), running file operations on > pass-through security model would fail because it needs root privileges. > > To overcome above issues, following approach is suggested: A new filesytem > type 'proxy' is introduced. Proxy FS uses chroot + socket combination for > securing the vulnerability known with following symbolic links. Intention of > adding a new filesystem type is to allow qemu to run in non-root mode, but > doing privileged operations using socket IO. > > A new binary (known as proxy helper) will be provided as part of qemu. Proxy > helper will chroot into 9p export path and create a socket pair or a named > socket based on the command line parameter. Qemu and proxy helper will > communicate using this socket. > > We need following changes in the libvirt code to accomodate new 'proxy' > filesystem type: > If qemu 9p server is configured to use 'proxy' FS, libvirt will do > * Create a socket pair > * invoke proxy_helper binary with one of the socket id from the pair as > command line parameters to it with root privilege > * invoke qemu with one of socket id from the pair as paramter to qemu virtfs > after dropping to the configured user privilege. > ie, libvirt will invoke proxy_helper as: > proxy_helper -i -p <9p-path-to-export> > > and qemu will be invoked with following virtfs parameter: > -virtfs proxy,id=,sock_fd= > ,path=/tmp/,security_model=prox,mount_tag=v_pass Interesting proposal. Explicitly comparing the security characteristics of running QEMU as root, vs using the proxy helper * QEMU run as root - QEMU is root, with full capabilities - QEMU has read/write any file/dir, regardless of whether it is exported via 9p * QEMU run as non-root, with proxy_helper root - QEMU is non-root, with no capabilities - QEMU has write to only files with matching UID/GID - proxy_helper is root, with full capabilities - proxy_helper has read/write to any file/dir Since QEMU can send arbitrary FS calls to the proxy_helper, the overall security of the system clearly depends on the security of the proxy_helper process. If we assume that QEMU gets exploited, and that QEMU can find some flaw in the proxy_helper that it can exploit, what damage can the proxy_helper do ? Clearly we want it to not be able to read/write any files other than those exported, even when it becomes compromised, ideally also without requiring SELinux/AppArmour to make it safe. If proxy_helper is running as root with full capabilities, it can trivially escape the chroot[1], so this isn't all that nice for overall system security. The attacker simply needs to find a vulnerability in QEMU and in the proxy_helper, instead of just in QEMU. We want a stronger guarantee than that. In order to be able to chown/chmod files etc, the proxy_helper is going to require some elevated privileges, however, this does not actually imply that proxy_helper needs to run as root. You don't want the proxy_helper to be allowed todo various other things that root would be allowed, even if it is inside a chroot. eg you don't want it being allowed to reboot, mlock, change network setting, mount volumes, make device nodes, and quite alot more. Looking at the man page 'capabilities(7)', I'd venture to suggest that the proxy_helper does not in fact need to run as the 'root' UID/GID at all. All it needs is to have the CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER capabilities, at which point it could still run as the 'qemu' user ID (or perhaps another 'qemuhelper' user ID). So in summary, I think you have a good idea to separate the file handling code into a separate proxy_helper binary. It should not, however, be run as root with all capabilities. It can start as root, and then drop to a non-root user, only keeping the few capabilities it needs. Or in libvirt case, libvirt can spawn it with the minimal set of capabilities directly. eg * QEMU run as non-root, with proxy_helper partially privileged - QEMU is non-root, with no capabilities - QEMU has write to only files with matching UID/GID - proxy_helper is non-root, with selected capabilities - proxy_helper has read/write to any file/dir inside the chroot for the 9p export. Regards, Daniel [1] http://www.bpfh.net/simes/computing/chroot-break.html -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org
Re: [libvirt] [PATCH 5/5] snapshot: implement getparent in qemu
On 09/28/2011 07:22 AM, Daniel Veillard wrote:
@@ -10432,6 +10477,7 @@ static virDriver qemuDriver = {
.domainSnapshotListNames = qemuDomainSnapshotListNames, /* 0.8.0 */
.domainSnapshotLookupByName = qemuDomainSnapshotLookupByName, /* 0.8.0 */
.domainHasCurrentSnapshot = qemuDomainHasCurrentSnapshot, /* 0.8.0 */
+.domainSnapshotGetParent = qemuDomainSnapshotGetParent, /* 0.9.7 */
.domainSnapshotCurrent = qemuDomainSnapshotCurrent, /* 0.8.0 */
.domainRevertToSnapshot = qemuDomainRevertToSnapshot, /* 0.8.0 */
.domainSnapshotDelete = qemuDomainSnapshotDelete, /* 0.8.0 */
ACK, any change to get this implemented for other drivers ?
I don't have ESX or VBox set up to test things, but I'll give the code a
shot if someone else can review the actual implementation. Those are
the only two other hypervisors with snapshots at the moment, and since
they already have the ability to report parent information into the
generated xml, I believe it should be doable to implement this new function.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/5] snapshot: add virsh snapshot-list --tree
On 09/28/2011 07:21 AM, Daniel Veillard wrote:
On Sat, Sep 24, 2011 at 06:30:05PM -0600, Eric Blake wrote:
Reuse the tree listing of nodedev-list, coupled with the new helper
function to efficiently grab snapshot parent names, to produce
tree output for a snapshot hierarchy. For example:
$ virsh snapshot-list dom --tree
root1
|
+- sibling1
+- sibling2
@@ -12987,7 +12987,7 @@ vshGetSnapshotParent(vshControl *ctl,
virDomainSnapshotPtr snapshot)
parent = virDomainSnapshotGetParent(snapshot, 0);
if (parent) {
/* API works, and virDomainSnapshotGetName will succeed */
-parent_name = vshStrdup(ctl, virDomainSnapshotGetName(snapshot));
+parent_name = vshStrdup(ctl, virDomainSnapshotGetName(parent));
goto cleanup;
}
if (last_error->code == VIR_ERR_NO_DOMAIN_SNAPSHOT) {
That looks like a bug fix squashed in here instead of previous patch,
what am I missing ?
Nothing. It was indeed a fix that I had made after the fact, then
merely squashed to the wrong patch when rebasing it back in. I've
floated this hunk up to patch 3/5.
ACK, great improvement,
Code reuse is nice, too - I was dreading writing the tree display code,
until I realized with my recent doc efforts that nodedev-list already
did it for me :)
I've now pushed the amended series (well, through patch 5; patches to
esx and vbox still need to be written and reviewed).
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libguestfs integration: rich disk access for libvirt applications
On Wed, Sep 28, 2011 at 1:19 PM, Richard W.M. Jones wrote: > On Wed, Sep 28, 2011 at 11:14:57AM +0100, Stefan Hajnoczi wrote: >> Does febootstrap-supermin-helper need to be dynamic or could >> libguestfs create a /var/lib/guestfs/appliance-initramfs.gz on >> install? Then libguestfs on the client can create the appliance >> domain and point at that static initramfs file path. > > This is how the Debian package of libguestfs works (Hilko's official > package, not my one). > > However this is troublesome because it means any security problem in a > dependent program is baked into the appliance. Applying a security > update to the host wouldn't update this libguestfs appliance. Compare > this to the way febootstrap-supermin-helper normally works (eg > upstream, Fedora and RHEL): the appliance is rebuilt whenever any > change is noticed in a dependent program. That sounds like a limitation in the packaging system. If 'watch' hooks can be registered by the libguestfs package on its dependencies, then it can rebuild itself every thing a dependency changes. Or the low-tech way is for the libguestfs package maintainer to create a new package each time its dependencies have updated - Debian has a volatile repo for packages that change a lot. At the end of the day we have this problem because the libguestfs appliance is a distro built from the underlying distro itself :)! Stefan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Allow use of file images for LXC container filesystems
On 09/28/2011 02:02 AM, Daniel P. Berrange wrote: The kernel headers available on RHEL 5 or CentOS 5 lack this enum value, which causes compilation to fail if you are trying to build lxc support for these older systems. This code shouldn't ever be being compiled on RHEL5, since it does not have any kernel container namespace support at all. So if we have a new enough kernel for LXC, we should have LO_FLAGS_AUTOCLEAR Which code - all of LXC, or just the code using LO_FLAGS_AUTOCLEAR (that is, code related to lxc namespace support)? Because using just the stock ./autogen.sh on RHEL 5 currently tries to build lxc, and because LO_FLAGS_AUTOCLEAR is missing, it is failing to compile. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: update man page for cpu_shares parameter
On 09/27/2011 09:06 PM, Daniel Veillard wrote: The man page suggest that the cpu_shares parameter of schedinfo allows values 0-262144, but the kernel remaps values 0 and 1 to the minimum 2, just document that behaviour: [root@test ~]# cat /cgroup/cpu/libvirt/qemu/cpu.shares 1024 [root@test ~]# echo 0> /cgroup/cpu/libvirt/qemu/cpu.shares [root@test ~]# cat /cgroup/cpu/libvirt/qemu/cpu.shares 2 [root@test ~]# echo 1> /cgroup/cpu/libvirt/qemu/cpu.shares [root@test ~]# cat /cgroup/cpu/libvirt/qemu/cpu.shares 2 [root@test ~]# * tools/virsh.pod: update description of the cpu_shares parameter to indicate the values 0 and 1 are automatically changed by the kernel to minimal value 2 diff --git a/tools/virsh.pod b/tools/virsh.pod index a01d723..6e3febb 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -914,7 +914,9 @@ If I<--current> is specified, affect the current guest state. B: The cpu_shares parameter has a valid value range of 0-262144; Negative values are wrapped to positive, and larger values are capped at the maximum. -Therefore, -1 is a useful shorthand for 262144. +Therefore, -1 is a useful shorthand for 262144. The values 0 and 1 seems to +also be automatically changed by the Linux kernel to 2 which consider this +the minimal value. Awkward reading to a native English speaker. How about: On the Linux kernel, the values 0 and 1 are automatically converted to a minimal value of 2. ACK with that tweak. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: describe attach-interface parameter target
On 09/27/2011 10:02 PM, Daniel Veillard wrote: This patch is based on a improvement suggested by Kazuhiro Kikuchi of Fujitsu, it gives a description of the target parameter for that command * tools/virsh.pod: add description for target parameter of attach-interface diff --git a/tools/virsh.pod b/tools/virsh.pod index 6e3febb..ca37e57 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1239,6 +1239,10 @@ the default one. I allows to specify the model type. I indicates the changes will affect the next boot of the domain. +B: the optional target value is the name of a device to be created +as the back-end on the node. If not provided a device named "vnetN" or "vifN" +will be created automatically. + ACK. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] qemu: add return value check
On 09/28/2011 02:00 AM, a...@redhat.com wrote: From: Alex Jia * src/qemu/qemu_migration.c: if 'vmdef' is NULL, the function virDomainSaveConfig still dereferences it, it doesn't make sense, so should add return value check to make sure 'vmdef' is non-NULL before calling virDomainSaveConfig, in addition, in order to debug later, also should record error information into log. Signed-off-by: Alex Jia --- src/qemu/qemu_migration.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) ACK and pushed, after fixing your trailing whitespace bug that 'make syntax-check' tripped on. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libguestfs integration: rich disk access for libvirt applications
On Wed, Sep 28, 2011 at 05:35:46PM +0100, Stefan Hajnoczi wrote: > On Wed, Sep 28, 2011 at 1:19 PM, Richard W.M. Jones wrote: > > On Wed, Sep 28, 2011 at 11:14:57AM +0100, Stefan Hajnoczi wrote: > >> Does febootstrap-supermin-helper need to be dynamic or could > >> libguestfs create a /var/lib/guestfs/appliance-initramfs.gz on > >> install? Then libguestfs on the client can create the appliance > >> domain and point at that static initramfs file path. > > > > This is how the Debian package of libguestfs works (Hilko's official > > package, not my one). > > > > However this is troublesome because it means any security problem in a > > dependent program is baked into the appliance. Applying a security > > update to the host wouldn't update this libguestfs appliance. Compare > > this to the way febootstrap-supermin-helper normally works (eg > > upstream, Fedora and RHEL): the appliance is rebuilt whenever any > > change is noticed in a dependent program. > > That sounds like a limitation in the packaging system. > > If 'watch' hooks can be registered by the libguestfs package on its > dependencies, then it can rebuild itself every thing a dependency > changes. Or the low-tech way is for the libguestfs package maintainer > to create a new package each time its dependencies have updated - > Debian has a volatile repo for packages that change a lot. > > At the end of the day we have this problem because the libguestfs > appliance is a distro built from the underlying distro itself :)! RPM & dpkg both have trigger mechanisms. The Debian package doesn't appear to use it for whatever reason. In the RPM we just don't use triggers because the checksum method we're using is more convenient and produces about the same result. We could change this but I want to look at other alternatives as well. In particular, using 9pfs might mean there's no need to explicitly build a root appliance at all (but it needs some qemu changes). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Check for ejected media during startup and migration
On 09/13/2011 10:14 AM, Michal Privoznik wrote:
If the daemon is restarted so we reconnect to monitor, cdrom media
can be ejected. In that case we don't want to show it in domain xml,
or require it on migration destination.
To check for disk status use 'info block' monitor command.
---
NB, the 'info block' is currently not updated yet. The qemu patches
that extend the monitor command are in a queue (that will be merged
quickly):
http://repo.or.cz/w/qemu/kevin.git
head for-anthony
The commit that introduce requested feature:
http://repo.or.cz/w/qemu/kevin.git/commitdiff/e4def80b36231e161b91fa984cd0d73b45668f00
Looks like this is in upstream qemu.git now, so that hurdle is out of
the way; guess I'd better give my formal review :)
My original complaint was that this was polling-based, but you've
convinced me that: 1) polling is necessary for libvirtd restart to learn
the correct state (since events while libvirtd is down are lost), and 2)
this doesn't touch user-visible XML, so the polling is limited to a few
points in time, mainly where we were already talking to the monitor anyway.
If, in the future, qemu does add event tracking, we can then expose
user-visible XML to expose this state to the user (whereas this patch
just uses the information internally); at that point, we'd want to only
expose XML if it can avoid polling (since we can't control how
frequently dumpxml is called, and don't want to involve the monitor on
every user-triggered dumpxml). But that's stuff for a later day, which
does not affect this patch.
+++ b/src/qemu/qemu_driver.c
@@ -8236,6 +8236,13 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
goto endjob;
}
+/* Check if there is and ejected media.
s/and/any/
+int
+qemuDomainCheckEjectableMedia(struct qemud_driver *driver,
+ virDomainObjPtr vm)
+{
+qemuDomainObjPrivatePtr priv = vm->privateData;
+int ret = -1;
+int i;
+
+for (i = 0; i< vm->def->ndisks; i++) {
+virDomainDiskDefPtr disk = vm->def->disks[i];
+struct qemuDomainDiskInfo info;
+
+memset(&info, 0, sizeof(info));
+
+qemuDomainObjEnterMonitor(driver, vm);
This does a monitor command for every disk, even for non-floppy
non-cdrom disks, where we already know the answer (if the disk is not
ejectable, then it can't be in the ejected state). Add a check before
the memset():
if (disk->device == VIR_DOMAIN_DISK_DEVICE_DISK)
continue;
+while (*p) {
+if (STRPREFIX(p, "removable=")) {
+p += strlen("removable=");
+if (virStrToLong_i(p,&dummy, 10,&tmp) == -1)
+VIR_DEBUG("error reading removable: %s", p);
+else
+info->removable = p ? true : false;
I tend to write this as "!!p" or "p != NULL", rather than the longer "p
? true : false", but that's not a show-stopper.
I'm comfortable giving:
ACK with nits fixed.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libguestfs integration: rich disk access for libvirt applications
On Wed, Sep 28, 2011 at 11:14:57AM +0100, Stefan Hajnoczi wrote: > On Tue, Sep 27, 2011 at 12:55 PM, Richard W.M. Jones > wrote: > > To put this all into one place: > > > > (1) An ugly new libvirt API that runs febootstrap-supermin-helper to > > create the appliance. > [...] > > I'm worried about item (1) in this list ... > > This is the only instance where libvirt knows about libguestfs. All > other steps are libguest only or involve libguestfs knowing about > libvirt. > > Would it be possible introduce a "domain-builder" concept into > libvirt? When libguestfs is installed it drops a domain-builder > configuration/script that libvirt can pick up. Then you can say > something like virDomainBuild(name="guestfs-appliance", > builder="guestfs"). We do have a historical syntax from Xen paravirt which lets us call out to a helper at boot time, namely the "" element. With Xen this is typically something like pygrub, or pxegrub, which does some work and writes out a kernel+initrd into temporary files, and prints the file paths + any kernel args on stdout. We could just wire up this concept in KVM too without any real trouble, and then we could have guestfs-bootloader script todo the magic setup Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Allow use of file images for LXC container filesystems
On Wed, Sep 28, 2011 at 10:46:12AM -0600, Eric Blake wrote: > On 09/28/2011 02:02 AM, Daniel P. Berrange wrote: > > >> > >>The kernel headers available on RHEL 5 or CentOS 5 lack this enum > >>value, which causes compilation to fail if you are trying to build > >>lxc support for these older systems. > > >This code shouldn't ever be being compiled on RHEL5, since it does not > >have any kernel container namespace support at all. So if we have a new > >enough kernel for LXC, we should have LO_FLAGS_AUTOCLEAR > > Which code - all of LXC, or just the code using LO_FLAGS_AUTOCLEAR > (that is, code related to lxc namespace support)? Because using > just the stock ./autogen.sh on RHEL 5 currently tries to build lxc, > and because LO_FLAGS_AUTOCLEAR is missing, it is failing to compile. All of LXC. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [fedora-virt] Guest can no longer be bootet with libvirt 0.9.6 from virt-preview repo
[adding libvirt list] On 09/28/2011 09:24 AM, Dennis Jacobfeuerborn wrote: I just noticed that once I upgrade to libvirt-0.9.6-1 from the virt-preview repo on my Fedora 15 machine I can no longer boot guests that use virtio disks. I only get "Boot failed: could not read the boot disk". Removing the disk and re-adding it as IDE drive allows KVM to boot from the disk (although the full boot obviously fails due to the hda/vda naming difference but that's expected). After downgrading to libvirt-0.8.8-7 again the problem goes away and the guest boot fine from virtio disks. Somewhere around 0.9.4 libvirt switched to use a different method to indicate from which device to boot. See http://libvirt.org/git/?p=libvirt.git;a=commit;h=c3068d4d2381146ed46051ad636a928edea5c602 I think this causes Seabios to skip using extboot.bin for booting and to try to directly boot from a disk. If your Seabios version is too old, it won't support booting from virtio disks directly. The libvirt package should probably be updated to require seabios-bin>= 0.6.2. Yes, that probably needs to happen to libvirt.spec when built for F16 (and thus imported into F15 via virt-preview). I'll tackle that, since I've been making a couple other spec file patches lately. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Allow use of file images for LXC container filesystems
On 09/28/2011 11:38 AM, Daniel P. Berrange wrote: On Wed, Sep 28, 2011 at 10:46:12AM -0600, Eric Blake wrote: On 09/28/2011 02:02 AM, Daniel P. Berrange wrote: The kernel headers available on RHEL 5 or CentOS 5 lack this enum value, which causes compilation to fail if you are trying to build lxc support for these older systems. This code shouldn't ever be being compiled on RHEL5, since it does not have any kernel container namespace support at all. So if we have a new enough kernel for LXC, we should have LO_FLAGS_AUTOCLEAR Which code - all of LXC, or just the code using LO_FLAGS_AUTOCLEAR (that is, code related to lxc namespace support)? Because using just the stock ./autogen.sh on RHEL 5 currently tries to build lxc, and because LO_FLAGS_AUTOCLEAR is missing, it is failing to compile. All of LXC. OK, that makes my configure.ac patch easier - probe for LO_FLAGS_AUTOCLEAR as a prereq for --with-lxc. Patch coming up soon. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [fedora-virt] Guest can no longer be bootet with libvirt 0.9.6 from virt-preview repo
On Wed, Sep 28, 2011 at 11:41:11AM -0600, Eric Blake wrote: > [adding libvirt list] > > On 09/28/2011 09:24 AM, Dennis Jacobfeuerborn wrote: > > I just noticed that once I upgrade to libvirt-0.9.6-1 from the > > virt-preview > > repo on my Fedora 15 machine I can no longer boot guests that use virtio > > disks. I only get "Boot failed: could not read the boot disk". > > Removing the disk and re-adding it as IDE drive allows KVM to boot from > > the > > disk (although the full boot obviously fails due to the hda/vda naming > > difference but that's expected). > > > > After downgrading to libvirt-0.8.8-7 again the problem goes away and the > > guest boot fine from virtio disks. > > > > >> > >> Somewhere around 0.9.4 libvirt switched to use a different method to > >> indicate from which device to boot. > >> See > >> http://libvirt.org/git/?p=libvirt.git;a=commit;h=c3068d4d2381146ed46051ad636a928edea5c602 > >> > >> I think this causes Seabios to skip using extboot.bin for booting and > >> to try to directly boot from a disk. > >> If your Seabios version is too old, it won't support booting from > >> virtio disks directly. > >> > > > > > The libvirt package should probably be updated to require seabios-bin>= > > 0.6.2. > > Yes, that probably needs to happen to libvirt.spec when built for F16 > (and thus imported into F15 via virt-preview). I'll tackle that, since > I've been making a couple other spec file patches lately. It is not a libvirt requirement really. It is QEMU that is advertising it supports the per-device boot ordering feature. libvirt queries this and then tries to use it. QEMU should have required the new Seabios if it intends to advertise this feature. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libguestfs integration: rich disk access for libvirt applications
On Wed, Sep 28, 2011 at 06:37:17PM +0100, Daniel P. Berrange wrote: > On Wed, Sep 28, 2011 at 11:14:57AM +0100, Stefan Hajnoczi wrote: > > On Tue, Sep 27, 2011 at 12:55 PM, Richard W.M. Jones > > wrote: > > > To put this all into one place: > > > > > > (1) An ugly new libvirt API that runs febootstrap-supermin-helper to > > > create the appliance. > > [...] > > > I'm worried about item (1) in this list ... > > > > This is the only instance where libvirt knows about libguestfs. All > > other steps are libguest only or involve libguestfs knowing about > > libvirt. > > > > Would it be possible introduce a "domain-builder" concept into > > libvirt? When libguestfs is installed it drops a domain-builder > > configuration/script that libvirt can pick up. Then you can say > > something like virDomainBuild(name="guestfs-appliance", > > builder="guestfs"). > > We do have a historical syntax from Xen paravirt which lets us call out > to a helper at boot time, namely the "" element. With Xen > this is typically something like pygrub, or pxegrub, which does some > work and writes out a kernel+initrd into temporary files, and prints > the file paths + any kernel args on stdout. > > We could just wire up this concept in KVM too without any real trouble, > and then we could have guestfs-bootloader script todo the magic setup I'm fine with this. Are there security implications to allowing users to add clauses pointing at random scripts that get run on remote machines as different users? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [fedora-virt] Guest can no longer be bootet with libvirt 0.9.6 from virt-preview repo
On 09/28/2011 11:43 AM, Daniel P. Berrange wrote: The libvirt package should probably be updated to require seabios-bin>= 0.6.2. Yes, that probably needs to happen to libvirt.spec when built for F16 (and thus imported into F15 via virt-preview). I'll tackle that, since I've been making a couple other spec file patches lately. It is not a libvirt requirement really. It is QEMU that is advertising it supports the per-device boot ordering feature. libvirt queries this and then tries to use it. QEMU should have required the new Seabios if it intends to advertise this feature. Ah, then the problem is qemu's spec file. On F16, I see this from 'yum deplist qemu-system-x86': dependency: seabios-bin provider: seabios-bin.noarch 0.6.2-2.fc16 So it is not requiring a minimal version, and when backporting qemu to F15 via virt-preview, no seabios-bin upgrade is being pulled in. I've created https://bugzilla.redhat.com/show_bug.cgi?id=741992 against qemu. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Check for ejected media during startup and migration
On 28.09.2011 19:35, Eric Blake wrote: > On 09/13/2011 10:14 AM, Michal Privoznik wrote: > > ... > ACK with nits fixed. > Thanks, pushed. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libguestfs integration: rich disk access for libvirt applications
On 09/28/2011 11:52 AM, Richard W.M. Jones wrote: We do have a historical syntax from Xen paravirt which lets us call out to a helper at boot time, namely the "" element. With Xen this is typically something like pygrub, or pxegrub, which does some work and writes out a kernel+initrd into temporary files, and prints the file paths + any kernel args on stdout. We could just wire up this concept in KVM too without any real trouble, and then we could have guestfs-bootloader script todo the magic setup I'm fine with this. Are there security implications to allowing users to add clauses pointing at random scripts that get run on remote machines as different users? No more so than the fact that we let random clients specify devices to random devices on remote machines. Right now, granting non-read-only connection rights to a user effectively gives them root access to the machine. There's eventual plans to further restrict things via per-command ACLs, and this should be considered during those plans, but until then, I don't see it as any larger a hole than anything else already present in libvirt design. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [fedora-virt] Guest can no longer be bootet with libvirt 0.9.6 from virt-preview repo
On 09/28/2011 07:56 PM, Eric Blake wrote: On 09/28/2011 11:43 AM, Daniel P. Berrange wrote: The libvirt package should probably be updated to require seabios-bin>= 0.6.2. Yes, that probably needs to happen to libvirt.spec when built for F16 (and thus imported into F15 via virt-preview). I'll tackle that, since I've been making a couple other spec file patches lately. It is not a libvirt requirement really. It is QEMU that is advertising it supports the per-device boot ordering feature. libvirt queries this and then tries to use it. QEMU should have required the new Seabios if it intends to advertise this feature. Ah, then the problem is qemu's spec file. On F16, I see this from 'yum deplist qemu-system-x86': dependency: seabios-bin provider: seabios-bin.noarch 0.6.2-2.fc16 So it is not requiring a minimal version, and when backporting qemu to F15 via virt-preview, no seabios-bin upgrade is being pulled in. I've created https://bugzilla.redhat.com/show_bug.cgi?id=741992 against qemu. I'm not sure if that is correct. It is purely the libvirt update that breaks things: 1. qemu 0.14.0, libvirt 0.8.8, seabios-bin 0.6.0 => virtio boots fine 2. update libvirt to 0.9.6 => virtio boot breaks 3. update seabios-bin to 0.6.2 => virtio works again Since I didn't update qemu at all any changes to its dependencies do not help in this situation. Regards, Dennis -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [fedora-virt] Guest can no longer be bootet with libvirt 0.9.6 from virt-preview repo
On Wed, 2011-09-28 at 11:56 -0600, Eric Blake wrote: > On 09/28/2011 11:43 AM, Daniel P. Berrange wrote: > >>> The libvirt package should probably be updated to require seabios-bin>= > >>> 0.6.2. > >> > >> Yes, that probably needs to happen to libvirt.spec when built for F16 > >> (and thus imported into F15 via virt-preview). I'll tackle that, since > >> I've been making a couple other spec file patches lately. > > > > It is not a libvirt requirement really. It is QEMU that is advertising > > it supports the per-device boot ordering feature. libvirt queries this > > and then tries to use it. QEMU should have required the new Seabios if > > it intends to advertise this feature. > > Ah, then the problem is qemu's spec file. On F16, I see this from 'yum > deplist qemu-system-x86': > >dependency: seabios-bin > provider: seabios-bin.noarch 0.6.2-2.fc16 > > So it is not requiring a minimal version, and when backporting qemu to > F15 via virt-preview, no seabios-bin upgrade is being pulled in. I've > created https://bugzilla.redhat.com/show_bug.cgi?id=741992 against qemu. > Well, there was no older seabios shipping with F16, so it made sense. As for virt-preview, seabios updates were also available there long before the qemu which required them. Enabling virt-preview and doing a yum update would have installed the new seabios as well. I just don't think that virt-preview can ever be trusted to pick and choose specific packages, you either want the F15 virt stack as it is, or the F16 (virt-preview) virt stack. Justin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 1/2] Actually provide gvir_storage_vol_get_path()
From: "Zeeshan Ali (Khattak)"
This was only declared in header previously but not implemented.
---
libvirt-gobject/libvirt-gobject-storage-vol.c | 11 +++
libvirt-gobject/libvirt-gobject.sym |1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-storage-vol.c
b/libvirt-gobject/libvirt-gobject-storage-vol.c
index b94f6cf..6cbae84 100644
--- a/libvirt-gobject/libvirt-gobject-storage-vol.c
+++ b/libvirt-gobject/libvirt-gobject-storage-vol.c
@@ -182,6 +182,17 @@ const gchar *gvir_storage_vol_get_name(GVirStorageVol *vol)
return name;
}
+const gchar *gvir_storage_vol_get_path(GVirStorageVol *vol)
+{
+GVirStorageVolPrivate *priv = vol->priv;
+const char *path;
+
+if (!(path = virStorageVolGetPath(priv->handle))) {
+g_error("Failed to get storage_vol path on %p", priv->handle);
+}
+
+return path;
+}
/**
* gvir_storage_vol_get_config:
diff --git a/libvirt-gobject/libvirt-gobject.sym
b/libvirt-gobject/libvirt-gobject.sym
index ff2f4cf..ea4ec38 100644
--- a/libvirt-gobject/libvirt-gobject.sym
+++ b/libvirt-gobject/libvirt-gobject.sym
@@ -83,6 +83,7 @@ LIBVIRT_GOBJECT_0.0.1 {
gvir_storage_vol_get_type;
gvir_storage_vol_handle_get_type;
gvir_storage_vol_get_name;
+ gvir_storage_vol_get_path;
gvir_storage_vol_get_config;
gvir_connection_handle_get_type;
--
1.7.6.2
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 2/2] API for storage pool volume management
From: "Zeeshan Ali (Khattak)"
---
libvirt-gobject/libvirt-gobject-storage-pool.c | 304 +++-
libvirt-gobject/libvirt-gobject-storage-pool.h | 19 ++
libvirt-gobject/libvirt-gobject.sym|6 +
3 files changed, 319 insertions(+), 10 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-storage-pool.c
b/libvirt-gobject/libvirt-gobject-storage-pool.c
index 0959642..5499e4d 100644
--- a/libvirt-gobject/libvirt-gobject-storage-pool.c
+++ b/libvirt-gobject/libvirt-gobject-storage-pool.c
@@ -38,7 +38,10 @@ extern gboolean debugFlag;
struct _GVirStoragePoolPrivate
{
+GMutex *lock;
virStoragePoolPtr handle;
+
+GHashTable *volumes;
};
G_DEFINE_TYPE(GVirStoragePool, gvir_storage_pool, G_TYPE_OBJECT);
@@ -64,8 +67,8 @@ static void gvir_storage_pool_get_property(GObject *object,
GValue *value,
GParamSpec *pspec)
{
-GVirStoragePool *conn = GVIR_STORAGE_POOL(object);
-GVirStoragePoolPrivate *priv = conn->priv;
+GVirStoragePool *pool = GVIR_STORAGE_POOL(object);
+GVirStoragePoolPrivate *priv = pool->priv;
switch (prop_id) {
case PROP_HANDLE:
@@ -83,8 +86,8 @@ static void gvir_storage_pool_set_property(GObject *object,
const GValue *value,
GParamSpec *pspec)
{
-GVirStoragePool *conn = GVIR_STORAGE_POOL(object);
-GVirStoragePoolPrivate *priv = conn->priv;
+GVirStoragePool *pool = GVIR_STORAGE_POOL(object);
+GVirStoragePoolPrivate *priv = pool->priv;
switch (prop_id) {
case PROP_HANDLE:
@@ -101,13 +104,20 @@ static void gvir_storage_pool_set_property(GObject
*object,
static void gvir_storage_pool_finalize(GObject *object)
{
-GVirStoragePool *conn = GVIR_STORAGE_POOL(object);
-GVirStoragePoolPrivate *priv = conn->priv;
+GVirStoragePool *pool = GVIR_STORAGE_POOL(object);
+GVirStoragePoolPrivate *priv = pool->priv;
+
+DEBUG("Finalize GVirStoragePool=%p", pool);
-DEBUG("Finalize GVirStoragePool=%p", conn);
+if (priv->volumes) {
+g_hash_table_unref(priv->volumes);
+priv->volumes = NULL;
+}
virStoragePoolFree(priv->handle);
+g_mutex_free(priv->lock);
+
G_OBJECT_CLASS(gvir_storage_pool_parent_class)->finalize(object);
}
@@ -137,15 +147,17 @@ static void
gvir_storage_pool_class_init(GVirStoragePoolClass *klass)
}
-static void gvir_storage_pool_init(GVirStoragePool *conn)
+static void gvir_storage_pool_init(GVirStoragePool *pool)
{
GVirStoragePoolPrivate *priv;
-DEBUG("Init GVirStoragePool=%p", conn);
+DEBUG("Init GVirStoragePool=%p", pool);
-priv = conn->priv = GVIR_STORAGE_POOL_GET_PRIVATE(conn);
+priv = pool->priv = GVIR_STORAGE_POOL_GET_PRIVATE(pool);
memset(priv, 0, sizeof(*priv));
+
+priv->lock = g_mutex_new();
}
static gpointer
@@ -220,3 +232,275 @@ GVirConfigStoragePool
*gvir_storage_pool_get_config(GVirStoragePool *pool,
g_free(xml);
return conf;
}
+
+typedef gint (* CountFunction) (virStoragePoolPtr vpool);
+typedef gint (* ListFunction) (virStoragePoolPtr vpool, gchar **lst, gint max);
+
+static gchar ** fetch_list(virStoragePoolPtr vpool,
+ const char *name,
+ CountFunction count_func,
+ ListFunction list_func,
+ GCancellable *cancellable,
+ gint *length,
+ GError **err)
+{
+gchar **lst = NULL;
+gint n = 0;
+gint i;
+
+if ((n = count_func(vpool)) < 0) {
+*err = gvir_error_new(GVIR_STORAGE_POOL_ERROR,
+ 0,
+ "Unable to count %s", name);
+goto error;
+}
+
+if (n) {
+if (g_cancellable_set_error_if_cancelled(cancellable, err))
+goto error;
+
+lst = g_new(gchar *, n);
+if ((n = list_func(vpool, lst, n)) < 0) {
+*err = gvir_error_new(GVIR_STORAGE_POOL_ERROR,
+ 0,
+ "Unable to list %s %d", name, n);
+goto error;
+}
+}
+
+*length = n;
+return lst;
+
+error:
+for (i = 0 ; i < n; i++)
+g_free(lst[i]);
+g_free(lst);
+return NULL;
+}
+
+/**
+ * gvir_storage_pool_refresh:
+ * @pool: the storage pool
+ * @cancellable: (allow-none)(transfer none): cancellation object
+ */
+gboolean gvir_storage_pool_refresh(GVirStoragePool *pool,
+ GCancellable *cancellable,
+ GError **err)
+{
+GVirStoragePoolPrivate *priv = pool->priv;
+GHashTable *vol_hash;
+gchar **volumes = NULL;
+gint nvolumes = 0;
+gboolean ret = FALSE;
+gint i;
+virStoragePoolPtr vpool = NULL;
+
+vpool = priv->handle;
+
+if (virStoragePool
Re: [libvirt] [PATCHv2 2/1] docs: document node device XML
On 09/28/2011 02:14 AM, Daniel Veillard wrote: On Tue, Sep 27, 2011 at 11:29:04AM -0600, Eric Blake wrote: Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page. --- + + I would just add an extra line for the separation between the two output +ACK, Done with that nit fixed. I've now pushed this, as well as the virsh.pod changes (assuming your ack applied to both patches). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC PATCH] lxc: don't return error on GetInfo when cgroups not yet set up
Nova (openstack) calls libvirt to create a container, then
periodically checks using GetInfo to see whether the container
is up. If it does this too quickly, then libvirt returns an
error, which in libvirt.py causes an exception to be raised,
the same type as if the container was bad.
This may not be the best way to handle it, but with this
patch, we assume that a -ENOENT return from virCgroupForDomain
means the cgroups are not yet set up, and so we return the
same values for cpu and memory usage as if the domain was not
active.
Signed-off-by: Serge Hallyn
---
src/lxc/lxc_driver.c | 37 +
1 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
index 4b62600..a68b8e7 100644
--- a/src/lxc/lxc_driver.c
+++ b/src/lxc/lxc_driver.c
@@ -542,26 +542,31 @@ static int lxcDomainGetInfo(virDomainPtr dom,
info->cpuTime = 0;
info->memory = vm->def->mem.cur_balloon;
} else {
-if (virCgroupForDomain(driver->cgroup, vm->def->name, &cgroup, 0) !=
0) {
+int ret = virCgroupForDomain(driver->cgroup, vm->def->name, &cgroup,
0);
+if (ret == -ENOENT) {
+/* cgroups are not set up yet */
+info->cpuTime = 0;
+info->memory = vm->def->mem.cur_balloon;
+} else if (ret != 0) {
lxcError(VIR_ERR_INTERNAL_ERROR,
_("Unable to get cgroup for %s"), vm->def->name);
goto cleanup;
-}
-
-if (virCgroupGetCpuacctUsage(cgroup, &(info->cpuTime)) < 0) {
-lxcError(VIR_ERR_OPERATION_FAILED,
- "%s", _("Cannot read cputime for domain"));
-goto cleanup;
-}
-if ((rc = virCgroupGetMemoryUsage(cgroup, &(info->memory))) < 0) {
-lxcError(VIR_ERR_OPERATION_FAILED,
- "%s", _("Cannot read memory usage for domain"));
-if (rc == -ENOENT) {
-/* Don't fail if we can't read memory usage due to a lack of
- * kernel support */
-info->memory = 0;
-} else
+} else {
+if (virCgroupGetCpuacctUsage(cgroup, &(info->cpuTime)) < 0) {
+lxcError(VIR_ERR_OPERATION_FAILED,
+ "%s", _("Cannot read cputime for domain"));
goto cleanup;
+}
+if ((rc = virCgroupGetMemoryUsage(cgroup, &(info->memory))) < 0) {
+lxcError(VIR_ERR_OPERATION_FAILED,
+ "%s", _("Cannot read memory usage for domain"));
+if (rc == -ENOENT) {
+/* Don't fail if we can't read memory usage due to a lack
of
+ * kernel support */
+info->memory = 0;
+} else
+goto cleanup;
+}
}
}
--
1.7.5.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [fedora-virt] Guest can no longer be bootet with libvirt 0.9.6 from virt-preview repo
On Wed, Sep 28, 2011 at 20:16:23 +0200, Dennis Jacobfeuerborn wrote: > On 09/28/2011 07:56 PM, Eric Blake wrote: > > Ah, then the problem is qemu's spec file. On F16, I see this from 'yum > > deplist qemu-system-x86': > > > > dependency: seabios-bin > > provider: seabios-bin.noarch 0.6.2-2.fc16 > > > > So it is not requiring a minimal version, and when backporting qemu to F15 > > via virt-preview, no seabios-bin upgrade is being pulled in. I've created > > https://bugzilla.redhat.com/show_bug.cgi?id=741992 against qemu. > > > > I'm not sure if that is correct. It is purely the libvirt update that > breaks things: > > 1. qemu 0.14.0, libvirt 0.8.8, seabios-bin 0.6.0 > => virtio boots fine > > 2. update libvirt to 0.9.6 > => virtio boot breaks > > 3. update seabios-bin to 0.6.2 > => virtio works again > > Since I didn't update qemu at all any changes to its dependencies do not > help in this situation. That's a bug in qemu 0.14.0 package, which should have required newer seabios as well. Upgrading libvirt just exposes this bug because new libvirt started to use bootindex option by default if qemu supports it (while older libvirt used it only when explicitly asked to). This option is supported by qemu since 0.14.0. But for it to actually work, new seabios is also needed. Upstream qemu 0.14.0 is bundled with such seabios so it's just fedora packaging that is broken because it allows qemu 0.14.0 to be installed without a new enough seabios. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 6/9] Update GVirConnection signals
---
libvirt-gobject/libvirt-gobject-connection.c | 36 +++---
libvirt-gobject/libvirt-gobject-network-filter.c | 14
2 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-connection.c
b/libvirt-gobject/libvirt-gobject-connection.c
index aa4a320..4cbebe0 100644
--- a/libvirt-gobject/libvirt-gobject-connection.c
+++ b/libvirt-gobject/libvirt-gobject-connection.c
@@ -55,6 +55,15 @@ enum {
PROP_HANDLE,
};
+enum {
+VIR_CONNECTION_OPENED,
+VIR_CONNECTION_CLOSED,
+VIR_DOMAIN_ADDED,
+VIR_DOMAIN_REMOVED,
+LAST_SIGNAL
+};
+
+static gint signals[LAST_SIGNAL];
#define GVIR_CONNECTION_ERROR gvir_connection_error_quark()
@@ -137,7 +146,7 @@ static GVirStream*
gvir_connection_stream_new(GVirConnection *self G_GNUC_UNUSED
static void gvir_connection_class_init(GVirConnectionClass *klass)
{
-GObjectClass *object_class = G_OBJECT_CLASS (klass);
+GObjectClass *object_class = G_OBJECT_CLASS(klass);
object_class->finalize = gvir_connection_finalize;
object_class->get_property = gvir_connection_get_property;
@@ -158,7 +167,7 @@ static void gvir_connection_class_init(GVirConnectionClass
*klass)
G_PARAM_STATIC_NICK |
G_PARAM_STATIC_BLURB));
-g_signal_new("vir-connection-opened",
+signals[VIR_CONNECTION_OPENED] = g_signal_new("vir-connection-opened",
G_OBJECT_CLASS_TYPE(object_class),
G_SIGNAL_RUN_FIRST,
G_STRUCT_OFFSET(GVirConnectionClass, vir_connection_opened),
@@ -166,7 +175,8 @@ static void gvir_connection_class_init(GVirConnectionClass
*klass)
g_cclosure_marshal_VOID__VOID,
G_TYPE_NONE,
0);
-g_signal_new("vir-connection-closed",
+
+signals[VIR_CONNECTION_CLOSED] = g_signal_new("vir-connection-closed",
G_OBJECT_CLASS_TYPE(object_class),
G_SIGNAL_RUN_FIRST,
G_STRUCT_OFFSET(GVirConnectionClass, vir_connection_closed),
@@ -175,22 +185,25 @@ static void
gvir_connection_class_init(GVirConnectionClass *klass)
G_TYPE_NONE,
0);
-g_signal_new("vir-domain-added",
+signals[VIR_DOMAIN_ADDED] = g_signal_new("vir-domain-added",
G_OBJECT_CLASS_TYPE(object_class),
G_SIGNAL_RUN_FIRST,
G_STRUCT_OFFSET(GVirConnectionClass, vir_domain_added),
NULL, NULL,
- g_cclosure_marshal_VOID__VOID,
+ g_cclosure_marshal_VOID__OBJECT,
G_TYPE_NONE,
- 0);
-g_signal_new("vir-domain-removed",
+ 1,
+ G_TYPE_OBJECT);
+
+signals[VIR_DOMAIN_REMOVED] = g_signal_new("vir-domain-removed",
G_OBJECT_CLASS_TYPE(object_class),
G_SIGNAL_RUN_FIRST,
G_STRUCT_OFFSET(GVirConnectionClass, vir_domain_removed),
NULL, NULL,
- g_cclosure_marshal_VOID__VOID,
+ g_cclosure_marshal_VOID__OBJECT,
G_TYPE_NONE,
- 0);
+ 1,
+ G_TYPE_OBJECT);
g_object_class_install_property(object_class,
PROP_HANDLE,
@@ -266,7 +279,8 @@ gboolean gvir_connection_open(GVirConnection *conn,
g_mutex_unlock(priv->lock);
-g_signal_emit_by_name(conn, "vir-connection-opened");
+g_signal_emit(conn, signals[VIR_CONNECTION_OPENED], 0);
+
return TRUE;
}
@@ -371,7 +385,7 @@ void gvir_connection_close(GVirConnection *conn)
g_mutex_unlock(priv->lock);
-g_signal_emit_by_name(conn, "vir-connection-closed");
+g_signal_emit(conn, signals[VIR_CONNECTION_CLOSED], 0);
}
typedef gint (* CountFunction) (virConnectPtr vconn);
diff --git a/libvirt-gobject/libvirt-gobject-network-filter.c
b/libvirt-gobject/libvirt-gobject-network-filter.c
index 467627f..020cdc0 100644
--- a/libvirt-gobject/libvirt-gobject-network-filter.c
+++ b/libvirt-gobject/libvirt-gobject-network-filter.c
@@ -64,8 +64,8 @@ static void gvir_network_filter_get_property(GObject *object,
GValue *value,
GParamSpec *pspec)
{
-GVirNetworkFilter *conn = GVIR_NETWORK_FILTER(object);
-GVirNetworkFilterPrivate *priv = conn->priv;
+GVirNetworkFilter *nf = GVIR_NETWORK_FILTER(object);
+GVirNetworkFilterPrivate *priv = nf->priv;
switch (prop_id) {
case PROP_HANDLE:
@@ -83,8 +83,8 @@ static void gvir_network_filter_set_property(GObject *object,
const GValue *value,
GParamSpec *pspec)
{
-GVirNetworkFilter *conn = GVIR_NETWORK_FILTER(object);
-GVirNetworkFilterPriv
[libvirt] [libvirt-glib 9/9] Silence a compilation warning
--- libvirt-gobject/libvirt-gobject-domain-snapshot.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.c b/libvirt-gobject/libvirt-gobject-domain-snapshot.c index 0f9e826..cc17b60 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.c +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.c @@ -187,6 +187,8 @@ const gchar *gvir_domain_snapshot_get_name(GVirDomainSnapshot *snapshot) if (snapshot || !snapshot) return NULL; #endif + +g_return_val_if_reached(NULL); } -- 1.7.6.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 7/9] Make get_uuid() return a static string
The string is not so large, we avoid fragmentation and duplication (especially
in hashtable)
---
libvirt-gobject/libvirt-gobject-connection.c | 12 +-
libvirt-gobject/libvirt-gobject-domain.c | 26 --
libvirt-gobject/libvirt-gobject-domain.h |2 +-
libvirt-gobject/libvirt-gobject-network-filter.c | 26 --
libvirt-gobject/libvirt-gobject-network-filter.h |2 +-
libvirt-gobject/libvirt-gobject-network.c| 24 ++--
libvirt-gobject/libvirt-gobject-network.h|2 +-
libvirt-gobject/libvirt-gobject-secret.c | 26 --
libvirt-gobject/libvirt-gobject-secret.h |2 +-
libvirt-gobject/libvirt-gobject-storage-pool.c | 26 --
libvirt-gobject/libvirt-gobject-storage-pool.h |2 +-
11 files changed, 104 insertions(+), 46 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-connection.c
b/libvirt-gobject/libvirt-gobject-connection.c
index 4cbebe0..e99a08d 100644
--- a/libvirt-gobject/libvirt-gobject-connection.c
+++ b/libvirt-gobject/libvirt-gobject-connection.c
@@ -502,7 +502,7 @@ gboolean gvir_connection_fetch_domains(GVirConnection *conn,
doms = g_hash_table_new_full(g_str_hash,
g_str_equal,
- g_free,
+ NULL,
g_object_unref);
for (i = 0 ; i < nactive ; i++) {
@@ -519,7 +519,7 @@ gboolean gvir_connection_fetch_domains(GVirConnection *conn,
NULL));
g_hash_table_insert(doms,
-gvir_domain_get_uuid(dom),
+(gpointer)gvir_domain_get_uuid(dom),
dom);
}
@@ -537,7 +537,7 @@ gboolean gvir_connection_fetch_domains(GVirConnection *conn,
NULL));
g_hash_table_insert(doms,
-gvir_domain_get_uuid(dom),
+(gpointer)gvir_domain_get_uuid(dom),
dom);
}
@@ -637,7 +637,7 @@ gboolean gvir_connection_fetch_storage_pools(GVirConnection
*conn,
NULL));
g_hash_table_insert(pools,
-gvir_storage_pool_get_uuid(pool),
+(gpointer)gvir_storage_pool_get_uuid(pool),
pool);
}
@@ -657,7 +657,7 @@ gboolean gvir_connection_fetch_storage_pools(GVirConnection
*conn,
NULL));
g_hash_table_insert(pools,
-gvir_storage_pool_get_uuid(pool),
+(gpointer)gvir_storage_pool_get_uuid(pool),
pool);
}
@@ -1060,7 +1060,7 @@ GVirDomain *gvir_connection_create_domain(GVirConnection
*conn,
g_mutex_lock(priv->lock);
g_hash_table_insert(priv->domains,
-gvir_domain_get_uuid(domain),
+(gpointer)gvir_domain_get_uuid(domain),
domain);
g_mutex_unlock(priv->lock);
diff --git a/libvirt-gobject/libvirt-gobject-domain.c
b/libvirt-gobject/libvirt-gobject-domain.c
index 001c787..41545f2 100644
--- a/libvirt-gobject/libvirt-gobject-domain.c
+++ b/libvirt-gobject/libvirt-gobject-domain.c
@@ -39,6 +39,7 @@ extern gboolean debugFlag;
struct _GVirDomainPrivate
{
virDomainPtr handle;
+gchar uuid[VIR_UUID_STRING_BUFLEN];
};
G_DEFINE_TYPE(GVirDomain, gvir_domain, G_TYPE_OBJECT);
@@ -122,6 +123,20 @@ static void gvir_domain_finalize(GObject *object)
}
+static void gvir_domain_constructed(GObject *object)
+{
+GVirDomain *conn = GVIR_DOMAIN(object);
+GVirDomainPrivate *priv = conn->priv;
+
+G_OBJECT_CLASS(gvir_domain_parent_class)->constructed(object);
+
+/* xxx we may want to turn this into an initable */
+if (virDomainGetUUIDString(priv->handle, priv->uuid) < 0) {
+g_error("Failed to get domain UUID on %p", priv->handle);
+}
+}
+
+
static void gvir_domain_class_init(GVirDomainClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
@@ -129,6 +144,7 @@ static void gvir_domain_class_init(GVirDomainClass *klass)
object_class->finalize = gvir_domain_finalize;
object_class->get_property = gvir_domain_get_property;
object_class->set_property = gvir_domain_set_property;
+object_class->constructed = gvir_domain_constructed;
g_object_class_install_property(object_class,
PROP_HANDLE,
@@ -269,15 +285,11 @@ const gchar *gvir_domain_get_name(GVirDomain *dom)
}
-gchar *gvir_domain_get_uuid(GVirDomain *dom)
+const gchar *gvir_domain_get_uuid(GVirDomain *dom)
{
-GVirDomainPrivate *priv = dom->priv;
-char *uuid = g_new(gchar, VIR_UUID_STRING_BUFLEN);
+g_return_val_i
[libvirt] [libvirt-glib 3/9] Add .mailmap for common aliases
--- .mailmap |5 + 1 files changed, 5 insertions(+), 0 deletions(-) create mode 100644 .mailmap diff --git a/.mailmap b/.mailmap new file mode 100644 index 000..482a46e --- /dev/null +++ b/.mailmap @@ -0,0 +1,5 @@ +# Format of each line: +# + + + -- 1.7.6.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 5/9] Add a few GVirDomain detailled signals
---
libvirt-gobject/libvirt-gobject-domain.c | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-domain.c
b/libvirt-gobject/libvirt-gobject-domain.c
index 75e7eb9..001c787 100644
--- a/libvirt-gobject/libvirt-gobject-domain.c
+++ b/libvirt-gobject/libvirt-gobject-domain.c
@@ -49,6 +49,16 @@ enum {
PROP_HANDLE,
};
+enum {
+VIR_STARTED,
+VIR_SUSPENDED,
+VIR_RESUMED,
+VIR_STOPPED,
+VIR_UPDATED,
+LAST_SIGNAL
+};
+
+static gint signals[LAST_SIGNAL];
#define GVIR_DOMAIN_ERROR gvir_domain_error_quark()
@@ -133,6 +143,55 @@ static void gvir_domain_class_init(GVirDomainClass *klass)
G_PARAM_STATIC_NICK |
G_PARAM_STATIC_BLURB));
+signals[VIR_STARTED] = g_signal_new("vir-started",
+G_OBJECT_CLASS_TYPE(object_class),
+G_SIGNAL_RUN_LAST |
G_SIGNAL_NO_RECURSE |
+G_SIGNAL_NO_HOOKS | G_SIGNAL_DETAILED,
+0,
+NULL, NULL,
+g_cclosure_marshal_VOID__VOID,
+G_TYPE_NONE,
+1, G_TYPE_STRING |
G_SIGNAL_TYPE_STATIC_SCOPE);
+
+signals[VIR_SUSPENDED] = g_signal_new("vir-suspended",
+G_OBJECT_CLASS_TYPE(object_class),
+G_SIGNAL_RUN_LAST |
G_SIGNAL_NO_RECURSE |
+G_SIGNAL_NO_HOOKS | G_SIGNAL_DETAILED,
+0,
+NULL, NULL,
+g_cclosure_marshal_VOID__VOID,
+G_TYPE_NONE,
+1, G_TYPE_STRING |
G_SIGNAL_TYPE_STATIC_SCOPE);
+
+signals[VIR_RESUMED] = g_signal_new("vir-resumed",
+G_OBJECT_CLASS_TYPE(object_class),
+G_SIGNAL_RUN_LAST |
G_SIGNAL_NO_RECURSE |
+G_SIGNAL_NO_HOOKS | G_SIGNAL_DETAILED,
+0,
+NULL, NULL,
+g_cclosure_marshal_VOID__VOID,
+G_TYPE_NONE,
+1, G_TYPE_STRING |
G_SIGNAL_TYPE_STATIC_SCOPE);
+
+signals[VIR_STOPPED] = g_signal_new("vir-stopped",
+G_OBJECT_CLASS_TYPE(object_class),
+G_SIGNAL_RUN_LAST |
G_SIGNAL_NO_RECURSE |
+G_SIGNAL_NO_HOOKS | G_SIGNAL_DETAILED,
+0,
+NULL, NULL,
+g_cclosure_marshal_VOID__VOID,
+G_TYPE_NONE,
+1, G_TYPE_STRING |
G_SIGNAL_TYPE_STATIC_SCOPE);
+
+signals[VIR_UPDATED] = g_signal_new("vir-updated",
+G_OBJECT_CLASS_TYPE(object_class),
+G_SIGNAL_RUN_LAST |
G_SIGNAL_NO_RECURSE | G_SIGNAL_NO_HOOKS,
+0,
+NULL, NULL,
+g_cclosure_marshal_VOID__VOID,
+G_TYPE_NONE,
+0);
+
g_type_class_add_private(klass, sizeof(GVirDomainPrivate));
}
--
1.7.6.2
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 2/9] Register event using GOnce to avoid multiple initializations
---
libvirt-glib/libvirt-glib-event.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/libvirt-glib/libvirt-glib-event.c
b/libvirt-glib/libvirt-glib-event.c
index 65af739..a785c93 100644
--- a/libvirt-glib/libvirt-glib-event.c
+++ b/libvirt-glib/libvirt-glib-event.c
@@ -359,7 +359,8 @@ cleanup:
}
-void gvir_event_register(void) {
+static gpointer event_register_once(gpointer data G_GNUC_UNUSED)
+{
eventlock = g_mutex_new();
virEventRegisterImpl(gvir_event_handle_add,
gvir_event_handle_update,
@@ -367,5 +368,13 @@ void gvir_event_register(void) {
gvir_event_timeout_add,
gvir_event_timeout_update,
gvir_event_timeout_remove);
+return NULL;
+}
+
+void gvir_event_register(void)
+{
+static GOnce once = G_ONCE_INIT;
+
+g_once(&once, event_register_once, NULL);
}
--
1.7.6.2
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 8/9] Connect a bunch of domain event to signals
---
libvirt-gobject/libvirt-gobject-connection.c | 126 ++
1 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-connection.c
b/libvirt-gobject/libvirt-gobject-connection.c
index e99a08d..34781e6 100644
--- a/libvirt-gobject/libvirt-gobject-connection.c
+++ b/libvirt-gobject/libvirt-gobject-connection.c
@@ -148,6 +148,8 @@ static void gvir_connection_class_init(GVirConnectionClass
*klass)
{
GObjectClass *object_class = G_OBJECT_CLASS(klass);
+gvir_event_register();
+
object_class->finalize = gvir_connection_finalize;
object_class->get_property = gvir_connection_get_property;
object_class->set_property = gvir_connection_set_property;
@@ -244,6 +246,125 @@ GVirConnection *gvir_connection_new(const char *uri)
}
+static int domain_event_cb(virConnectPtr conn G_GNUC_UNUSED,
+ virDomainPtr dom,
+ int event,
+ int detail,
+ void *opaque)
+{
+gchar uuid[VIR_UUID_STRING_BUFLEN];
+GVirConnection *gconn = opaque;
+GVirDomain *gdom;
+GVirConnectionPrivate *priv = gconn->priv;
+
+if (virDomainGetUUIDString(dom, uuid) < 0) {
+g_warning("Failed to get domain UUID on %p", dom);
+return 0;
+}
+
+DEBUG("%s: %s event:%d, detail:%d", G_STRFUNC, uuid, event, detail);
+
+g_mutex_lock(priv->lock);
+gdom = g_hash_table_lookup(priv->domains, uuid);
+g_mutex_unlock(priv->lock);
+
+if (gdom == NULL) {
+gdom = GVIR_DOMAIN(g_object_new(GVIR_TYPE_DOMAIN, "handle", dom,
NULL));
+
+g_mutex_lock(priv->lock);
+g_hash_table_insert(priv->domains,
(gpointer)gvir_domain_get_uuid(gdom), gdom);
+g_mutex_unlock(priv->lock);
+}
+
+switch (event) {
+case VIR_DOMAIN_EVENT_DEFINED:
+if (detail == VIR_DOMAIN_EVENT_DEFINED_ADDED)
+g_signal_emit(gconn, signals[VIR_DOMAIN_ADDED], 0, gdom);
+else if (detail == VIR_DOMAIN_EVENT_DEFINED_UPDATED)
+g_signal_emit_by_name(gdom, "vir-updated");
+else
+g_warn_if_reached();
+break;
+
+case VIR_DOMAIN_EVENT_UNDEFINED:
+if (detail == VIR_DOMAIN_EVENT_UNDEFINED_REMOVED) {
+g_mutex_lock(priv->lock);
+g_hash_table_steal(priv->domains, uuid);
+g_mutex_unlock(priv->lock);
+
+g_signal_emit(gconn, signals[VIR_DOMAIN_REMOVED], 0, gdom);
+g_object_unref(gdom);
+} else
+g_warn_if_reached();
+break;
+
+case VIR_DOMAIN_EVENT_STARTED:
+if (detail == VIR_DOMAIN_EVENT_STARTED_BOOTED)
+g_signal_emit_by_name(gdom, "vir-started::booted");
+else if (detail == VIR_DOMAIN_EVENT_STARTED_MIGRATED)
+g_signal_emit_by_name(gdom, "vir-started::migrated");
+else if (detail == VIR_DOMAIN_EVENT_STARTED_RESTORED)
+g_signal_emit_by_name(gdom, "vir-started::restored");
+else if (detail == VIR_DOMAIN_EVENT_STARTED_FROM_SNAPSHOT)
+g_signal_emit_by_name(gdom, "vir-started::from-snapshot");
+else
+g_warn_if_reached();
+break;
+
+case VIR_DOMAIN_EVENT_SUSPENDED:
+if (detail == VIR_DOMAIN_EVENT_SUSPENDED_PAUSED)
+g_signal_emit_by_name(gdom, "vir-suspended::paused");
+else if (detail == VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED)
+g_signal_emit_by_name(gdom, "vir-suspended::migrated");
+else if (detail == VIR_DOMAIN_EVENT_SUSPENDED_IOERROR)
+g_signal_emit_by_name(gdom, "vir-suspended::ioerror");
+else if (detail == VIR_DOMAIN_EVENT_SUSPENDED_WATCHDOG)
+g_signal_emit_by_name(gdom, "vir-suspended::watchdog");
+else if (detail == VIR_DOMAIN_EVENT_SUSPENDED_RESTORED)
+g_signal_emit_by_name(gdom, "vir-suspended::restored");
+else if (detail == VIR_DOMAIN_EVENT_SUSPENDED_FROM_SNAPSHOT)
+g_signal_emit_by_name(gdom, "vir-suspended::from-snapshot");
+else
+g_warn_if_reached();
+break;
+
+case VIR_DOMAIN_EVENT_RESUMED:
+if (detail == VIR_DOMAIN_EVENT_RESUMED_UNPAUSED)
+g_signal_emit_by_name(gdom, "vir-resumed::unpaused");
+else if (detail == VIR_DOMAIN_EVENT_RESUMED_MIGRATED)
+g_signal_emit_by_name(gdom, "vir-resumed::migrated");
+else if (detail == VIR_DOMAIN_EVENT_RESUMED_FROM_SNAPSHOT)
+g_signal_emit_by_name(gdom, "vir-resumed::from-snapshot");
+else
+g_warn_if_reached();
+break;
+
+case VIR_DOMAIN_EVENT_STOPPED:
+if (detail == VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN)
+g_signal_emit_by_name(gdom, "v
[libvirt] [libvirt-glib 4/9] Plug a memleak
---
libvirt-gobject/libvirt-gobject-connection.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-connection.c
b/libvirt-gobject/libvirt-gobject-connection.c
index c0c47da..aa4a320 100644
--- a/libvirt-gobject/libvirt-gobject-connection.c
+++ b/libvirt-gobject/libvirt-gobject-connection.c
@@ -505,7 +505,7 @@ gboolean gvir_connection_fetch_domains(GVirConnection *conn,
NULL));
g_hash_table_insert(doms,
-g_strdup(gvir_domain_get_uuid(dom)),
+gvir_domain_get_uuid(dom),
dom);
}
@@ -523,7 +523,7 @@ gboolean gvir_connection_fetch_domains(GVirConnection *conn,
NULL));
g_hash_table_insert(doms,
-g_strdup(gvir_domain_get_uuid(dom)),
+gvir_domain_get_uuid(dom),
dom);
}
@@ -604,7 +604,7 @@ gboolean gvir_connection_fetch_storage_pools(GVirConnection
*conn,
pools = g_hash_table_new_full(g_str_hash,
g_str_equal,
- g_free,
+ NULL,
g_object_unref);
for (i = 0 ; i < nactive ; i++) {
@@ -623,7 +623,7 @@ gboolean gvir_connection_fetch_storage_pools(GVirConnection
*conn,
NULL));
g_hash_table_insert(pools,
-g_strdup(gvir_storage_pool_get_uuid(pool)),
+gvir_storage_pool_get_uuid(pool),
pool);
}
@@ -643,7 +643,7 @@ gboolean gvir_connection_fetch_storage_pools(GVirConnection
*conn,
NULL));
g_hash_table_insert(pools,
-g_strdup(gvir_storage_pool_get_uuid(pool)),
+gvir_storage_pool_get_uuid(pool),
pool);
}
@@ -1046,7 +1046,7 @@ GVirDomain *gvir_connection_create_domain(GVirConnection
*conn,
g_mutex_lock(priv->lock);
g_hash_table_insert(priv->domains,
-g_strdup(gvir_domain_get_uuid(domain)),
+gvir_domain_get_uuid(domain),
domain);
g_mutex_unlock(priv->lock);
--
1.7.6.2
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-glib 1/9] doc: add some missing return value documentation
From: Marc-André Lureau --- libvirt-gobject/libvirt-gobject-stream.c |1 + libvirt-gobject/libvirt-gobject-stream.h |2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/libvirt-gobject/libvirt-gobject-stream.c b/libvirt-gobject/libvirt-gobject-stream.c index 255ad73..519d733 100644 --- a/libvirt-gobject/libvirt-gobject-stream.c +++ b/libvirt-gobject/libvirt-gobject-stream.c @@ -191,6 +191,7 @@ stream_sink(virStreamPtr st G_GNUC_UNUSED, * @stream: the stream * @func: (scope notified): the callback for writing data to application * @user_data: (closure): data to be passed to @callback + * Returns: the number of bytes consumed or -1 upon error * * Receive the entire data stream, sending the data to the * requested data sink. This is simply a convenient alternative diff --git a/libvirt-gobject/libvirt-gobject-stream.h b/libvirt-gobject/libvirt-gobject-stream.h index 27fa8b7..fd9c9bb 100644 --- a/libvirt-gobject/libvirt-gobject-stream.h +++ b/libvirt-gobject/libvirt-gobject-stream.h @@ -65,6 +65,8 @@ struct _GVirStreamClass * @buf: data pointer * @nbytes: data size * @user_data: user data passed to the function + * Returns: the number of bytes filled, 0 upon end + * of file, or -1 upon error */ typedef gint (* GVirStreamSinkFunc) (GVirStream *stream, const gchar *buf, -- 1.7.6.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/1] lvm storage backend: handle command_names=1 in lvm.conf (v2)
[ Thanks for the feedback, Eric. Hopefully I correctly incorporated it
in this version. This version still tests fine with and without
lvm.conf command_names=1 ]
If the regexes supported (?:pvs)?, then we could handle this by
optionally matching but not returning the initial command name. But it
doesn't. So add a new char* argument to
virStorageBackendRunProgRegex(). If that argument is NULL then we act
as usual. Otherwise, if the string at that argument is found at the
start of a returned line, we drop that before running the regex.
With this patch, virt-manager shows me lvs with command_names 1 or 0.
The definitions of PVS_BASE etc may want to be moved into the configure
scripts (though given how PVS is found, IIUC that could only happen if
pvs was a link to pvs_real), but in any case no sense dealing with that
until we're sure this is an ok way to handle it.
Changelog:
Sep 28: Use STRSKIP and make cmd_to_ignore arg const, as per Eric's
feedback.
Signed-off-by: Serge Hallyn
---
src/storage/storage_backend.c | 15 +++
src/storage/storage_backend.h |2 +-
src/storage/storage_backend_fs.c |2 +-
src/storage/storage_backend_iscsi.c |4 ++--
src/storage/storage_backend_logical.c |9 ++---
5 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
index d125504..dd7e36b 100644
--- a/src/storage/storage_backend.c
+++ b/src/storage/storage_backend.c
@@ -1400,7 +1400,7 @@ virStorageBackendRunProgRegex(virStoragePoolObjPtr pool,
const char **regex,
int *nvars,
virStorageBackendListVolRegexFunc func,
- void *data)
+ void *data, const char *cmd_to_ignore)
{
int fd = -1, err, ret = -1;
FILE *list = NULL;
@@ -1460,13 +1460,20 @@ virStorageBackendRunProgRegex(virStoragePoolObjPtr pool,
}
while (fgets(line, sizeof(line), list) != NULL) {
+char *p = NULL;
/* Strip trailing newline */
int len = strlen(line);
if (len && line[len-1] == '\n')
line[len-1] = '\0';
+/* if cmd_to_ignore is specified, then ignore it */
+if (cmd_to_ignore)
+p = STRSKIP(line, cmd_to_ignore);
+if (!p)
+p = line;
+
for (i = 0 ; i <= maxReg && i < nregex ; i++) {
-if (regexec(®[i], line, nvars[i]+1, vars, 0) == 0) {
+if (regexec(®[i], p, nvars[i]+1, vars, 0) == 0) {
maxReg++;
if (i == 0)
@@ -1475,9 +1482,9 @@ virStorageBackendRunProgRegex(virStoragePoolObjPtr pool,
/* NULL terminate each captured group in the line */
for (j = 0 ; j < nvars[i] ; j++) {
/* NB vars[0] is the full pattern, so we offset j by 1 */
-line[vars[j+1].rm_eo] = '\0';
+p[vars[j+1].rm_eo] = '\0';
if ((groups[ngroup++] =
- strdup(line + vars[j+1].rm_so)) == NULL) {
+ strdup(p + vars[j+1].rm_so)) == NULL) {
virReportOOMError();
goto cleanup;
}
diff --git a/src/storage/storage_backend.h b/src/storage/storage_backend.h
index 67ac32c..75ed676 100644
--- a/src/storage/storage_backend.h
+++ b/src/storage/storage_backend.h
@@ -140,7 +140,7 @@ int virStorageBackendRunProgRegex(virStoragePoolObjPtr pool,
const char **regex,
int *nvars,
virStorageBackendListVolRegexFunc func,
- void *data);
+ void *data, const char *cmd_to_ignore);
int virStorageBackendRunProgNul(virStoragePoolObjPtr pool,
const char **prog,
diff --git a/src/storage/storage_backend_fs.c b/src/storage/storage_backend_fs.c
index da98f87..d678625 100644
--- a/src/storage/storage_backend_fs.c
+++ b/src/storage/storage_backend_fs.c
@@ -266,7 +266,7 @@ virStorageBackendFileSystemNetFindPoolSources(virConnectPtr
conn ATTRIBUTE_UNUSE
if (virStorageBackendRunProgRegex(NULL, prog, 1, regexes, vars,
virStorageBackendFileSystemNetFindPoolSourcesFunc,
-&state) < 0)
+&state, NULL) < 0)
goto cleanup;
retval = virStoragePoolSourceListFormat(&state.list);
diff --git a/src/storage/storage_backend_iscsi.c
b/src/storage/storage_backend_iscsi.c
index 346e698..99e69c9 100644
--- a/src/storage/storage_backend_iscsi.c
+++ b/src/storage/storage_backend_iscsi.c
@@ -160,7 +160,7 @@ virStorageBackendISCSISession(virStoragePoolObjPtr pool,
regexes,
vars,
Re: [libvirt] [libvirt-glib 7/9] Make get_uuid() return a static string
On Wed, Sep 28, 2011 at 9:30 PM, Marc-André Lureau wrote: > The string is not so large, we avoid fragmentation and duplication > (especially in hashtable) "static" is the wrong word, I meant const. -- Marc-André Lureau -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] AHCI support in qemu driver
Daniel P. Berrange wrote:
> On Tue, Sep 27, 2011 at 10:22:48PM -0600, Jim Fehlig wrote:
>
>> I have some time this week to work on libvirt and thought Daniel's
>> suggestion [1] for adding AHCI support in the qemu driver would be a
>> useful endeavor.
>>
>> I've managed to start a qemu instance using AHCI with attached hackery,
>> iff I have a controller defined. E.g.
>>
>>
>>
>>
>>
>>
>>
>> > function='0x0'/>
>>
>>
>> which results in qemu args
>>
>> -device ahci,id=ahci0,bus=pci.0,multifunction=on,addr=0x3.0x0 -drive
>> file=/var/lib/libvirt/images/test/disk0.raw,if=none,id=drive-sata-dik0,format=raw
>> -device
>> ide-drive,bus=ahci0.0,drive=drive-sata-disk0,id=sata-disk0,bootindex=1
>>
>> If the controller is not explicitly defined, the AHCI device (-device
>> ahci,...) is not created and qemu fails with
>>
>> qemu-kvm: -device
>> ide-drive,bus=ahci0.0,drive=drive-sata-disk0,id=sata-disk0,bootindex=1:
>> Bus 'a
>> hci0.0' not found
>>
>> I'm not quite sure how to create the controller when not explicitly
>> defined in the config.
>>
>
> There is a function virDomainDefAddImplicitControllers() in the
> domain_conf.c which looks to be missing the SATA case.
>
Ah, thanks!
>
>> Also, I suspect there are many things I'm missing in adding support for
>> this controller. E.g., I've ignored hotplug for the moment. What would
>> be considered minimal functionality for supporting this controller?
>>
>
> Just being able to launch a guest + the test data files for qemuxml2argvtest
> would be the minimum. Hotplug would be desirable if it works in QEMU, but
> not critical.
>
Ok, sounds good. I was concerned there was something I was overlooking.
>
>
>> >From 02c793bdc86e3f7f1775f58ef4776e32512ecdb8 Mon Sep 17 00:00:00 2001
>> From: Jim Fehlig
>> Date: Tue, 27 Sep 2011 21:46:08 -0600
>> Subject: [PATCH] Add AHCI support to qemu driver
>>
>> ---
>> src/qemu/qemu_capabilities.c |3 +++
>> src/qemu/qemu_capabilities.h |1 +
>> src/qemu/qemu_command.c | 32 +---
>> 3 files changed, 29 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>> index 8e20e3f..7122756 100644
>> --- a/src/qemu/qemu_capabilities.c
>> +++ b/src/qemu/qemu_capabilities.c
>> @@ -139,6 +139,7 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST,
>>"no-shutdown",
>>
>>"cache-unsafe", /* 75 */
>> + "ich9-ahci",
>> );
>>
>> struct qemu_feature_flags {
>> @@ -1241,6 +1242,8 @@ qemuCapsParseDeviceStr(const char *str, virBitmapPtr
>> flags)
>> qemuCapsSet(flags, QEMU_CAPS_USB_REDIR);
>> if (strstr(str, "name \"usb-hub\""))
>> qemuCapsSet(flags, QEMU_CAPS_USB_HUB);
>> +if (strstr(str, "name \"ich9-ahci\""))
>> +qemuCapsSet(flags, QEMU_CAPS_ICH9_AHCI);
>>
>> /* Prefer -chardev spicevmc (detected earlier) over -device spicevmc */
>> if (!qemuCapsGet(flags, QEMU_CAPS_CHARDEV_SPICEVMC) &&
>> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
>> index ae3de90..1e23451 100644
>> --- a/src/qemu/qemu_capabilities.h
>> +++ b/src/qemu/qemu_capabilities.h
>> @@ -113,6 +113,7 @@ enum qemuCapsFlags {
>> QEMU_CAPS_NO_SHUTDOWN = 74, /* usable -no-shutdown */
>>
>> QEMU_CAPS_DRIVE_CACHE_UNSAFE = 75, /* Is cache=unsafe supported? */
>> +QEMU_CAPS_ICH9_AHCI = 76, /* -device ich9-ahci */
>>
>> QEMU_CAPS_LAST, /* this must always be the last item
>> */
>> };
>> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
>> index 9174a5f..86c3f86 100644
>> --- a/src/qemu/qemu_command.c
>> +++ b/src/qemu/qemu_command.c
>> @@ -1702,6 +1702,12 @@ qemuBuildDriveDevStr(virDomainDiskDefPtr disk,
>>disk->info.addr.drive.bus,
>>disk->info.addr.drive.unit);
>> break;
>> +case VIR_DOMAIN_DISK_BUS_SATA:
>> +virBufferAddLit(&opt, "ide-drive");
>>
>
> Oh, AHCI still wants the 'ide-drive' devices ? I always figured it would
> have a new type of device there too, but perhaps not.
>
AFAICT, yes, that is the case. I used the syntax noted in the qemu
changelog for 0.14
http://wiki.qemu.org/ChangeLog/0.14#IDE_.2F_AHCI
Updated patch on the way. Thanks for the help!
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Add AHCI support to qemu driver
Tested with multiple AHCI controllers and multiple disks attached
to a controller. E.g.,
---
docs/formatdomain.html.in |9 +++--
docs/schemas/domaincommon.rng |1 +
src/conf/domain_conf.c | 14 +
src/qemu/qemu_capabilities.c |3 ++
src/qemu/qemu_capabilities.h |1 +
src/qemu/qemu_command.c| 30
.../qemuxml2argv-disk-sata-device.args |6
.../qemuxml2argv-disk-sata-device.xml | 25
tests/qemuxml2argvtest.c |3 ++
9 files changed, 82 insertions(+), 10 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 3087d01..b6a0c66 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -972,11 +972,12 @@
as a device ordering hint. The optional bus
attribute specifies the type of disk device to emulate;
possible values are driver specific, with typical values being
-"ide", "scsi", "virtio", "xen" or "usb". If omitted, the bus type is
-inferred from the style of the device name. eg, a device named 'sda'
-will typically be exported using a SCSI bus.
+"ide", "scsi", "virtio", "xen", "usb" or "sata". If omitted, the bus
+type is inferred from the style of the device name. eg, a device named
+'sda' will typically be exported using a SCSI bus.
Since 0.0.3; bus attribute since
0.4.3;
-"usb" attribute value since after 0.4.4
+"usb" attribute value since after 0.4.4; "sata" attribute value since
+0.9.7
driver
The optional driver element allows specifying further details
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index be98be0..675d55d 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -790,6 +790,7 @@
xen
usb
uml
+sata
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index a918679..6a7f296 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2157,6 +2157,15 @@ virDomainDiskDefAssignAddress(virCapsPtr caps,
virDomainDiskDefPtr def)
def->info.addr.drive.unit = (idx % 2);
break;
+case VIR_DOMAIN_DISK_BUS_SATA:
+/* For SATA we define the default mapping to be 6 units
+ * per bus, 1 bus per controller, many controllers */
+def->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE;
+def->info.addr.drive.controller = idx / 6;
+def->info.addr.drive.bus = 0;
+def->info.addr.drive.unit = idx % 6;
+break;
+
case VIR_DOMAIN_DISK_BUS_FDC:
/* For FDC we define the default mapping to be 2 units
* per bus, 1 bus per controller, many controllers */
@@ -8675,6 +8684,11 @@ int virDomainDefAddImplicitControllers(virDomainDefPtr
def)
VIR_DOMAIN_DISK_BUS_IDE) < 0)
return -1;
+if (virDomainDefAddDiskControllersForType(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_SATA,
+ VIR_DOMAIN_DISK_BUS_SATA) < 0)
+return -1;
+
if (virDomainDefMaybeAddVirtioSerialController(def) < 0)
return -1;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 8e20e3f..7122756 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -139,6 +139,7 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST,
"no-shutdown",
"cache-unsafe", /* 75 */
+ "ich9-ahci",
);
struct qemu_feature_flags {
@@ -1241,6 +1242,8 @@ qemuCapsParseDeviceStr(const char *str, virBitmapPtr
flags)
qemuCapsSet(flags, QEMU_CAPS_USB_REDIR);
if (strstr(str, "name \"usb-hub\""))
qemuCapsSet(flags, QEMU_CAPS_USB_HUB);
+if (strstr(str, "name \"ich9-ahci\""))
+qemuCapsSet(flags, QEMU_CAPS_ICH9_AHCI);
/* Prefer -chardev spicevmc (detected earlier) over -device spicevmc */
if (!qemuCapsGet(flags, QEMU_CAPS_CHARDEV_SPICEVMC) &&
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index ae3de90..1e23451 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -113,6 +113,7 @@ enum qemuCapsFlags {
QEMU_CAPS_NO_SHUTDOWN = 74, /* usable -no-shutdown */
QEMU_CAPS_DRIVE_CACHE_UNSAFE = 75, /* Is cache=unsafe supported? */
+QEMU_CAPS_ICH9_AHCI = 76, /* -device ich9-ahci */
QEMU_CAPS_LAST, /* this must always be the last item */
};
diff --git a/src/qemu/qemu_command.
Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
On 09/28/11 16:51, Reeted wrote: On 09/28/11 14:56, Richard W.M. Jones wrote: On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote: Ok that seems to work: it removes the vhost part in the virsh launch hence cutting down 12secs of boot time. If nobody comes out with an explanation of why, I will open another thread on the kvm list for this. I would probably need to test disk performance on vhost=on to see if it degrades or it's for another reason that boot time is increased. Is it using CPU during this time, or is the qemu-kvm process idle? It wouldn't be the first time that a network option ROM sat around waiting for an imaginary console user to press a key. Rich. Of the two qemu-kvm processes (threads?) which I see consuming CPU for that VM, one is at about 20%, the other at about 10%. I think it's doing something but maybe not much, or maybe it's really I/O bound and the I/O is slow (as I originarily thought). I will perform some disk benchmarks and follow up, but I can't do that right now... Thank you Ok still didn't do benchmarks but I am now quite a lot convinced that it's either a disk performance problem or cpu problem with vhostnet on. Not a network performance problem or idle wait. Because I have installed another virtual machine now, which is a fedora core 6 (old!), but with a debian natty kernel vmlinuz + initrd so that it supports virtio devices. The initrd part from Ubuntu is extremely short so finishes immediately, but then the fedora core 6 boot is much longer than with my previous ubuntu-barebone virtual machine, and with more messages, and I can see the various daemons being brought up one by one, and I can tell you such boot (and also the teardown of services during shutdown) is very much faster with vhostnet disabled. With vhostnet disabled it takes 30seconds to come up (since after grub), and 28 seconds to shutdown. With vhostnet enabled it takes 1m19sec to come up (since after grub), and 1m04sec to shutdown. I have some ideas about disk benchmarking, that would be fio or simple dd. What could I use for CPU benchmarking? Would "openssl speed" be too simple? Thank you -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] formatdomain.html.in: fix tickpolicy
there is no option "none": >From libvirt/src/conf/domain_conf.c VIR_ENUM_IMPL(virDomainTimerTickpolicy, VIR_DOMAIN_TIMER_TICKPOLICY_LAST, "delay", "catchup", "merge", "discard"); Replacing with delay. Signed-off-by: Douglas Schilling Landgraf --- docs/formatdomain.html.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 9c3c2e8..49a2c09 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -746,7 +746,7 @@- + ... -- 1.7.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] "Connection does not support host device enumeration"
2011/9/27 Osier Yang : > 于 2011年09月27日 01:13, Kaushal Shriyan 写道: > > Hi, Kaushal > > I don't use CentOS, so don't known it, though I guess it's > the intention or mistake of the packager. > > you can compile from the source code youself. > > # rpm -qi libvirt > > You will see the version you use currently, and get the same > source tarball from http://libvirt.org/sources/ to compile. > > Of course, you can download newer source to compile, but > it may also need newer dependency packages. So compiling > from the same version is the easiest way. :-) > > If you really don't want to compile yourself, just file a bug > to CentOS, guess the packger will help you do it. > > Regards, > Osier > > > Hi Osier > > Can you please point me to the rpm version which has hal and udev > flags enabled by default for CentOS 5.6 ? > > Regards > > Kaushal > > On Thu, Sep 22, 2011 at 10:22 AM, Osier Yang wrote: > > 于 2011年09月22日 12:46, Osier Yang 写道: > > 于 2011年09月22日 12:41, Kaushal Shriyan 写道: > > On Thu, Sep 22, 2011 at 9:41 AM, Osier Yang wrote: > > 于 2011年09月22日 09:11, Kaushal Shriyan 写道: > > does not support host device enumeration > > Seems your libvirt is compiled without --with-hal and > --with-udev > > Regards > Osier > > Hi Osier > > Thanks for the reply. Please let me know how do i enable this feature > since its a binary package installed on CentOS 5.6 x86_64 > architecture. > > You need to re-compile from the source if that's true. > > http://libvirt.org/compiling.html > > To make sure get your wanted, specifying --with-hal/--with-udev explicitly > with "yes" will help. > > > Regards, > Osier > > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > > > Hi Osier, Is there libudev-devel or udev-devel package available on CentOS 5.6 ? [root@~]# yum search udev-devel Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: centos.aol.in * extras: centos.aol.in * updates: centos.aol.in base | 1.1 kB 00:00 extras | 2.1 kB 00:00 updates | 1.9 kB 00:00 Warning: No matches found for: udev-devel No Matches found [root@~]# yum search libudev-devel Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: centos.aol.in * extras: centos.aol.in * updates: centos.aol.in Warning: No matches found for: libudev-devel No Matches found [root@~]# Please suggest further and also it seems like this package is not available in CentOS 5.6 Regards Kaushal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
