On Wed, Jul 29, 2009 at 10:33:12AM +0100, Daniel P. Berrange wrote:
[..snip..]
> FYI, my libvirt-glib work is temporarily on hold due to lack of time.
> As such I've just pulled the event loop code directly into the
> virt-viewer application, so I can do a release of virt-viewer without
> needing to do a release of libvirt-glib right now. I want to pick it
> up again in the future and do something a little more advanced than
> just event loops, actually providing a proper GObject's for each libvirt
> objects so that GUI apps can just use normal GLib signal handling and
> properties, etc. virt-manager already does alot of this kind of wrapping
> in its own code, so its really pulling that out into a library where it
> can be shared
Sounds great! Will the old API still be there? I've just uploaded
libvirt-glib into Debian:
http://ftp-master.debian.org/new/libvirt-glib_0~0.git22fac-1.html
and mentioned it in my talk at Debconf:
http://honk.sigxcpu.org/projects/libvirt/libvirt-dc09.pdf
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Jul 29, 2009 at 12:50:17PM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 29, 2009 at 01:24:24PM +0200, Guido G?nther wrote:
> > On Wed, Jul 29, 2009 at 10:33:12AM +0100, Daniel P. Berrange wrote:
> > [..snip..]
> > > FYI, my libvirt-glib work is temporarily on hold due to lack of time.
> > > As such I've just pulled the event loop code directly into the
> > > virt-viewer application, so I can do a release of virt-viewer without
> > > needing to do a release of libvirt-glib right now. I want to pick it
> > > up again in the future and do something a little more advanced than
> > > just event loops, actually providing a proper GObject's for each libvirt
> > > objects so that GUI apps can just use normal GLib signal handling and
> > > properties, etc. virt-manager already does alot of this kind of wrapping
> > > in its own code, so its really pulling that out into a library where it
> > > can be shared
> > Sounds great! Will the old API still be there? I've just uploaded
>
> It will almost certainly change. This is reason I've not done any
> release of libvirt-glib - i didn't want to commit to this API as
> it is. That said there's only one public symbol there so far. Could
> do some evil linker script black magic to add compatibility for that
O.k. I'll keep it in experimental than so it won't end up in any stable
release. Thanks for the update,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Aug 06, 2009 at 02:37:53PM +0200, Daniel Veillard wrote:
> On Thu, Aug 06, 2009 at 12:39:34PM +0100, Daniel P. Berrange wrote:
> > On Wed, Aug 05, 2009 at 12:58:33PM +0200, Jonas Eriksson wrote:
> > > * src/remote_internal.c: Honour USE_SOCAT by selecting between
> > > netcat/nc and socat at compile time.
> >
> > Changing the binary used at compile time is really not a good idea,
> > because libvirt uses netcat on the remote machine, which is not
> > required to be the same distro as the client machine on whihc you
> > built libvirt. So by making socat vs netcat a compile time option
> > you pretty much guarentee incompatibility between libvirt client &
> > server betweeen distros. It is really better to fix netcat on the
> > distros where -U isn't available.
>
> As for other case where we had multiple binary options, isn't
> picking up at runtime a possibility, suppose we can catch that
> 'netcat -U' fails, we could try to fallback to socat.
...and /bin/nc.openbsd on Debian. Having this would be appreciated
(unfortunately I don't have time to work on it).
Cheers,
-- Guido
> In any case a compile time switch doesn't sounds right to me but
> being more flexible at runtime is similar to the way we have done
> for dependance on other binaries.
>
> 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
>
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi Daniel,
On Fri, Oct 23, 2009 at 02:05:39PM +0100, Daniel P. Berrange wrote:
> The daemonizing code lets the parent exit almost immediately. This
> means that it may think it has successfully started even when
> important failures occur like not being able to acquire the PID
> file. It also means network sockets are not yet open.
With this patch applied to 0.7.2 I'm seeing:
# libvirtd -d
15:20:22.457: error : main:2971 : Failed to fork as daemon: Success
about every second time I start the daemon. Any idea where this comes
from?
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Oct 28, 2009 at 06:52:49PM +, Daniel P. Berrange wrote:
> On Wed, Oct 28, 2009 at 03:22:38PM +0100, Guido G?nther wrote:
> > Hi Daniel,
> > On Fri, Oct 23, 2009 at 02:05:39PM +0100, Daniel P. Berrange wrote:
> > > The daemonizing code lets the parent exit almost immediately. This
> > > means that it may think it has successfully started even when
> > > important failures occur like not being able to acquire the PID
> > > file. It also means network sockets are not yet open.
> > With this patch applied to 0.7.2 I'm seeing:
> >
> > # libvirtd -d
> > 15:20:22.457: error : main:2971 : Failed to fork as daemon: Success
> >
> > about every second time I start the daemon. Any idea where this comes
> > from?
>
> No, but that sounds bad to me - something I'm not expecting must be
> going on here. Definitely sounds like a race condition.
I should add that the daemon is running fine afterwards. It's just that
the parent believes it doesn't.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jul 22, 2008 at 04:53:19PM +0100, Daniel P. Berrange wrote:
> On Tue, Jul 22, 2008 at 11:42:03AM -0400, Cole Robinson wrote:
[..snip..]
> > 2) If a cpuset isn't specified, def->cpumask is null.
> > However qemudInitCpus from qemu_driver.c doesn't know
> > how to handle this, causing libvirtd to crash. This
> > function is also using QEMUD_CPUMASK_LEN which I think
> > should be replaced with VIR_DOMAIN_CPUMASK_LEN. I tried
> > the obvious fix of just skipping the dependent code
> > if cpumask is null, but there still seemed to be problems
> > and I didn't dig much deeper.
>
> I'm surprised that doesn't work - we should be able to just
> skip the bit of code within the HAVE_SCHED_GETAFFINITY
> conditional, and go straight to the part when it issues the
> 'cont' command to the monitor to start execution.
What you suggested works here.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
currently virsh create foo.xml overwrites running domains. In case of
qemu this leaves detached qemu processes around and the domain creation
fails later on being unable to start other domains afterwards - not
nice.
Attached patch checks if we already have a running domain by that name
and in this case refuses to create a new domain from xml by that name.
Probably this check needs to be pushed further upward since this might
affect other hypervisors too, haven't checked that though.
Cheers,
-- Guido
[PATCH] qemudDomainCreate: check if domain is already active
otherwise we overwrite a running domain which lets libvirtd disconnect
from the running qemu.
---
src/qemu_driver.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index b84bdf4..0ad72ae 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -1978,6 +1978,15 @@ static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,
if (!(def = virDomainDefParseString(conn, driver->caps, xml)))
return NULL;
+vm = virDomainFindByName(driver->domains, def->name);
+if (vm && virDomainIsActive(vm)) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
+ _("domain %s is already defined and running"),
+ def->name);
+virDomainDefFree(def);
+return NULL;
+}
+
if (!(vm = virDomainAssignDef(conn,
&driver->domains,
def))) {
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Jul 24, 2008 at 10:01:32AM +0100, Daniel P. Berrange wrote:
> > diff --git a/src/qemu_driver.c b/src/qemu_driver.c
> > index b84bdf4..0ad72ae 100644
> > --- a/src/qemu_driver.c
> > +++ b/src/qemu_driver.c
> > @@ -1978,6 +1978,15 @@ static virDomainPtr qemudDomainCreate(virConnectPtr
> > conn, const char *xml,
> > if (!(def = virDomainDefParseString(conn, driver->caps, xml)))
> > return NULL;
> >
> > +vm = virDomainFindByName(driver->domains, def->name);
>
> You need to check for UUID clash too.
Indeed. But before fixing this I wonder what the exact semantics of
domainCreateLinux are. Is it correct that we don't call
virDomainSaveConfiguration?
If so we probably don't even need to check if the domain is running. The
mere existance of a domain with the same name/uuid should probably throw
an error already since having another domain by the same name/uuid known
to libvirt already can be a source of confusion for the user.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Jul 24, 2008 at 04:12:05PM +0100, Daniel P. Berrange wrote:
> On Thu, Jul 24, 2008 at 10:41:31AM -0400, Guido G?nther wrote:
> > On Thu, Jul 24, 2008 at 10:01:32AM +0100, Daniel P. Berrange wrote:
[..snip..]
> > > You need to check for UUID clash too.
> > Indeed. But before fixing this I wonder what the exact semantics of
> > domainCreateLinux are. Is it correct that we don't call
> > virDomainSaveConfiguration?
>
> Yes, that is correct.
>
> virDomainCreateLinux() starts a virtual machine with no config file. All
> trace of it will disappear when it shuts down - a so called 'transient'
> VM.
>
> Alternatively you can define the config first with virDomainDefineXML()
> and then start it based on this definition with virDomainCreate(). This
> gives you a persistent VM.
>
> Now, while a transient VM is running you can explicitly give it a config
> file by called virDomainDefineXML with the same uuid, thus turning it in
> to a persistent VM.
The attache patch also checks the uuid.
-- Guido
---
src/qemu_driver.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 4a0c06c..8015b63 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -63,6 +63,7 @@
#include "stats_linux.h"
#include "capabilities.h"
#include "memory.h"
+#include "uuid.h"
/* For storing short-lived temporary files. */
#define TEMPDIR LOCAL_STATE_DIR "/cache/libvirt"
@@ -2009,11 +2010,22 @@ static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,
vm = virDomainFindByName(driver->domains, def->name);
if (vm && virDomainIsActive(vm)) {
qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
- _("domain %s is already defined and running"),
+ _("domain '%s' is already defined and running"),
def->name);
virDomainDefFree(def);
return NULL;
}
+vm = virDomainFindByUUID(driver->domains, def->uuid);
+if (vm && virDomainIsActive(vm)) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+
+virUUIDFormat(def->uuid, uuidstr);
+qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
+ _("domain with uuid '%s' is already defined and running"),
+ uuidstr);
+virDomainDefFree(def);
+return NULL;
+}
if (!(vm = virDomainAssignDef(conn,
&driver->domains,
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
while reading through that I noticed libvirt.h is quiet xen centric.
Purely cosmetic patch attached,
-- Guido
---
include/libvirt/libvirt.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h
index 8980bc2..9c3e1c2 100644
--- a/include/libvirt/libvirt.h
+++ b/include/libvirt/libvirt.h
@@ -2,7 +2,7 @@
* libvirt.h:
* Summary: core interfaces for the libvirt library
* Description: Provides the interfaces of the libvirt library to handle
- * Xen domains from a process running in domain 0
+ * virtualized domains
*
* Copy: Copyright (C) 2005,2006 Red Hat, Inc.
*
@@ -33,7 +33,7 @@ extern "C" {
* virConnect:
*
* a virConnect is a private structure representing a connection to
- * the Xen Hypervisor.
+ * the Hypervisor.
*/
typedef struct _virConnect virConnect;
@@ -41,14 +41,14 @@ typedef struct _virConnect virConnect;
* virConnectPtr:
*
* a virConnectPtr is pointer to a virConnect private structure, this is the
- * type used to reference a connection to the Xen Hypervisor in the API.
+ * type used to reference a connection to the Hypervisor in the API.
*/
typedef virConnect *virConnectPtr;
/**
* virDomain:
*
- * a virDomain is a private structure representing a Xen domain.
+ * a virDomain is a private structure representing a domain.
*/
typedef struct _virDomain virDomain;
@@ -56,7 +56,7 @@ typedef struct _virDomain virDomain;
* virDomainPtr:
*
* a virDomainPtr is pointer to a virDomain private structure, this is the
- * type used to reference a Xen domain in the API.
+ * type used to reference a domain in the API.
*/
typedef virDomain *virDomainPtr;
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Jul 25, 2008 at 05:02:43AM -0400, Daniel Veillard wrote:
> On Fri, Jul 25, 2008 at 09:29:43AM +0100, Daniel P. Berrange wrote:
> > On Thu, Jul 24, 2008 at 03:52:32PM -0400, Guido G?nther wrote:
> > > Hi,
> > > qemu_driver misses some conversions to a char* before printing the uuid.
> > > Possible fix attached.
> >
> > ACK, surprised that the printf() format checks don't complain about
> > passing an unsigned char to a %s format in GCC. This is actually
> > one of the things ICC flagged when i tried it, but I never fixed it
>
> Applied, i just had to add an include for uuid.h to avoid an undeclared
> function warning :-)
The hunk including uuid.h accidently endet up in
0001-also-check-domain-uuid-on-create.patch, sorry about that.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Jul 25, 2008 at 11:46:48AM -0400, Daniel Veillard wrote:
> On Fri, Jul 25, 2008 at 09:56:27AM -0400, Guido Günther wrote:
> > On Fri, Jul 25, 2008 at 05:02:43AM -0400, Daniel Veillard wrote:
> > > On Fri, Jul 25, 2008 at 09:29:43AM +0100, Daniel P. Berrange wrote:
> > > > On Thu, Jul 24, 2008 at 03:52:32PM -0400, Guido G?nther wrote:
> > > > > Hi,
> > > > > qemu_driver misses some conversions to a char* before printing the
> > > > > uuid.
> > > > > Possible fix attached.
> > > >
> > > > ACK, surprised that the printf() format checks don't complain about
> > > > passing an unsigned char to a %s format in GCC. This is actually
> > > > one of the things ICC flagged when i tried it, but I never fixed it
> > >
> > > Applied, i just had to add an include for uuid.h to avoid an undeclared
> > > function warning :-)
> > The hunk including uuid.h accidently endet up in
> > 0001-also-check-domain-uuid-on-create.patch, sorry about that.
>
> Hum, i don't find it. Can you regenerate/repost please ?
Attached. It also dropped the check if the domain is running or not,
since a transient domain with of a currently offline domain is just to
confusing.
-- Guido
[PATCH] also check domain uuid on create
and don't care if domain is active or not - it confuses users both ways
---
src/qemu_driver.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 81bde4e..3c04e09 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2013,13 +2013,24 @@ static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,
return NULL;
vm = virDomainFindByName(driver->domains, def->name);
-if (vm && virDomainIsActive(vm)) {
+if (vm) {
qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
- _("domain %s is already defined and running"),
+ _("domain '%s' is already defined and running"),
def->name);
virDomainDefFree(def);
return NULL;
}
+vm = virDomainFindByUUID(driver->domains, def->uuid);
+if (vm) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+
+virUUIDFormat(def->uuid, uuidstr);
+qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
+ _("domain with uuid '%s' is already defined and running"),
+ uuidstr);
+virDomainDefFree(def);
+return NULL;
+}
if (!(vm = virDomainAssignDef(conn,
&driver->domains,
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
actually I thought I sent this out already, but it seems I didn't:
Don't dump core on NULL ifname when getting interface statistic.
Not all networking types have a target ifname set
(user,client,server,mcast).
Cheers,
-- Guido
[PATCH] don't dump core on NULL ifname
not all networking types have a target ifname set
(user,client,server,mcast)
---
src/qemu_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index b8fd11c..9d661d2 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -3242,7 +3242,7 @@ qemudDomainInterfaceStats (virDomainPtr dom,
/* Check the path is one of the domain's network interfaces. */
for (net = vm->def->nets; net; net = net->next) {
-if (STREQ (net->ifname, path))
+if (net->ifname && STREQ (net->ifname, path))
goto ok;
}
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi Daniel,
On Mon, Jul 28, 2008 at 09:26:57AM -0400, Daniel Veillard wrote:
> On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido Günther wrote:
> > Hi,
> > attached is some basic support for host device passthrough. It enables
> > you to passthrough usb devices in qemu/kvm via:
> >
> >
> >
>
> you meant type='pci' there right ?
Qemu support host:bus.device syntax for usb devices (useful for the case
of two identical devices). PCI can work like this too of course.
> >
> >
>
> Hum, on the format level I think this need a bit more discussion.
> the type is better caracterized as a bus informations.
> Also I'm not sure if we should keep a flat single element or
> (expecting possible further complex descriptions later) go for a
> more structured description like
>
>
>
>
I think this looks better. Actually I thought so already after sending
the patch.
> I think an hypervisor could remap the actual port/addresses
> of a device so a target may make sense in the future (or not).
Hopefully it does. It would be nice if we could do that since we'd then
have the necessary data for easy unmapping.
> > I didn't implement unplug yet since this needs some modifications to
> > qemu/kvm to be able to identify the correct device to unplug.
> > Does this look reasonable?
>
> I also think we need to clarify the naming conventions, are numbers
> provided decimal, if yes then is an 0x hexadecimal version allowed too.
Currently they're all hex as outputet by lsusb.
[..snip..]
> From an implementation perspective, the patch looks very clean to me
> aside maybe some Hostdev type vs. Bus naming for the enum, but maybe we need
> to give a bit more thoughs one the format first :-)
Sure. I'll see what I can come up with. Thanks for the comments.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido Günther wrote:
> attached is some basic support for host device passthrough. It enables
> you to passthrough usb devices in qemu/kvm via:
On top of the hostdev passthrough (but it's actually totally
independent) I added usb massstorage backed by a file. Very handy for
installer testing where the preseed data is on the USB stick and the
CD/DVD is the installation medium.
At the moment I'm using a dummy target "usbdisk" so we don't have to
check for target == NULL in that many places. Once qemu handles it we
can fill in bus and device address for unplugging. To add a file as usb
massstorage to the guest you can use:
Does this make sense?
-- Guido
---
src/domain_conf.c | 40
src/domain_conf.h |1 +
src/qemu_conf.c | 23 +--
src/qemu_driver.c | 41 +
4 files changed, 91 insertions(+), 14 deletions(-)
diff --git a/src/domain_conf.c b/src/domain_conf.c
index d36caeb..74ceecc 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -84,7 +84,8 @@ VIR_ENUM_IMPL(virDomainDiskBus, VIR_DOMAIN_DISK_BUS_LAST,
"fdc",
"scsi",
"virtio",
- "xen")
+ "xen",
+ "usb")
VIR_ENUM_IMPL(virDomainNet, VIR_DOMAIN_NET_TYPE_LAST,
"user",
@@ -540,6 +541,14 @@ virDomainDiskDefParseXML(virConnectPtr conn,
def->device = VIR_DOMAIN_DISK_DEVICE_DISK;
}
+if (bus) {
+if ((def->bus = virDomainDiskBusTypeFromString(bus)) < 0) {
+virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _("unknown disk bus type '%s'"), bus);
+goto error;
+}
+}
+
/* Only CDROM and Floppy devices are allowed missing source path
* to indicate no media present */
if (source == NULL &&
@@ -550,10 +559,16 @@ virDomainDiskDefParseXML(virConnectPtr conn,
goto error;
}
+/* only USB devices are allowed missing target path since the hypervisor
+ * can assign bus and device number */
if (target == NULL) {
-virDomainReportError(conn, VIR_ERR_NO_TARGET,
- source ? "%s" : NULL, source);
-goto error;
+if (def->bus == VIR_DOMAIN_DISK_BUS_USB) {
+ target = strdup("usbdisk");
+ } else {
+virDomainReportError(conn, VIR_ERR_NO_TARGET,
+ source ? "%s" : NULL, source);
+goto error;
+}
}
if (def->device == VIR_DOMAIN_DISK_DEVICE_FLOPPY &&
@@ -571,19 +586,14 @@ virDomainDiskDefParseXML(virConnectPtr conn,
!STRPREFIX((const char *)target, "hd") &&
!STRPREFIX((const char *)target, "sd") &&
!STRPREFIX((const char *)target, "vd") &&
-!STRPREFIX((const char *)target, "xvd")) {
+!STRPREFIX((const char *)target, "xvd") &&
+!STREQ((const char*)target, "usbdisk")) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_("Invalid harddisk device name: %s"), target);
goto error;
}
-if (bus) {
-if ((def->bus = virDomainDiskBusTypeFromString(bus)) < 0) {
-virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
- _("unknown disk bus type '%s'"), bus);
-goto error;
-}
-} else {
+if (!bus) {
if (def->device == VIR_DOMAIN_DISK_DEVICE_FLOPPY) {
def->bus = VIR_DOMAIN_DISK_BUS_FDC;
} else {
@@ -612,6 +622,12 @@ virDomainDiskDefParseXML(virConnectPtr conn,
_("Invalid bus type '%s' for disk"), bus);
goto error;
}
+if (def->device != VIR_DOMAIN_DISK_DEVICE_DISK &&
+def->bus == VIR_DOMAIN_DISK_BUS_USB) {
+virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _("Invalid bus type '%s' for usb disk"), bus);
+goto error;
+}
def->src = source;
source = NULL;
diff --git a/src/domain_conf.h b/src/domain_conf.h
index 1aa5c39..a9c237e 100644
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -72,6 +72,7 @@ enum virDomainDiskBus {
VIR_DOMAIN_DISK_BUS_SCSI,
VIR_DOMAIN_DISK_BUS_VIRTIO,
VIR_DOMAIN_DISK_BUS_XEN,
+VIR_DOMAIN_DISK_BUS_USB,
VIR_DOMAIN_DISK_BUS_LAST
};
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index 7678ac5..868b3dc 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -55,7 +55,8 @@ VIR_ENUM_IMPL(virDomainDiskQEMUBus, VIR_DOMAIN_DISK_BUS_LAST,
On Wed, Jul 30, 2008 at 09:47:00AM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 28, 2008 at 11:02:45AM -0400, Guido G?nther wrote:
> > On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido Günther wrote:
> > > attached is some basic support for host device passthrough. It enables
> > > you to passthrough usb devices in qemu/kvm via:
> > On top of the hostdev passthrough (but it's actually totally
> > independent) I added usb massstorage backed by a file. Very handy for
> > installer testing where the preseed data is on the USB stick and the
> > CD/DVD is the installation medium.
> > At the moment I'm using a dummy target "usbdisk" so we don't have to
> > check for target == NULL in that many places. Once qemu handles it we
> > can fill in bus and device address for unplugging. To add a file as usb
> > massstorage to the guest you can use:
> >
> >
> >
> >
> >
>
> The way we do target for other disk types doesn't work so well - others
> we typically have a device name, eg hda, sdc, xvdf, etc. For VirtIO we
> let people pass in a dummy device name too 'vda', 'vdb', etc. Only some
> of the disk buses & guest OS honour these names though - in cases where
> they're not honoured, they at most provide a unique key, and allow for
> ordering of disks in our XML. USB will be much like SCSI / VirtIO where
> the device name in the XML is merely used for ordering, so we should just
> allow sda, sdb, etc as the target device name. This will avoid having
> to special case the code in the here too much.
Acutally I intended to use the target like target="bus:device" once qemu
(and others) support this. The would also help on detach. Would you
prefer:
then?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Jul 30, 2008 at 12:05:56AM -0500, Charles Duffy wrote:
> It appears that this patch was applied (in commit
> 45616162db2d1e807dbe70e60c67cb701cbd06d8) with the virDomainIsActive(vm)
> checks removed from qemudDomainCreate, such that we fail out with
> "domain [...] is already defined and running" even if the domain is only
> defined but not running.
The error message is confusing. I missed to correct that. Shall I send a
patch? I thing doing more than that is simply too confusing for users.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Aug 04, 2008 at 10:34:31AM +0100, Daniel P. Berrange wrote:
> On Sun, Aug 03, 2008 at 01:41:28AM +0200, Guido G?nther wrote:
> > Hi,
> > attached is a second version. Changes are:
> >
> > * s/bus/subsystem/
> > * support hexadecimal and decimal attributes
> > * introduce device and source elements.
> >
> > I decided to not drop vendor and product id into their own elements
> > since the structure would then become very nested for no good reason.
>
> The reason is that I want it to match the host device enumeration
> XML format. This will be using explicit and
> tags, with an 'id' attribute, because there will be text content
> in the body giving the human readable name.
Ahh...o.k.
>
> > Some examples:
> >
> >
> >
> >
>
> So this needs to be changed to
>
>
>
Sure.
> Ok, that's not critical, but the other things we need before we
> can commit this are
>
> - Code to format XML for output, so that the devices are included when
> dumping the XML description of a guest.
> - Update to the RNG schema in docs/libvirt.rng
> - Example XML data files in tests/qemuxml2argvdata/, along with the
>corresponding CLI args for QEMU. THis is then hooked into the
>qemuxml2argvtest.c and qemuxml2xmltest.c files
Sure. I delayed those since they'd have to be adjusted when the XML
changes, I'll add them now and do the other minor touchups you
suggested...might be a couple of days though.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Aug 04, 2008 at 09:05:07AM -0400, Bryan Kearney wrote:
> I added the following to my xml
>
>
>
>
>
>
>
> and had acpi=force on my kernel line.. still no luck. I looked for bugs
> in bugzilla.redhat... saw none for kvm with acpi. Is there another to
> bug tool to look at?
You can check if the acpi interrupt got dilivered in /proc/interrupts.
If so your OS doesn't handle it (e.g. missing acpi tools), if it didn't
get delivered there's probably something broken with kvm.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
attached patch lets the domainschema check work when building in $build
instead of $src. Otherwise it won't find the xml files to validate.
-- Guido
>From e2a19f1e14ef6712626a1b1b06b62cedf032495e Mon Sep 17 00:00:00 2001
From: Guido Guenther <[EMAIL PROTECTED]>
Date: Thu, 7 Aug 2008 16:12:43 +0200
Subject: [PATCH] fix path to xml files
---
tests/domainschematest |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/domainschematest b/tests/domainschematest
index e410cdc..7ebcefc 100755
--- a/tests/domainschematest
+++ b/tests/domainschematest
@@ -8,7 +8,7 @@ n=0
f=0
for dir in $DOMAINDIRS
do
- XML=`find $dir -name '*.xml'`
+ XML=`find $abs_srcdir/$dir -name '*.xml'`
for xml in $XML
do
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
On Fri, Aug 08, 2008 at 10:34:00AM -0400, Daniel Veillard wrote:
[..snip..]
> I think the only thing missing is extending the descrition in the
> documentation
> would you mind adding a description in formatdomain.html(.in)
> Probably an "USB devices" section added below the elementsDisks part,
> explaining the syntaxes and stating that it was added in versions after 0.4.4
>
> If you don't feel comfortable with that I can do it, but you know better :)
Attached is a short patch for this. This might be a bit terse but we'll
have to change this anyhow once pci passthrough for xen arrives.
Cheers,
-- Guido
>From 3a962e2f7a326e4dc8c27f37d7d206f6a6bf0530 Mon Sep 17 00:00:00 2001
From: Guido Guenther <[EMAIL PROTECTED]>
Date: Fri, 8 Aug 2008 17:41:17 +0200
Subject: [PATCH] usb doc update
---
docs/formatdomain.html.in | 49 +---
1 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index d4f650e..1f02727 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -362,10 +362,11 @@
the device name in the guest OS. Treat it 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". 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
+ "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.
+ Since 0.0.3; bus attribute since 0.4.3;
+"usb" attribute value since after 0.4.4
driver
If the hypervisor supports multiple backend drivers, then the optional
driver element allows them to be selected. The name
@@ -374,6 +375,46 @@
+USB devices
+
+
+ USB devices attached to the host can be passed through to the guest using
+ the hostdev element. since after 0.4.4
+
+
+
+ ...
+
+
+
+
+
+
+ ...
+
+
+ hostdev
+ The hostdev element is the main container for describing
+ host devices. For usb device passthrough mode is always
+ "subsystem" and type is "usb".
+ source
+ The source element describes the device as seen from the host.
+ The USB device can either be addressed by vendor / product id using the
+ vendor and product elements or by the device's
+ address on the hosts using the address element.
+ vendor, product
+ The vendor and product elements each have an
+ id attribute that specifies the USB vendor and product id.
+ The ids can be given in decimal, hexadecimal (starting with 0x) or
+ ocatal (starting with 0) form.
+ address
+ The address element has a bus and
+ device attribute to specify the USB bus and device number
+ the device appears at on the host. The values of these attributes can
+ be given in decimal, hexadecimal (starting with 0x) or ocatal (starting
+ with 0) form.
+
+
Network interfaces
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Aug 08, 2008 at 06:30:56PM +0200, Jim Meyering wrote:
> Guido Guenther <[EMAIL PROTECTED]> wrote:
> > ...not the one in $PATH. I was wondering why this test kept failing...
>
> You shouldn't need that change, since "make check" already sets PATH
> so that $abs_top_builddir/qemud is early in PATH. And it does it
> in such a way that it should work even if the absolute path
> contains shell meta-characters.
I ran:
cd tests/
make check
and that particular check failed. I figure this isn't supported then?
It works for all other tests and it works for daemon-conf with the patch
I attached so it should probably be applied to make things a bit more
newbie robust?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Sat, Aug 09, 2008 at 09:56:45AM +0100, Richard W.M. Jones wrote:
[..snip..]
> Dan/Dan, any reason we can't 'mkdir' this when libvirtd starts up?
Shoulnd't this better be handled in the distros init script?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Aug 08, 2008 at 06:57:19PM +0200, Jim Meyering wrote:
> Can you debug it?
> E.g., echo "$PATH" from within the script and figure
> out why it doesn't include $$abs_top_builddir/qemud.
It suddenly doesn't fail here anymore, no idea what happened. I'll
report back once I'm able to break it again.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi Mark,
On Wed, Aug 13, 2008 at 06:44:28PM +0100, Mark McLoughlin wrote:
> With e.g.:
>
>
>
>
>
>
>
> You currently get:
>
> Unknown option: listen
> qemu: could not open serial device 'telnet:127.0.0.1:,listen'
>
> With the telnet protocol, qemu expects "server" as an option
> rather than "listen".
Not that I'm qualified to comment on this but a testcase in
tests/qemuxml2argv* would prevent breaking this in the future.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Aug 22, 2008 at 07:26:12PM +0200, Jim Meyering wrote:
[..snip..]
> I've just checked up to date rawhide and debian unstable systems.
> Both had this:
>
> $ grep KVM_CHECK_EXTENSION /usr/include/linux/kvm.h
> #define KVM_CHECK_EXTENSION _IO(KVMIO, 0x03)
>
> But rawhide lacks KVM_CAP_NR_VCPUS, while Debian has it.
>
> $ grep -r KVM_CAP_NR_VCPUS /usr/include/linux/kvm.h
> #define KVM_CAP_NR_VCPUS 9 /* returns max vcpus per vm */
Debian has it only in unstable not in testing. That's why I added the
header check as well as the "#if defined(KVM_CAP_NR_VCPUS)" - the code
stays as is for old header files and uses the definition (and therefore
the ioctl) if available.
Rawhide will get the defintion with the next libc header update I guess.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Sun, Aug 24, 2008 at 01:33:34AM +0200, Stefan de Konink wrote:
> With the tip of DanB I am currently using the inactive XML storage quite
> satisfied with the concept of first undefining than starting. But there
> is still a bug.
>
> The inactive XML adds a tag. Now that is (in my
> perspective) not a bug, but it it is that libvirt expects a config. In
> my personal believes the tag shouldn't be there if there is no config;
> or libvirt should not
I think is similar to what I reported in February:
http://www.redhat.com/archives/libvir-list/2008-February/msg00097.html
There's a patch attached that works around the issue but I doubt it
still applies.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
On Fri, Aug 22, 2008 at 02:27:58PM +0100, Daniel P. Berrange wrote:
> On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
> > Hi,
> > with recent linux kernels we can detect the maximum number of virtual
> > cpus at runtime via an ioctl. Possible patch attached. It does this on
> > every call to qemudGetMaxVCPUs. Would you prefer something that does
> > this only once in qemudStartup()?
> > Cheers,
> > -- Guido
>
> >
> > +dnl
> > +dnl check for kvm headers
> > +dnl
> > +AC_CHECK_HEADERS([linux/kvm.h])
>
> Hmm, I wonder if that's commonly installed by Fedora/Debian RPMs
> for KVM
>
> It might be neccessary to just #define the IOCTL constant in
> our own header files if its not available.
Attached patch adds the missing definitions via qemu_driver.h which
seemed close enough to KVM and isn't a public header. This way all
#ifdefs' moved out of qemu_driver.c.
-- Guido
>From 0da5b6ba3279d80be13b50ba456d2a4e434da7b8 Mon Sep 17 00:00:00 2001
From: Guido Guenther <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 14:47:49 +0200
Subject: [PATCH] for kvm determine maxVCPUs at runtime
---
configure.in |5 +
src/qemu_driver.c | 24 +++-
src/qemu_driver.h | 18 ++
3 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/configure.in b/configure.in
index 430a097..dfb38ea 100644
--- a/configure.in
+++ b/configure.in
@@ -314,6 +314,11 @@ if test "$with_qemu" = "yes" -o "$with_lxc" = "yes" ; then
AC_MSG_ERROR([You must install kernel-headers in order to compile libvirt]))
fi
+dnl
+dnl check for kvm headers
+dnl
+AC_CHECK_HEADERS([linux/kvm.h])
+
dnl Need to test if pkg-config exists
PKG_PROG_PKG_CONFIG
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index eb4454a..482d988 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#if HAVE_NUMACTL
#include
@@ -1790,6 +1791,27 @@ static const char *qemudGetType(virConnectPtr conn ATTRIBUTE_UNUSED) {
return "QEMU";
}
+
+static int kvmGetMaxVCPUs(void) {
+int maxvcpus = 1;
+
+int r, fd;
+
+fd = open(KVM_DEVICE, O_RDONLY);
+if (fd < 0) {
+qemudLog(QEMUD_WARN, _("Unable to open " KVM_DEVICE ": %s\n"), strerror(errno));
+return maxvcpus;
+}
+
+r = ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS);
+if (r > 0)
+maxvcpus = r;
+
+close(fd);
+return maxvcpus;
+}
+
+
static int qemudGetMaxVCPUs(virConnectPtr conn, const char *type) {
if (!type)
return 16;
@@ -1800,7 +1822,7 @@ static int qemudGetMaxVCPUs(virConnectPtr conn, const char *type) {
/* XXX future KVM will support SMP. Need to probe
kernel to figure out KVM module version i guess */
if (STRCASEEQ(type, "kvm"))
-return 1;
+return kvmGetMaxVCPUs();
if (STRCASEEQ(type, "kqemu"))
return 1;
diff --git a/src/qemu_driver.h b/src/qemu_driver.h
index dbcca70..e0662e0 100644
--- a/src/qemu_driver.h
+++ b/src/qemu_driver.h
@@ -29,6 +29,24 @@
#include "internal.h"
+#if HAVE_LINUX_KVM_H
+#include
+#endif
+
+/* device for kvm ioctls */
+#define KVM_DEVICE "/dev/kvm"
+
+/* add definitions missing in older linux/kvm.h */
+#ifndef KVMIO
+# define KVMIO 0xAE
+#endif
+#ifndef KVM_CHECK_EXTENSION
+# define KVM_CHECK_EXTENSION _IO(KVMIO, 0x03)
+#endif
+#ifndef KVM_CAP_NR_VCPUS
+# define KVM_CAP_NR_VCPUS 9 /* returns max vcpus per vm */
+#endif
+
int qemudRegister(void);
#endif /* QEMUD_DRIVER_H */
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Guido Günther wrote:
> Hi,
> On Fri, Aug 22, 2008 at 02:27:58PM +0100, Daniel P. Berrange wrote:
>> On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
>> > Hi,
>> > with recent linux kernels we can detect the maximum number of virtual
>> > cpus at runtime via an ioctl. Possible patch attached. It does this on
>> > every call to qemudGetMaxVCPUs. Would you prefer something that does
>> > this only once in qemudStartup()?
Any comments on this one? Or is this too obviously broken?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Sep 05, 2008 at 12:23:36PM -0400, Cole Robinson wrote:
[..snip..]
> FYI, I'm about to post a patch that builds on this
> to offer max vcpu checking based on the kvm version
> which is parsed from the help message. Should also
> help providing useful values for older kernels and
> kvm versions.
This is difficult since different architectures gained vcpu support in
different stages but even limited to i386/amd64 this is useful. We
should try the ioctal first in any case I think.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Sep 01, 2008 at 12:02:31PM +0200, Chris Lalancette wrote:
> Atsushi SAKAI wrote:
> > Hi,
> >
> > I have a question about migration on KVM/Qemu.
> >>From src/qemu_driver.c, domainMigrateX is not defined.
> >
> > But from news on 0.3.2, KVM migration is supported.
> > http://libvirt.org/news.html
> >
> > Where is the code which performs migration on KVM/Qemu.
>
> Hm, that's a little odd. As far as I know, KVM migration isn't supported yet.
Well there's suspend/resume suport for kvm which can be used to migrate
to another machine. It's not live and it's not what the migrate command
does but maybe that's what got added to 0.3.2?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido Günther wrote:
> Hi,
> with recent linux kernels we can detect the maximum number of virtual
> cpus at runtime via an ioctl. Possible patch attached. It does this on
> every call to qemudGetMaxVCPUs. Would you prefer something that does
> this only once in qemudStartup()?
This patch is still outstanding. Anything I can help to push this?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Sep 17, 2008 at 02:11:46PM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 17, 2008 at 01:38:49PM +0200, Guido Günther wrote:
> > On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido Günther wrote:
> > > Hi,
> > > with recent linux kernels we can detect the maximum number of virtual
> > > cpus at runtime via an ioctl. Possible patch attached. It does this on
> > > every call to qemudGetMaxVCPUs. Would you prefer something that does
> > > this only once in qemudStartup()?
> > This patch is still outstanding. Anything I can help to push this?
>
> Can you point me to the latest version?
Attached.
-- Guido
>From 0da5b6ba3279d80be13b50ba456d2a4e434da7b8 Mon Sep 17 00:00:00 2001
From: Guido Guenther <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 14:47:49 +0200
Subject: [PATCH] for kvm determine maxVCPUs at runtime
---
configure.in |5 +
src/qemu_driver.c | 24 +++-
src/qemu_driver.h | 18 ++
3 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/configure.in b/configure.in
index 430a097..dfb38ea 100644
--- a/configure.in
+++ b/configure.in
@@ -314,6 +314,11 @@ if test "$with_qemu" = "yes" -o "$with_lxc" = "yes" ; then
AC_MSG_ERROR([You must install kernel-headers in order to compile libvirt]))
fi
+dnl
+dnl check for kvm headers
+dnl
+AC_CHECK_HEADERS([linux/kvm.h])
+
dnl Need to test if pkg-config exists
PKG_PROG_PKG_CONFIG
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index eb4454a..482d988 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#if HAVE_NUMACTL
#include
@@ -1790,6 +1791,27 @@ static const char *qemudGetType(virConnectPtr conn ATTRIBUTE_UNUSED) {
return "QEMU";
}
+
+static int kvmGetMaxVCPUs(void) {
+int maxvcpus = 1;
+
+int r, fd;
+
+fd = open(KVM_DEVICE, O_RDONLY);
+if (fd < 0) {
+qemudLog(QEMUD_WARN, _("Unable to open " KVM_DEVICE ": %s\n"), strerror(errno));
+return maxvcpus;
+}
+
+r = ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS);
+if (r > 0)
+maxvcpus = r;
+
+close(fd);
+return maxvcpus;
+}
+
+
static int qemudGetMaxVCPUs(virConnectPtr conn, const char *type) {
if (!type)
return 16;
@@ -1800,7 +1822,7 @@ static int qemudGetMaxVCPUs(virConnectPtr conn, const char *type) {
/* XXX future KVM will support SMP. Need to probe
kernel to figure out KVM module version i guess */
if (STRCASEEQ(type, "kvm"))
-return 1;
+return kvmGetMaxVCPUs();
if (STRCASEEQ(type, "kqemu"))
return 1;
diff --git a/src/qemu_driver.h b/src/qemu_driver.h
index dbcca70..e0662e0 100644
--- a/src/qemu_driver.h
+++ b/src/qemu_driver.h
@@ -29,6 +29,24 @@
#include "internal.h"
+#if HAVE_LINUX_KVM_H
+#include
+#endif
+
+/* device for kvm ioctls */
+#define KVM_DEVICE "/dev/kvm"
+
+/* add definitions missing in older linux/kvm.h */
+#ifndef KVMIO
+# define KVMIO 0xAE
+#endif
+#ifndef KVM_CHECK_EXTENSION
+# define KVM_CHECK_EXTENSION _IO(KVMIO, 0x03)
+#endif
+#ifndef KVM_CAP_NR_VCPUS
+# define KVM_CAP_NR_VCPUS 9 /* returns max vcpus per vm */
+#endif
+
int qemudRegister(void);
#endif /* QEMUD_DRIVER_H */
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
we print an error message on OOM conditions in qemudStartup() at the end
of the function, no need to do it differently in one place.
Cheers,
-- Guido
[PATCH] handle OOM as everywhere else
---
src/qemu_driver.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index b003b00..b5ba723 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -208,11 +208,8 @@ qemudStartup(void) {
"%s/.libvirt/qemu/log", pw->pw_dir) == -1)
goto out_of_memory;
-if (asprintf (&base, "%s/.libvirt", pw->pw_dir) == -1) {
-qemudLog (QEMUD_ERR,
- "%s", _("out of memory in asprintf\n"));
+if (asprintf (&base, "%s/.libvirt", pw->pw_dir) == -1)
goto out_of_memory;
-}
}
/* Configuration paths are either ~/.libvirt/qemu/... (session) or
--
1.5.6.5
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 07, 2008 at 03:03:10PM -0400, Cole Robinson wrote:
> Guido Günther wrote:
> > On Thu, Oct 02, 2008 at 09:06:25PM +0100, Daniel P. Berrange wrote:
> >> I think this needs to use the virDiskNameToIndex() method to
> >> extract the index instead.
> > Corrected pach attached. I don't know how devices are called when using
> > xenner so I left that out.
> > -- Guido
> >
> >
>
> There is actually a function in qemu_driver.c called
> qemudDiskDeviceName that handles a lot of this already,
> it's used for generating the connect/eject cdrom names.
> It's probably best to reuse that.
Yes this makes sense. After fixing things up a little in
virDiskNameToBusDeviceIndex and qemudDiskDeviceName this works. I'll
post this as 3 tiny patches since they might be helpful on their own and
can be applied in case there's still something wrong with the
blockstats.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 07, 2008 at 05:37:52PM +0100, Daniel P. Berrange wrote:
[..snip..]
> This also needs to be implemented with the assumption that the daemon
> can & will crash any time. So putting the state-saving hooks into the
> qemudShutdown() method won't be sufficient. We need to write out the
> state we need when initially starting the VM, and then update it any
> time we hot-plug/unplug devices.
This was actually the first way I looked at this but decided to do it
the other way around since it saves us from updating the live config all
the time. But if we consider libvirtd crashable it's indeed better
to go this way. I'll come up with a different patch, might be a couple
of days before I get around to it though.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Oct 15, 2008 at 09:59:12PM +0100, Daniel P. Berrange wrote:
> When you get to that level of cleverness, it seems to me that it is verging
> on a complete re-implementation of DLM (distributed lock manager), which
> really, AFAIK, needs a proper cluster setup so it can safely fence
> mis-behaving nodes, and avoid quorum/split-brain problems.
I've been toying with the idea of using DLM for libvirt earlier this
year [1](but infered from other postings on the list that this would be out
of scope for libvirt - probably should have asked). I looked at vm based
locks then but having storage based locks is even better.
Currently you have to make sure "manually" that people using i.e.
virt-manager[2] don't accidentally fire up VMs managed via e.g.
rgmanager.
Having cluster wide storage based locks would be an awesome solution.
-- Guido
[1] using the rather simple lock_resource() and unlock_resource() API:
http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=blob;f=dlm/doc/libdlm.txt
[2] i.e. by having virt-manager hooked to all libvirtds in the cluster
and allowing to start each uuid only once
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 14, 2008 at 09:29:38AM -0400, Cole Robinson wrote:
> Guido Günther wrote:
> > On Fri, Oct 10, 2008 at 06:05:37PM +0100, Daniel P. Berrange wrote:
> >> Sorry to mess up your patch, but I just committed the code to turn
> >> all linked lists into arrays. So you'll need to tweak this to do
> >>
> >> for (i = 0 ; i < vm->def->ndisks ; i++)
> >> if (STREQ(vm->def->disks[i]->dst))
> >> break;
> > Fixed version attached. This one also addresses Cole's comment on the
> > error message.
> > -- Guido
> >
>
> ACK.
So can the be applied (together with the other two fixups)?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 21, 2008 at 02:42:40PM +0100, Daniel P. Berrange wrote:
[..snip..]
> Is there not some 'info pci' or 'info disk' command we cna use to find
> out the PCI slot number at the time we want to detach the device. This
> would make it work for all disks, and avoid the need to track the
> state in that virDomainDiskDef union
I don't like restricting this to hot added disks either but for one this
will probably be a very common suitation and more important qemu just
doesn't give enough information to do this reliably.
The only really reliable way would (at least I think) be for the user
(in this case libvirt) to pass a token to qemu (with -drive and with
pci_add). We should then be able to detach using this token. Something
else will always be dependent on what hardware qemu currently emulates.
This would need to be implemented in qemu for usb and pci.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi Daniel,
On Tue, Oct 21, 2008 at 03:25:25PM +0200, Daniel Veillard wrote:
> Those are just stylistic issues, I can apply the patch with those
> changed if you wish if you don't have time for a new patch,
I'll come up with a corrected version, no problem.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 21, 2008 at 03:09:48PM +0200, Daniel Veillard wrote:
> On Fri, Oct 17, 2008 at 12:44:13PM +0200, Guido Günther wrote:
> > Hi,
> > this just brings qemudDomainAttachUsbMassstorageDevice in line with the
> > rest of the code:
> >
> > * don't allow to add the same target device name more than once
> > * escape paths for qemu's monitor command
>
> Good idea ! Applied and commited,
Would it make sense to push the check for duplicate device names further
up in the long term?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 21, 2008 at 12:16:01PM -0700, Itamar Heim wrote:
> While this might work for SBC (although most enterprises have the
> datacenter on remote sites as well, so not always that easy). I don't
> think the solution is viable for CBC though (I am not sure CBC would
> use iSCSI, probably NFS is a more relevant option, but the leased
> locking is required there as well, just as a collaborative effort to
> notate to the non-responding node to stop writing to the image).
What about using dlm? This gives fencing for free. See my other post
- allowing libvirt to use cluster wide storage locks would solve your
problem?
-- Guido
>
> -Original Message-
> From: Perry Myers [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 21, 2008 21:09 PM
> To: Itamar Heim
> Cc: libvir-list@redhat.com
> Subject: Re: [libvirt] image locking?
>
> Itamar Heim wrote:
> > Hi Perry,
> >
> > The problem is with unreachable hosts which are locking the image
> > forever.
> >
> > When fencing can't be used, there is no way for the management to
> > "release" the image, since it can't verify the host stopped using the
> > image. A leased lock mechanism, while not providing 100% prevention,
> > does allow a collaborative effort to allow releasing the image after
> > the lock expired, by having the nodes check that they still own the
> > lease and stop writing to the images.
>
> If you have an unreachable host that is locking the image forever, you
> walk into the datacenter and pull the plug. Once that is done, you can
> use the oVirt Server interface to undefine the vm and release the storage
> volume. So it can be done without hw fencing, it just involves manual
> administrator action. Not ideal, but it works :)
>
> > It would have been much better if image access could have been enforced
> > at storage level, but that is much more complex (and not relevant for
> > images under LVM for example)
>
> Agreed. We're using the above procedure (pull the plug or hw fencing)
> until a better mechanism is created.
>
> Perry
>
> --
> Libvir-list mailing list
> Libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi Daniel,
On Tue, Oct 21, 2008 at 03:25:25PM +0200, Daniel Veillard wrote:
[..snip..]
> Those are just stylistic issues, I can apply the patch with those
> changed if you wish if you don't have time for a new patch,
Thanks for your comments. Updated version attached. I basically removed
the union in favour of a single slotnum variable and cleaned up the
error messages.
As Daniel P. pointed out, the situation isn't ideal since we can only
hotremove disks added during the same session since qemu has no real
notion of "reidentifying" the disks that were passed on the command
line, this can hopefully be resolved in the future with a little help
from qemu.
Cheers,
-- Guido
>From db7089cbd401f3474b73b2e03be4b1489b860df3 Mon Sep 17 00:00:00 2001
From: Guido Guenther <[EMAIL PROTECTED]>
Date: Fri, 17 Oct 2008 15:46:38 +0200
Subject: [PATCH] device detach for scsi/virtio disks
so far only disks hot added during the same session can be detached
---
src/domain_conf.h |1 +
src/qemu_driver.c | 134 +++--
2 files changed, 130 insertions(+), 5 deletions(-)
diff --git a/src/domain_conf.h b/src/domain_conf.h
index 4d193f4..886f318 100644
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -90,6 +90,7 @@ struct _virDomainDiskDef {
char *driverType;
unsigned int readonly : 1;
unsigned int shared : 1;
+int slotnum; /* pci slot number for unattach */
};
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 34f743b..4e8e10d 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2510,12 +2510,12 @@ static int qemudDomainChangeEjectableMedia(virDomainPtr dom,
return 0;
}
-static int qemudDomainAttachDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr dev)
+static int qemudDomainAttachPciDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr dev)
{
struct qemud_driver *driver = (struct qemud_driver *)dom->conn->privateData;
virDomainObjPtr vm = virDomainFindByUUID(&driver->domains, dom->uuid);
int ret, i;
-char *cmd, *reply;
+char *cmd, *reply, *s;
char *safe_path;
const char* type = virDomainDiskBusTypeToString(dev->data.disk->bus);
@@ -2563,7 +2563,14 @@ static int qemudDomainAttachDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr d
DEBUG ("pci_add reply: %s", reply);
/* If the command succeeds qemu prints:
* OK bus 0... */
-if (!strstr(reply, "OK bus 0")) {
+#define PCI_ATTACH_OK_MSG "OK bus 0, slot "
+if ((s=strstr(reply, PCI_ATTACH_OK_MSG))) {
+char* dummy = s;
+s += strlen(PCI_ATTACH_OK_MSG);
+
+if (virStrToLong_i ((const char*)s, &dummy, 10, &dev->data.disk->slotnum) == -1)
+qemudLog(QEMUD_WARN, _("Unable to parse slot number\n"));
+} else {
qemudReportError (dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
_("adding %s disk failed"), type);
VIR_FREE(reply);
@@ -2744,7 +2751,7 @@ static int qemudDomainAttachDevice(virDomainPtr dom,
} else if (dev->data.disk->bus == VIR_DOMAIN_DISK_BUS_SCSI ||
dev->data.disk->bus == VIR_DOMAIN_DISK_BUS_VIRTIO) {
supported = 1;
-ret = qemudDomainAttachDiskDevice(dom, dev);
+ret = qemudDomainAttachPciDiskDevice(dom, dev);
}
break;
}
@@ -2765,6 +2772,123 @@ static int qemudDomainAttachDevice(virDomainPtr dom,
return ret;
}
+static int qemudDomainDetachPciDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr dev)
+{
+struct qemud_driver *driver = (struct qemud_driver *)dom->conn->privateData;
+virDomainObjPtr vm = virDomainFindByUUID(&driver->domains, dom->uuid);
+int i, ret = -1;
+char *cmd, *reply;
+virDomainDiskDefPtr detach = NULL;
+
+if (!vm) {
+qemudReportError(dom->conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
+ "%s", _("no domain with matching uuid"));
+return -1;
+}
+
+for (i = 0 ; i < vm->def->ndisks ; i++) {
+if (STREQ(vm->def->disks[i]->dst, dev->data.disk->dst)) {
+detach = vm->def->disks[i];
+break;
+}
+}
+
+if (!detach) {
+qemudReportError(dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ _("disk %s not found"), dev->data.disk->dst);
+return -1;
+}
+
+if (detach->slotnum < 1) {
+qemudReportError(dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ _("disk %s cannot be detached - invalid slot number %d"),
+ detach->dst, detach->slotnum);
+return -1;
+}
+
+ret = asprintf(&cmd, "pci_del 0 %d", detach->slotnum);
+if (ret == -1) {
+qemudReportError(dom->conn, NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
+return ret;
+}
+
+if (qemudMonitorCommand(driver, vm, cmd, &reply) < 0) {
+qemudReportError(dom->conn, dom, NULL, VIR_ERR_OPERATION_FAI
Hi,
I just ran across these oddities when using a bit more libvirt+xen:
1.) virsh setmaxmem:
On a running domain:
# virsh setmaxmem domain 256000
completes but virsh dumpxml as well as the config.sxp still shows the
old amount of memory. Looks as the set_maxmem hypercall simply gets
ignored. xm mem-max works as expected. Smells like a bug in the ioctl?
2.) virsh list:
Sometimes (didn't find a pattern yet) when shutting down a running
domains and restarting it I'm seeing:
Id Name State
--
0 Domain-0 running
2 foo idle
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
7 bar idle
Note that the number of errors the corresponds to the number of
shutdowns. VirXen_getdomaininfolist returns 7 in the above case.
virDomainLookupByID later on fails for these "additional" domains.
3.) virsh list: Duplicate domains:
Id Name State
--
0 Domain-0 running
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
14 bar no state
libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
daemon:
16 bar idle
Domain 14 can't be shut down (xm list only lists domain 16).
Could be a similar problem as the above.
This is all libvirt 0.4.6 (but the code looks very similar in gurrent
CVS) and xen-3.2.1 on Debian. The detected ABI is hypervisor call v2,
sys ver6 dom ver5. And from a quick glance at the libxen-dev package the
structs seem to match.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Nov 24, 2008 at 01:56:29PM +, Daniel P. Berrange wrote:
> On Mon, Nov 24, 2008 at 02:52:50PM +0100, Guido G?nther wrote:
> > Hi,
> > libvirt_sym.version is looked for at the wrong location. O.k. to apply?
>
> Ah yes, forgot to change this. Go ahead.
Applied.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Finally got around to have another look at qemu/kvm surviving libvirt
restarts:
On Tue, Oct 07, 2008 at 05:37:52PM +0100, Daniel P. Berrange wrote:
> > diff --git a/src/domain_conf.h b/src/domain_conf.h
> > index 632e5ad..1ac1561 100644
> > --- a/src/domain_conf.h
> > +++ b/src/domain_conf.h
> > @@ -448,6 +448,7 @@ struct _virDomainObj {
> > int stdout_fd;
> > int stderr_fd;
> > int monitor;
> > +char *monitorpath;
>
> I think we can avoid needing this. If we write out the staste the
> moment the VM is started, we don't need to carry this around in
> memory. Alternatively, since we're writing all stdout/err data to
> the logfile, we could simply re-parse the log to extract the
> monitor path upon restart.
I'm not sure reparsing the log is that good. Maybe the log got rotated
in the meantime or the admin moved it away. So I'd rather keep this in
/var/run/ too. We don't need that extra monitorpath variable we though,
we can simply pick it from /proc//fd/ when
writing out the state information.
[..snip..]
> > +static int
> > +qemudFileReadMonitor(const char *dir,
> > + const char *name,
> > + char **path)
> > +{
> > +int rc;
> > +FILE *file;
> > +char *monitorfile = NULL;
> > +
> > +if (asprintf(&monitorfile, "%s/%s.monitor", dir, name) < 0) {
> > +rc = ENOMEM;
> > +goto cleanup;
> > +}
> > +
> > +if (!(file = fopen(monitorfile, "r"))) {
> > +rc = errno;
> > +goto cleanup;
> > +}
> > +
> > +if (fscanf(file, "%as", path) != 1) {
> > +rc = EINVAL;
> > +goto cleanup;
> > +}
> > +
> > +if (fclose(file) < 0) {
> > +rc = errno;
> > +goto cleanup;
> > +}
> > +
> > +rc = 0;
> > +
> > + cleanup:
> > +VIR_FREE(monitorfile);
> > +return rc;
> > +}
>
> If we re-parse the logfile to extract the monitiro PTY path, this is
> unneccessary. If not, this can be simplied by just calling the
> convenient virFileReadAll() method.
We have several things that need to be (re)stored. The id (if we don't
switch over to using PIDs), the monitor path, the domain state (running,
paused, ...), and the acutally used vncport are things that come to
mind. Some of the information is already in the domain.xml but not
getting reparsed properly (e.g. def->id is always set to -1 and the
vncport isn't reread if "autport=yes").
Therefore I introduced a flag VIR_DOMAIN_XML_STATE that tells the
virDomain*DefParse functions to set those values when reading back "state"
not "config". This somewhat mixes config with state which I don't like
too much. It would probably be better to add an extra set of functions
that takes the virDomainObjPtr instead of the virDomainDefPtr? This way
we could also fold in the monitor path and the domain state easily like:
Does this make sense? For now I use an extra file for the monitor path.
[..snip..]
> > +static int
> > +qemudSaveDomainState(struct qemud_driver * driver, virDomainObjPtr vm) {
> > +int ret;
> > +
> > +if ((ret = virFileWritePid(driver->stateDir, vm->def->name, vm->pid))
> > != 0) {
> > +qemudLog(QEMUD_ERR, _("Unable to safe pidfile for %s: %s\n"),
> > +vm->def->name, strerror(ret));
> > + return ret;
> > +}
> > +if ((ret = virDomainSaveConfig(NULL, driver->stateDir, vm->def))) {
> > +qemudLog(QEMUD_ERR, _("Unable to save domain %s\n"),
> > vm->def->name);
> > +return ret;
> > +}
> > +if ((ret = qemudFileWriteMonitor(driver->stateDir, vm->def->name,
> > vm->monitorpath)) != 0) {
> > +qemudLog(QEMUD_ERR, _("Unable to monitor file for %s: %s\n"),
> > +vm->def->name, strerror(ret));
> > +return ret;
> > +}
> > +return 0;
> > +}
> > +
>
> This will need to be called at time of VM creation, and the
> XSL config will need updating whether live config changes.
O.k. I'm currently only calling this when forking qemu, I'll add the
calls to the places where the config changes soonish.
[..snip..]
> > diff --git a/src/util.h b/src/util.h
> > index 093ef46..8fbe2cd 100644
> > --- a/src/util.h
> > +++ b/src/util.h
> > @@ -32,6 +32,7 @@ enum {
> > VIR_EXEC_NONE = 0,
> > VIR_EXEC_NONBLOCK = (1 << 0),
> > VIR_EXEC_DAEMON = (1 << 1),
> > +VIR_EXEC_SETSID = (1 << 2),
> > };
>
> Shouldn't we simply be starting all the QEMU VMs with VIR_EXEC_DAEMON
> so they totally disassociate themselves from libvirtd right away. They
> will be disassociated anyway if the libvirtd is ever restarted, so best
> to daemonize from time they are started, to avoid any surprising changes
> in behaviour
Done.
-- Guido
>From cf7671af462298650343103b5ec386665533d53c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Guido=20G=C3=BCnther?= <[EMAIL PROTECTED]>
Date: Sun, 23 Nov 2008 16:22:59 +0100
Subject: [PATCH] let qemu/kvm survive libvirtd restarts
---
src/domain_conf.c | 33 +++--
src/domai
On Tue, Nov 25, 2008 at 04:32:00PM -0800, Bryan McLellan wrote:
> Is there a way to configure libvirt to cache the serial console on the
> host so the buffer on the guest does not fill up when you aren't
> connected to the console, or should I disable the serial console?
As Daniel pointed out this is a bug in KVM/Qemu. Debian got bitten by
this kvm bug too:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494831
The bugreport has the necessary patches. Ubuntu just has to resync the
Debian package again once these changes are in.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Nov 25, 2008 at 11:39:57AM +, Daniel P. Berrange wrote:
> On Fri, Nov 21, 2008 at 11:13:04PM +0100, Guido G?nther wrote:
> > Hi,
> > I just ran across these oddities when using a bit more libvirt+xen:
> >
> > 1.) virsh setmaxmem:
> >
> > On a running domain:
> > # virsh setmaxmem domain 256000
> > completes but virsh dumpxml as well as the config.sxp still shows the
> > old amount of memory. Looks as the set_maxmem hypercall simply gets
> > ignored. xm mem-max works as expected. Smells like a bug in the ioctl?
>
> The setmaxmem API is not performance critical, so it sounds like we
> should first try setting it via XenD, and use Hypervisor as the
> fallback instead.
I tried that and it worked as you suggested. However, checking the "old"
method of using HV out of a sudden works too now, no idea why that
reliably failed the last time and doesn't do so now (the machine has
been rebooted in the meantime though). I keep the patched package around
in case this pops up again.
>
> > 2.) virsh list:
> >
> > Sometimes (didn't find a pattern yet) when shutting down a running
> > domains and restarting it I'm seeing:
> >
> > Id Name State
> > --
> > 0 Domain-0 running
> > 2 foo idle
> > libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> > daemon:
> > libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> > daemon:
> > libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> > daemon:
> > libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> > daemon:
> > 7 bar idle
> >
> > Note that the number of errors the corresponds to the number of
> > shutdowns. VirXen_getdomaininfolist returns 7 in the above case.
> > virDomainLookupByID later on fails for these "additional" domains.
>
> This is basically a XenD bug. What's happening is that the domain
> has been shutdown, and got most of the way through cleanup, as far
> as the hypervisor is concerned. But something is still hanging around
> keeping the domain from being completely terminated. In this case
> XenD takes the dubious approach of just pretending the domain does
> not exist. So libvirt sees it exists in the hypervisor, but when
> asking XenD for more data, it gets that error. This really really
> sucks.
>
> THere's not really much we can do about it when XenD is just plain
> lieing about what exists. We explicitly don't ask XenD for the list
> of domain IDs because it is incredibly slow, hence we use the HV.
>
> The only idea I can think of is to ask XenStore for the list of
> domain IDs. This is still dramatically faster than asking XenD,
> but not quite as fast as the Hypervisor.
>
> >
> > 3.) virsh list: Duplicate domains:
> >
> > Id Name State
> > --
> > 0 Domain-0 running
> > libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> > daemon:
> 2A> libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> daemon:
> > libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> > daemon:
> > 14 bar no state
> > libvir: Xen Daemon error : GET operation failed: xend_get: error from xen
> > daemon:
> > 16 bar idle
> >
> > Domain 14 can't be shut down (xm list only lists domain 16).
> >
> > Could be a similar problem as the above.
>
> Yeha, this is almost certainly just another example of XenD not properly
> cleaning up / destroying domains. If you still have a machine which
> shows this behaviour, then I'd recommend trying this change to our Xen
> impl
>
> In xen_unified.c, find the method xenUnifiedListDomains and make it first
> call xenStoreListDomains() and then fallback to trying HV & XenD drivers.
> If we're lucky this will help
Yes this helps indeed, thanks a lot. Possible patch attached.
-- Guido
>From 215f2c99da9b086d8d506f359a1e4cfcc64670b6 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Guido=20G=C3=BCnther?= <[EMAIL PROTECTED]>
Date: Wed, 26 Nov 2008 10:54:51 +0100
Subject: [PATCH] prefer xenstore driver for listDomains
at least Debian's xen 3.2.1 reports ghost ids of already shutdown domains when
using the HV driver.
---
src/proxy_internal.c |3 +--
src/proxy_internal.h |2 ++
src/xen_unified.c| 29 +++--
src/xend_internal.c |2 +-
src/xend_internal.h |1 +
5 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/src/proxy_internal.c b/src/proxy_internal.c
index 1378559..daf1193 100644
--- a/src/proxy_internal.c
+++ b/src/proxy_internal.c
@@ -37,7 +37,6 @@ static int xenProxyOpen(virConnectPtr conn, xmlURIPtr uri, virConnectAuthPtr aut
static int xenProxyGetVersion(virConnectPtr conn, unsigned long *hvVer);
static int xenProxyNodeGetInfo(virConnectPtr conn, virNodeInfoPtr info);
static char *xenProxyGetCapabilities(virConnectPt
On Wed, Nov 26, 2008 at 05:08:49PM +0100, Chris Lalancette wrote:
> +AC_PATH_PROG([UDEVSETTLE], [udevsettle], [udevsettle],
> + [/sbin:/usr/sbin:/usr/local/sbin:$PATH])
As far as I understand things as of udev 117 udevsettle is deprecated in
favour of "udevadm settle". So it's probably better to prefer this over
udevsettle if present?
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=ChangeLog;h=d317b97760fd502efb3426148f1a6e409d3f9bff;hb=6d83d9a62468c2db4357b362f910b121c633a965
Recent udev versions even dropped the compat symlink.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Nov 27, 2008 at 04:07:48PM +, Daniel P. Berrange wrote:
> On Thu, Nov 27, 2008 at 05:04:05PM +0100, Guido G?nther wrote:
> > On Tue, Nov 25, 2008 at 11:39:57AM +, Daniel P. Berrange wrote:
> > > Yeha, this is almost certainly just another example of XenD not properly
> > > cleaning up / destroying domains. If you still have a machine which
> > > shows this behaviour, then I'd recommend trying this change to our Xen
> > > impl
> > >
> > > In xen_unified.c, find the method xenUnifiedListDomains and make it first
> > > call xenStoreListDomains() and then fallback to trying HV & XenD drivers.
> > > If we're lucky this will help
> > Yes this helps indeed, thanks a lot. Possible patch attached.
>
> Thanks for confirming. ACK to this patch - it looks reasonable to
> me, and shouldn't have any serious performance implication.
O.k., commited now.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Nov 26, 2008 at 08:54:40PM +, Daniel P. Berrange wrote:
[..snip..]
> Hmm, interesting idea - we already have a variant for parsing based
> off an arbitrary XML node, rather than assuming the root,
>
> virDomainDefPtr virDomainDefParseNode(virConnectPtr conn,
> virCapsPtr caps,
> xmlDocPtr doc,
> xmlNodePtr root);
>
> So we could add a wrapper function which writes out a XML doc
>
>
>
>
> ... normal domain XML config ...
>
>
>
> And so have a function
>
>virDomainObjPtr virDomainObjParse(const char *filename)
>
> which'd parse the custom QEMU state, and then just invoke the
> virDomainDefParseNode for the nested tag.
Yes, nice - this simplifies things. I'll try that.
> Now, some things like VNC port, domain ID really are easily tracked
> in the regular domain XML - rather than adding VIR_DOMAIN_XML_STATE
> I've a slight alternative idea.
>
> The formatXML methods already accept a flag VIR_DOMAIN_XML_INACTIVE
> which when passed causes it to skip some attributes which only
> make sense for running VMs - VNC port, ID, VIF name
>
> The parseXML methods, just hardcode this and always skip these
> attributes. We should fix this so the parsing only skips these
> attrs if this same VIR_DOMAIN_XML_INACTIVE flag is passed. Then
> just make sure all existing code is changed to set this flag
> when parsing XML. The code for loading VM from disk can simply
> not set this flag. Technically the LXC driver shold be doing
> this already, precisely for the VIF name issue.
Like the attached patch?
-- Guido
>From 87db4a698ed9b49294c0f94137fc6beef13bd4e8 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Guido=20G=C3=BCnther?= <[EMAIL PROTECTED]>
Date: Tue, 25 Nov 2008 13:02:43 +0100
Subject: [PATCH] differentiate between active and inactive configs
by honoring the VIR_DOMAIN_XML_INACTIVE flag.
---
src/domain_conf.c| 35 +++
src/domain_conf.h|6 --
src/lxc_controller.c |3 ++-
src/lxc_driver.c |2 +-
src/test.c |6 --
tests/qemuxml2argvtest.c |3 ++-
6 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/src/domain_conf.c b/src/domain_conf.c
index 4adab69..292cecf 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -1318,7 +1318,7 @@ error:
/* Parse the XML definition for a graphics device */
static virDomainGraphicsDefPtr
virDomainGraphicsDefParseXML(virConnectPtr conn,
- xmlNodePtr node) {
+ xmlNodePtr node, int flags) {
virDomainGraphicsDefPtr def;
char *type = NULL;
@@ -1355,7 +1355,8 @@ virDomainGraphicsDefParseXML(virConnectPtr conn,
VIR_FREE(port);
/* Legacy compat syntax, used -1 for auto-port */
if (def->data.vnc.port == -1) {
-def->data.vnc.port = 0;
+if (flags & VIR_DOMAIN_XML_INACTIVE)
+def->data.vnc.port = 0;
def->data.vnc.autoport = 1;
}
} else {
@@ -1365,7 +1366,8 @@ virDomainGraphicsDefParseXML(virConnectPtr conn,
if ((autoport = virXMLPropString(node, "autoport")) != NULL) {
if (STREQ(autoport, "yes")) {
-def->data.vnc.port = 0;
+if (flags & VIR_DOMAIN_XML_INACTIVE)
+def->data.vnc.port = 0;
def->data.vnc.autoport = 1;
}
VIR_FREE(autoport);
@@ -1699,11 +1701,12 @@ int virDomainDiskQSort(const void *a, const void *b)
#ifndef PROXY
static virDomainDefPtr virDomainDefParseXML(virConnectPtr conn,
virCapsPtr caps,
-xmlXPathContextPtr ctxt)
+xmlXPathContextPtr ctxt, int flags)
{
xmlNodePtr *nodes = NULL, node = NULL;
char *tmp = NULL;
int i, n;
+long id = -1;
virDomainDefPtr def;
if (VIR_ALLOC(def) < 0) {
@@ -1711,7 +1714,11 @@ static virDomainDefPtr virDomainDefParseXML(virConnectPtr conn,
"%s", _("failed to allocate space for xmlXPathContext"));
return NULL;
}
-def->id = -1;
+
+if (!(flags & VIR_DOMAIN_XML_INACTIVE))
+if((virXPathLong(conn, "string(./@id)", ctxt, &id)) < 0)
+id = -1;
+def->id = (int)id;
/* Find out what type of virtualization to use */
if (!(tmp = virXPathString(conn, "string(./@type)", ctxt))) {
@@ -2101,7 +2108,8 @@ static virDomainDefPtr virDomainDefParseXML(virConnectPtr conn,
}
if (n > 0) {
virDomainGraphicsDefPtr graphics = virDomainGraphicsDefParseXML(conn,
-nodes[0]);
+nodes[0],
+
On Mon, Dec 01, 2008 at 03:31:55PM +0100, Mickaël Canévet wrote:
> In other (debian) words, will an "apt-get update kvm -t
> experimental" (which provides kvm-79) be enough on my lenny (I would
> like to limit unstable or experimental packages) ?
experimental also has kvm-source, you can build new kernel modules
easily with modules-assistant - see README.Debian.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Sun, Nov 30, 2008 at 12:43:48PM +0100, Guido Günther wrote:
> >From 87db4a698ed9b49294c0f94137fc6beef13bd4e8 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Guido=20G=C3=BCnther?= <[EMAIL PROTECTED]>
> Date: Tue, 25 Nov 2008 13:02:43 +0100
> Subject: [PATCH] differentiate between active and inactive configs
>
> by honoring the VIR_DOMAIN_XML_INACTIVE flag.
O.k. to commit this part as a start so you can readily use it vor lxc?
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Dec 03, 2008 at 04:38:10PM +0100, Daniel Veillard wrote:
> On Tue, Dec 02, 2008 at 10:22:28PM +0100, Guido Günther wrote:
> > We do so in qemudCapsInitGuest() but not in qemudProbe(). O.k. to apply?
> > -- Guido
>
>
> Looks fine to me !
Applied now.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Dec 04, 2008 at 10:56:25AM +, Daniel P. Berrange wrote:
> On Wed, Dec 03, 2008 at 06:20:12PM +0100, Guido G?nther wrote:
> > On Sun, Nov 30, 2008 at 12:43:48PM +0100, Guido Günther wrote:
> > > >From 87db4a698ed9b49294c0f94137fc6beef13bd4e8 Mon Sep 17 00:00:00 2001
> > > From: =?utf-8?q?Guido=20G=C3=BCnther?= <[EMAIL PROTECTED]>
> > > Date: Tue, 25 Nov 2008 13:02:43 +0100
> > > Subject: [PATCH] differentiate between active and inactive configs
> > >
> > > by honoring the VIR_DOMAIN_XML_INACTIVE flag.
> > O.k. to commit this part as a start so you can readily use it vor lxc?
>
> ACK, assuming 'make check' still passes.
It does here, sure. Patch Applied now. I've added the flag to the
functions currently needed for qemu but if nobody objects I'd like to
add them to:
virDomainDeviceDefParse
virDomainDefParseString
virDomainHostdevSubsysUsbDefParseXML
virDomainDiskDefParseXML
virDomainFSDefParseXML
virDomainNetDefParseXML
virDomainInputDefParseXML
virDomainSoundDefParseXML
virDomainHostdevDefParseXML
virDomainChrDefParseXML
too, to make things more consistent.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
attached patch is from Debian Bug #507553:
The logfile is opened with O_APPEND (to make logrotate work with
copytruncate) and without O_TRUNC (to not lose log information e.g. with
stop and start of a VM).
Using collectd or munin to monitor VMs creates quiet a bit of qemu
monitor output so the ability to use logrotate makes a lot of sense to
me.
O.k. to apply?
-- Guido
diff -ur libvirt-0.4.4.orig/src/qemu_driver.c libvirt-0.4.4/src/qemu_driver.c
--- libvirt-0.4.4.orig/src/qemu_driver.c2008-06-12
16:52:53.0 +0200
+++ libvirt-0.4.4/src/qemu_driver.c 2008-12-02 12:48:32.271881000 +0100
@@ -844,7 +844,7 @@
return -1;
}
-if ((vm->logfile = open(logfile, O_CREAT | O_TRUNC | O_WRONLY,
+if ((vm->logfile = open(logfile, O_CREAT | O_APPEND | O_WRONLY,
S_IRUSR | S_IWUSR)) < 0) {
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
_("failed to create logfile %s: %s"),
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Dec 04, 2008 at 01:26:40PM +, Daniel P. Berrange wrote:
> On Thu, Dec 04, 2008 at 02:11:07PM +0100, Guido G?nther wrote:
> > Hi,
> > attached patch is from Debian Bug #507553:
> >
> > The logfile is opened with O_APPEND (to make logrotate work with
> > copytruncate) and without O_TRUNC (to not lose log information e.g. with
> > stop and start of a VM).
> >
> > Using collectd or munin to monitor VMs creates quiet a bit of qemu
> > monitor output so the ability to use logrotate makes a lot of sense to
> > me.
>
> And is there a corresponding logrotate config file from Debian we
> can use ? If we're going to let log files append, then we need to
> ship a logrotate config by default too.
I've changed the patch to only use O_APPEND as root so we don't fill up
the user's log when running as qemu:///session
> ACK if we add a logrotate config too
New version attached. O.k. to apply?
-- Guido
>From c0e2c2ac0a62bc2f7907efe03f8f34f117035977 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Guido=20G=C3=BCnther?= <[EMAIL PROTECTED]>
Date: Thu, 4 Dec 2008 17:09:39 +0100
Subject: [PATCH] handle qemu monitor logs via logrotate
therefore use O_APPEND instead of O_CREAT if running as root
---
qemud/Makefile.am | 13 -
qemud/libvirtd.logrotate.in |8
src/qemu_driver.c | 10 --
3 files changed, 28 insertions(+), 3 deletions(-)
create mode 100644 qemud/libvirtd.logrotate.in
diff --git a/qemud/Makefile.am b/qemud/Makefile.am
index 15d3717..7b778d8 100644
--- a/qemud/Makefile.am
+++ b/qemud/Makefile.am
@@ -132,7 +132,8 @@ libvirtd_DEPENDENCIES = $(libvirtd_LDADD)
default_xml_dest = libvirt/qemu/networks/default.xml
-install-data-local: install-init install-data-sasl install-data-polkit
+install-data-local: install-init install-data-sasl install-data-polkit \
+install-logrotate
mkdir -p $(DESTDIR)$(sysconfdir)/libvirt/qemu/networks/autostart
$(INSTALL_DATA) $(srcdir)/default-network.xml \
$(DESTDIR)$(sysconfdir)/$(default_xml_dest)
@@ -191,6 +192,16 @@ remote_dispatch_localvars.h: $(srcdir)/remote_generate_stubs.pl remote_protocol.
remote_dispatch_proc_switch.h: $(srcdir)/remote_generate_stubs.pl remote_protocol.x
perl -w $(srcdir)/remote_generate_stubs.pl -w $(srcdir)/remote_protocol.x > $@
+libvirtd.logrotate: libvirtd.logrotate.in
+ sed \
+ -e [EMAIL PROTECTED]@[EMAIL PROTECTED]@!g \
+ < $< > [EMAIL PROTECTED]
+ mv [EMAIL PROTECTED] $@
+
+install-logrotate: libvirtd.logrotate
+ mkdir -p $(DESTDIR)$(sysconfdir)/logrotate.d/
+ $(INSTALL_DATA) $< $(DESTDIR)$(sysconfdir)/logrotate.d/$<
+
if LIBVIRT_INIT_SCRIPTS_RED_HAT
install-init: libvirtd.init
mkdir -p $(DESTDIR)$(sysconfdir)/rc.d/init.d
diff --git a/qemud/libvirtd.logrotate.in b/qemud/libvirtd.logrotate.in
new file mode 100644
index 000..9b42630
--- /dev/null
+++ b/qemud/libvirtd.logrotate.in
@@ -0,0 +1,8 @@
[EMAIL PROTECTED]@/log/libvirt/qemu/*.log {
+daily
+missingok
+rotate 7
+compress
+delaycompress
+copytruncate
+}
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index efe780c..0e8acc9 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -798,6 +798,8 @@ static int qemudStartVMDaemon(virConnectPtr conn,
unsigned int qemuCmdFlags;
fd_set keepfd;
const char *emulator;
+uid_t uid = geteuid();
+mode_t logmode;
FD_ZERO(&keepfd);
@@ -841,8 +843,12 @@ static int qemudStartVMDaemon(virConnectPtr conn,
return -1;
}
-if ((vm->logfile = open(logfile, O_CREAT | O_TRUNC | O_WRONLY,
-S_IRUSR | S_IWUSR)) < 0) {
+logmode = O_CREAT | O_WRONLY;
+if (uid != 0)
+logmode |= O_TRUNC;
+else
+logmode |= O_APPEND;
+if ((vm->logfile = open(logfile, logmode, S_IRUSR | S_IWUSR)) < 0) {
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
_("failed to create logfile %s: %s"),
logfile, strerror(errno));
--
1.6.0.2
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Dec 05, 2008 at 02:20:08PM +0100, Daniel Veillard wrote:
> On Thu, Dec 04, 2008 at 05:44:30PM +0100, Guido Günther wrote:
> > On Thu, Dec 04, 2008 at 01:26:40PM +, Daniel P. Berrange wrote:
> > > On Thu, Dec 04, 2008 at 02:11:07PM +0100, Guido G?nther wrote:
> > > > Hi,
> > > > attached patch is from Debian Bug #507553:
> > > >
> > > > The logfile is opened with O_APPEND (to make logrotate work with
> > > > copytruncate) and without O_TRUNC (to not lose log information e.g. with
> > > > stop and start of a VM).
> > > >
> > > > Using collectd or munin to monitor VMs creates quiet a bit of qemu
> > > > monitor output so the ability to use logrotate makes a lot of sense to
> > > > me.
> > >
> > > And is there a corresponding logrotate config file from Debian we
> > > can use ? If we're going to let log files append, then we need to
> > > ship a logrotate config by default too.
> > I've changed the patch to only use O_APPEND as root so we don't fill up
> > the user's log when running as qemu:///session
> >
> > > ACK if we add a logrotate config too
> > New version attached. O.k. to apply?
>
> Looks fine to me, we will need to update the spec file but that can be
> done later,
Applied now with one minor change: we create the logdir now during "make
install" since logrotate otherwise complains about the missing dir.
Cheers,
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
attached is a new version of the "let kvm/qemu survive libvirt restart"
patches. Since we have the VIR_DOMAIN_XML_INACTIVE changes already
applied we now only need to persist the monitor path, pid and current
domain state (running, paused, ...).
Cheers,
-- Guido
Pathes:
write pid file into stateDir
daemonize qemu processes
add XML parsing for vm status file
save domain status during vm creation and remove it on shutdown.
read saved vm status on libvirtd startup
src/domain_conf.c | 36 ++-
src/domain_conf.h |6 +
src/libvirt_sym.version.in |3 +
src/qemu_conf.c| 198 +++
src/qemu_conf.h| 18 ++
src/qemu_driver.c | 262 ++--
src/util.c | 20 ++-
src/util.h |2 +
.../qemuxml2argv-hostdev-usb-address.args |2 +-
tests/qemuxml2argvtest.c |2 +
10 files changed, 514 insertions(+), 35 deletions(-)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
