[libvirt] [PATCH] lxc: use new error code in lxcDomainUndefine
by Amy Griffis
Update lxcDomainUndefine() to use VIR_ERR_INVALID_OPERATION
instead of VIR_ERR_INTERNAL_ERROR.
Signed-off-by: Amy Griffis <amy.griffis(a)hp.com>
diff --git a/src/lxc_driver.c b/src/lxc_driver.c
index 5392af1..64c735d 100644
--- a/src/lxc_driver.c
+++ b/src/lxc_driver.c
@@ -329,13 +329,13 @@ static int lxcDomainUndefine(virDomainPtr dom)
}
if (virDomainIsActive(vm)) {
- lxcError(dom->conn, dom, VIR_ERR_INTERNAL_ERROR,
+ lxcError(dom->conn, dom, VIR_ERR_OPERATION_INVALID,
"%s", _("cannot delete active domain"));
goto cleanup;
}
if (!vm->persistent) {
- lxcError(dom->conn, dom, VIR_ERR_INTERNAL_ERROR,
+ lxcError(dom->conn, dom, VIR_ERR_OPERATION_INVALID,
"%s", _("cannot undefine transient domain"));
goto cleanup;
}
15 years, 7 months
[libvirt] [PATCH] python: Better error reporting if 'import libvirtmod' fails
by Cole Robinson
Don't squash a possibly legitimate libvirtmod error (e.g. some from
clashing libvirt.so versions) with 'Cannot import cygvirtmod'
---
python/libvir.py | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/python/libvir.py b/python/libvir.py
index 8a16dd0..3cda8dc 100644
--- a/python/libvir.py
+++ b/python/libvir.py
@@ -8,8 +8,12 @@
# On cygwin, the DLL is called cygvirtmod.dll
try:
import libvirtmod
-except:
- import cygvirtmod as libvirtmod
+except ImportError, lib_e:
+ try:
+ import cygvirtmod as libvirtmod
+ except ImportError, cyg_e:
+ if str(cyg_e).count("No module named"):
+ raise lib_e
import types
--
1.6.2.2
15 years, 7 months
[libvirt] [PATCH v2 0/2] FS backend VolCreateXMLFrom implementation.
by Cole Robinson
The following 2 patches implement virStorageVolCreateXMLFrom for the
storage driver and the FS storage backend.
Changes from v1:
- Mark origvol as building in driver implementation
- Make sure driver is locked when relocking pool object
- Simplify sparse file detection with memcmp
- Allocate read buffer on the heap.
Thanks,
Cole
Cole Robinson (2):
Storage driver implementation for CreateXMLFrom
VolumeCreateXMLFrom FS storage backend implementation.
src/storage_backend.h | 2 +
src/storage_backend_fs.c | 247 +++++++++++++++++++++++++++++++++++++++-------
src/storage_driver.c | 159 +++++++++++++++++++++++++++++-
3 files changed, 369 insertions(+), 39 deletions(-)
15 years, 7 months
[libvirt] libvirt API to write sectors on a device
by Francesco Latino
Hello,***I am able to compile libvirt samples on my KVM hypervisor. (I
edited and recompiled info.c code)
*I am creating a sample code to read/write disk devices.
With method *virDomainBlockPeek I can** read sectors from a given device
attached to a KVM virtual guest.**I am not able to* find an API to write
sectors on a disk: am I missing something ?Is there such method to write
sectors from a given virtual disk ?
Thanks,Francesco
15 years, 7 months
[libvirt] [PATCH 0/5] Interface Config Public APIs and remote stubs, with MAC addresses in string format
by Laine Stump
These patches are based on those I sent last week (the public
virInterface*() API definition, the local plumbing, and the RPC glue),
but with suggestions incorporated:
1) MAC address is always used in null-terminated ASCII string
format. This eliminates any potential problems with extra long
addresses.
2) no comments in libvirt.h
3) flags arguments are all unsigned.
Item (1) caused changes in most of the patches, so I just regenerated
the entire set. Is this the proper/expected thing to do, or should I
be making patches of patches?
15 years, 7 months
[libvirt] PATCH: Enable migration with QEMU >= 0.10.0
by Daniel P. Berrange
The KVM migration code was added to QEMU for the 0.10.0 release, so we
should enable this in libvirt now.
Daniel
diff -r be7993675e07 src/qemu_conf.c
--- a/src/qemu_conf.c Thu Apr 30 14:49:27 2009 +0100
+++ b/src/qemu_conf.c Thu Apr 30 15:08:45 2009 +0100
@@ -473,16 +473,13 @@ int qemudExtractVersionInfo(const char *
/*
* Handling of -incoming arg with varying features
- * -incoming tcp (kvm >= 79)
- * -incoming exec (kvm >= 80)
+ * -incoming tcp (kvm >= 79, qemu >= 0.10.0)
+ * -incoming exec (kvm >= 80, qemu >= 0.10.0)
* -incoming stdio (all earlier kvm)
*
* NB, there was a pre-kvm-79 'tcp' support, but it
* was broken, because it blocked the monitor console
* while waiting for data, so pretend it doesn't exist
- *
- * XXX when next QEMU release after 0.9.1 arrives,
- * we'll need to add MIGRATE_QEMU_TCP/EXEC here too
*/
if (kvm_version >= 79) {
flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_TCP;
@@ -490,6 +487,9 @@ int qemudExtractVersionInfo(const char *
flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_EXEC;
} else if (kvm_version > 0) {
flags |= QEMUD_CMD_FLAG_MIGRATE_KVM_STDIO;
+ } else if (version >= 10000) {
+ flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_TCP;
+ flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_EXEC;
}
if (retversion)
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 7 months
[libvirt] PATCH: Declare QEMU migration capabilities
by Daniel P. Berrange
This patches adds the missing data in the capabilities XML about the QEMU
driver's migration support. Specifically it declares support for both
offline and live migrate, and registers the 'tcp' URI scheme.
Daniel
diff -r 00f2e113eca8 src/qemu_conf.c
--- a/src/qemu_conf.c Mon May 18 12:38:18 2009 +0100
+++ b/src/qemu_conf.c Mon May 18 13:15:33 2009 +0100
@@ -371,7 +371,7 @@ virCapsPtr qemudCapsInit(void) {
uname (&utsname);
if ((caps = virCapabilitiesNew(utsname.machine,
- 0, 0)) == NULL)
+ 1, 1)) == NULL)
goto no_memory;
/* Using KVM's mac prefix for QEMU too */
@@ -380,6 +380,9 @@ virCapsPtr qemudCapsInit(void) {
if (virCapsInitNUMA(caps) < 0)
goto no_memory;
+ virCapabilitiesAddHostMigrateTransport(caps,
+ "tcp");
+
/* First the pure HVM guests */
for (i = 0 ; i < ARRAY_CARDINALITY(arch_info_hvm) ; i++)
if (qemudCapsInitGuest(caps,
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 7 months
[libvirt] Domain Event Handlers
by Noah Zoschke
Hello,
I have been playing around with the libvirt domain event handlers in
Python and am seeing something surprising. I am using trunk libvirt
and `event-test.py` with some more of the debugging strings uncommented.
When I trigger my first event:
virsh # define xppro-sp2-0.img.xml
Domain xppro-sp2-0.img defined from xppro-sp2-0.img.xml
The timeout and handle callbacks are called, but not my
domainEventRegister handler:
Invoking Timeout CB
Invoking Handle CB
When I trigger a second event:
virsh # create xppro-sp2-0.img.xml
Domain xppro-sp2-0.img created from xppro-sp2-0.img.xml
my event handler for the first event is finally called:
Invoking Timeout CB
domainEventHandler EVENT: Domain xppro-sp2-0.img(-1) Added 1
Invoking Handle CB
Likewise for a third event:
virsh # destroy xppro-sp2-0.img
Domain xppro-sp2-0.img destroyed
Invoking Timeout CB
domainEventHandler EVENT: Domain xppro-sp2-0.img(1) Started 0
Invoking Handle CB
So my handler is always one event behind.
This behavior is not intended is it? Am I missing either something in
`event-test.py` or in how I am using virsh that would correct this
behavior?
Thank you,
Noah
15 years, 7 months
[libvirt] Usage of UUID
by Eduardo Otubo
Hello all,
When I started to implement phyp driver, I use to handle the UUID as a
normal 'unsigned char *' with a LPAR value called "logical_serial_num"
that is a string in the format "067BE8B2", an identifier.
In the last comments I got from danpb and DV, they called my attention
to const string at UUID handling and some funtcions that must be
implemented: domainDumpXML, listDefinedDomains and numOfDefinedDomains.
My question is: Once I don't have information from my hypervisor about
UUID, do I have to handle UUID at "list" or "list --all" commands? Or I
should keep and handle this information only when defining a domaing at
libvirt?
I mean, in my point of view, there is no need to generate and store a
UUID while just listing LPARs in the remote server. What I should do is
to generate a random UUID (and store it) just when the user decides to
define it at libvirt.
Am I thinking right?
Thanks for the help.
[]'s
--
Eduardo Otubo
Software Engineer
Linux Technology Center
IBM Systems & Technology Group
Mobile: +55 19 8135 0885
otubo(a)linux.vnet.ibm.com
15 years, 7 months
