[libvirt] [PATCH] Correct 'cputune' documentation example.
by Neil Wilson
Signed-off-by: Neil Wilson <neil(a)aldur.co.uk>
---
docs/formatdomain.html.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 0517119..225e0c8 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -293,7 +293,7 @@
<vcpupin vcpu="1" cpuset="0,1"/>
<vcpupin vcpu="2" cpuset="2,3"/>
<vcpupin vcpu="3" cpuset="0,4"/>
- <cpushares>2048</cpushares>
+ <shares>2048</shares>
</cputune>
...</pre>
--
1.7.4.1
13 years, 5 months
[libvirt] [PATCH 00/10] coverity cleanups, round 1
by Eric Blake
Coverity reported a number of bugs against libvirt. I ran out
of time to get through them all today, but there are certainly
some real doozies in here. I've blamed commits where non-trivial
bugs were introduced, to help distros decide if things need
back-porting (I think that leaks on OOM situations and coverity
false positives are not serious enough to warrant a back-port).
These patches are pretty much independent (can be applied in any
order); I suppose I could have rebased it to order the series by
severity, oh well.
Eric Blake (10):
command: avoid leak on failure
libvirtd: avoid leak on failure
storage: avoid memory leak
storage: avoid memory leak on stat failure
lock: avoid leak on failure
remote: avoid leak on failure
qemu: avoid memory leak on vcpupin
event: avoid memory leak on cleanup
build: silence coverity false positive
build: silence coverity false positive
daemon/libvirtd.c | 4 +++-
daemon/remote.c | 1 +
src/conf/domain_event.c | 3 ++-
src/locking/lock_manager.c | 3 ++-
src/qemu/qemu_process.c | 21 +++++++++++++--------
src/remote/remote_driver.c | 7 ++++++-
src/storage/storage_backend_fs.c | 15 +--------------
src/util/command.c | 5 ++++-
src/util/storage_file.c | 15 +++++++--------
9 files changed, 39 insertions(+), 35 deletions(-)
--
1.7.4.4
13 years, 5 months
[libvirt] [PATCH] Fix regressions BlockStats/Info APIs in QEMU driver
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The change 18c2a592064d69499f70428e498f4a3cb5161cda caused
some regressions in behaviour of virDomainBlockStats
and virDomainBlockInfo in the QEMU driver.
The virDomainBlockInfo API stopped working for inactive
guests if querying a block device.
The virDomainBlockStats API did not promptly report
an error if the guest was not running in some cases.
* src/qemu/qemu_driver.c: Fix inactive guest handling
in BlockStats/Info APIs
---
src/qemu/qemu_driver.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 5632d62..3716b15 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5531,6 +5531,12 @@ qemudDomainBlockStats (virDomainPtr dom,
goto cleanup;
}
+ if (!virDomainObjIsActive(vm)) {
+ qemuReportError(VIR_ERR_OPERATION_INVALID,
+ "%s", _("domain is not running"));
+ goto cleanup;
+ }
+
for (i = 0 ; i < vm->def->ndisks ; i++) {
if (STREQ(path, vm->def->disks[i]->dst)) {
disk = vm->def->disks[i];
@@ -5994,7 +6000,8 @@ static int qemuDomainGetBlockInfo(virDomainPtr dom,
highest allocated extent from QEMU */
if (disk->type == VIR_DOMAIN_DISK_TYPE_BLOCK &&
format != VIR_STORAGE_FILE_RAW &&
- S_ISBLK(sb.st_mode)) {
+ S_ISBLK(sb.st_mode) &&
+ virDomainObjIsActive(vm)) {
qemuDomainObjPrivatePtr priv = vm->privateData;
if ((priv->jobActive == QEMU_JOB_MIGRATION_OUT)
@@ -6017,10 +6024,9 @@ static int qemuDomainGetBlockInfo(virDomainPtr dom,
if (qemuDomainObjBeginJob(vm) < 0)
goto cleanup;
- if (!virDomainObjIsActive(vm)) {
- qemuReportError(VIR_ERR_OPERATION_INVALID,
- "%s", _("domain is not running"));
- goto endjob;
+ if (virDomainObjIsActive(vm)) {
+ ret = 0;
+ goto cleanup;
}
qemuDomainObjEnterMonitor(vm);
@@ -6029,7 +6035,6 @@ static int qemuDomainGetBlockInfo(virDomainPtr dom,
&info->allocation);
qemuDomainObjExitMonitor(vm);
-endjob:
if (qemuDomainObjEndJob(vm) == 0)
vm = NULL;
}
--
1.7.5.2
13 years, 5 months
[libvirt] [PATCH] Fix minor issues in libxenlight managed save
by Jim Fehlig
There were a few minor issues in commit 5b6c961e
- leak managed save path
- leak managed save fd
- functions that open an fd should also close it
---
src/libxl/libxl_driver.c | 30 ++++++++++++++++++++----------
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 9a794e8..ed24d10 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -632,23 +632,27 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
int ret;
uint32_t domid = 0;
char *dom_xml = NULL;
- char *managed_save = NULL;
+ char *managed_save_path = NULL;
+ int managed_save_fd = -1;
pid_t child_console_pid = -1;
libxlDomainObjPrivatePtr priv = vm->privateData;
/* If there is a managed saved state restore it instead of starting
* from scratch. The old state is removed once the restoring succeeded. */
if (restore_fd < 0) {
- managed_save = libxlDomainManagedSavePath(driver, vm);
- if (managed_save == NULL)
+ managed_save_path = libxlDomainManagedSavePath(driver, vm);
+ if (managed_save_path == NULL)
goto error;
- if (virFileExists(managed_save)) {
+ if (virFileExists(managed_save_path)) {
- restore_fd = libxlSaveImageOpen(driver, managed_save, &def, &hdr);
- if (restore_fd < 0)
+ managed_save_fd = libxlSaveImageOpen(driver, managed_save_path,
+ &def, &hdr);
+ if (managed_save_fd < 0)
goto error;
+ restore_fd = managed_save_fd;
+
if (STRNEQ(vm->def->name, def->name) ||
memcmp(vm->def->uuid, def->uuid, VIR_UUID_BUFLEN)) {
char vm_uuidstr[VIR_UUID_STRING_BUFLEN];
@@ -665,9 +669,12 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
virDomainObjAssignDef(vm, def, true);
def = NULL;
- if (unlink(managed_save) < 0)
- VIR_WARN("Failed to remove the managed state %s", managed_save);
+ if (unlink(managed_save_path) < 0) {
+ VIR_WARN("Failed to remove the managed state %s",
+ managed_save_path);
+ }
}
+ VIR_FREE(managed_save_path);
}
memset(&d_config, 0, sizeof(d_config));
@@ -738,6 +745,7 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
libxl_domain_config_destroy(&d_config);
VIR_FREE(dom_xml);
+ VIR_FORCE_CLOSE(managed_save_fd);
return 0;
error:
@@ -748,9 +756,9 @@ error:
}
libxl_domain_config_destroy(&d_config);
VIR_FREE(dom_xml);
- VIR_FREE(managed_save);
+ VIR_FREE(managed_save_path);
virDomainDefFree(def);
- VIR_FORCE_CLOSE(restore_fd);
+ VIR_FORCE_CLOSE(managed_save_fd);
return -1;
}
@@ -1955,6 +1963,8 @@ libxlDomainRestore(virConnectPtr conn, const char *from)
}
cleanup:
+ if (VIR_CLOSE(fd) < 0)
+ virReportSystemError(errno, "%s", _("cannot close file"));
virDomainDefFree(def);
if (vm)
virDomainObjUnlock(vm);
--
1.7.3.1
13 years, 5 months
[libvirt] [PATCH 0/2] libxl driver additions
by Markus Groß
I know it is very late for 0.9.2 but perhabs we could
squeeze these patches in (then the version numbers
of the functions in patch 2 have to be changed to 0.9.2).
Markus Groß (2):
Get maximum memory of running domain in libxl driver
Add managedSave support to libxl driver
src/libxl/libxl_driver.c | 356 ++++++++++++++++++++++++++++++++++++----------
1 files changed, 278 insertions(+), 78 deletions(-)
--
1.7.5.2
13 years, 5 months
Re: [libvirt] [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason
by Anthony Liguori
On 06/02/2011 02:13 PM, Luiz Capitulino wrote:
> On Thu, 02 Jun 2011 13:33:52 -0500
> Anthony Liguori<anthony(a)codemonkey.ws> wrote:
>
>> On 06/02/2011 01:09 PM, Luiz Capitulino wrote:
>>> On Thu, 02 Jun 2011 13:00:04 -0500
>>> Anthony Liguori<anthony(a)codemonkey.ws> wrote:
>>>
>>>> On 06/02/2011 12:57 PM, Luiz Capitulino wrote:
>>>>> On Wed, 01 Jun 2011 16:35:03 -0500
>>>>> Anthony Liguori<anthony(a)codemonkey.ws> wrote:
>>>>>
>>>>>> On 06/01/2011 04:12 PM, Luiz Capitulino wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> There are people who want to use QMP for thin provisioning. That's, the VM is
>>>>>>> started with a small storage and when a no space error is triggered, more space
>>>>>>> is allocated and the VM is put to run again.
>>>>>>>
>>>>>>> QMP has two limitations that prevent people from doing this today:
>>>>>>>
>>>>>>> 1. The BLOCK_IO_ERROR doesn't contain error information
>>>>>>>
>>>>>>> 2. Considering we solve item 1, we still have to provide a way for clients
>>>>>>> to query why a VM stopped. This is needed because clients may miss the
>>>>>>> BLOCK_IO_ERROR event or may connect to the VM while it's already stopped
>>>>>>>
>>>>>>> A proposal to solve both problems follow.
>>>>>>>
>>>>>>> A. BLOCK_IO_ERROR information
>>>>>>> -----------------------------
>>>>>>>
>>>>>>> We already have discussed this a lot, but didn't reach a consensus. My solution
>>>>>>> is quite simple: to add a stringfied errno name to the BLOCK_IO_ERROR event,
>>>>>>> for example (see the "reason" key):
>>>>>>>
>>>>>>> { "event": "BLOCK_IO_ERROR",
>>>>>>> "data": { "device": "ide0-hd1",
>>>>>>> "operation": "write",
>>>>>>> "action": "stop",
>>>>>>> "reason": "enospc", }
>>>>>>
>>>>>> you can call the reason whatever you want, but don't call it stringfied
>>>>>> errno name :-)
>>>>>>
>>>>>> In fact, just make reason "no space".
>>>>>
>>>>> You mean, we should do:
>>>>>
>>>>> "reason": "no space"
>>>>>
>>>>> Or that we should make it a boolean, like:
>>>>>
>>>>> "no space": true
>>>>
>>>>
>>>> Do we need reason in BLOCK_IO_ERROR if query-block returns this information?
>>>
>>> True, no.
>>>
>>>>> I'm ok with either way. But in case you meant the second one, I guess
>>>>> we should make "reason" a dictionary so that we can group related
>>>>> information when we extend the field, for example:
>>>>>
>>>>> "reason": { "no space": false, "no permission": true }
>>>>
>>>> Why would we ever have "no permission"?
>>
>> Why did it happen? It's not clear to me when read/write would return
>> EPERM. open() should fail. In fact, EPERM is not mentioned in man 2 read.
>
> Actually, the error was an EACCESS which might sound more bizarre :)
>
> What happened was that the device file in question had its permission
> changed during VM execution due to a bug somewhere else. I'm not sure if
> the error was returned in a read() or write() (Kevin might have more details).
Strange, EACCES should only happen on open(). Is it possible that
somehow a reopen was happening?
> This is a bit extreme and I'd agree it's arguable whether or not we should
> report EACCESS, but I had this in mind and ended up mentioning it...
If we can't explain why an error would occur, we shouldn't make it part
of the protocol :-)
> Maybe libvirt guys could provide more input wrt the error reason usage.
> If we don't have valid use cases for other errors, then I'll agree that
> providing only "no space" is enough.
Definitely! Adding libvirt to the CC to help encourage their input.
Regards,
Anthony Liguori
13 years, 5 months
[libvirt] [PATCHv4 0/7] interface: new public API for network config change transactions
by Laine Stump
(This is v3 of some of the patches and v4 of some others. Changes from
previous versions are noted in the individual patches.)
This patch series implements three new APIs for the interface
driver which support transactional changes to the host's network
config - at any point you can begin a transaction (which saves a
snapshot of the current config), then make any changes you like to the
config, and later either commit those changes (the current
implementation just removes the snapshotted files) or rollback to the
original config.
The actual implementation of this functionality lives in the netcf
library; these patches create pass-through functions that call out to
netcf on the machine that's running libvirtd.
Most importantly, note that uses of "start" in the API names have been
changed to "begin", and rather than a single virsh command with
multiple subcommands, there are now three separate commands:
iface-begin, iface-commit, and iface-rollback.
Thanks to using AC_CHECK_LIB in configure.ac, this code can safely be
pushed and built on systems that don't yet have a new enough netcf to
contain the API extensions - those functions are simply not
implemented in that case (and return the appropriate error).
13 years, 5 months
[libvirt] [PATCH] Explicitly set VM state to paused after migration completes
by Daniel P. Berrange
In v3 migration, once migration is completed, the VM needs
to be left in a paused state until after Finish3 has been
executed on the target. Only then will the VM be killed
off. When using non-JSON QEMU monitor though, we don't
receive any 'STOP' event from QEMU, so we need to manually
set our state offline & thus release lock manager leases.
It doesn't hurt to run this on the JSON case too, just in
case the event gets lost somehow
* src/qemu/qemu_migration.c: Explicitly set VM state to
paused when migration completes
---
src/qemu/qemu_migration.c | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index f4eda92..aa74d86 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -718,7 +718,7 @@ qemuMigrationSetOffline(struct qemud_driver *driver,
virDomainObjPtr vm)
{
int ret;
-
+ VIR_DEBUG("driver=%p vm=%p", driver, vm);
ret = qemuProcessStopCPUs(driver, vm, VIR_DOMAIN_PAUSED_MIGRATION);
if (ret == 0) {
virDomainEventPtr event;
@@ -1521,6 +1521,19 @@ static int doNativeMigrate(struct qemud_driver *driver,
if (qemuMigrationWaitForCompletion(driver, vm) < 0)
goto cleanup;
+ /* When migration completed, QEMU will have paused the
+ * CPUs for us, but unless we're using the JSON monitor
+ * we won't have been notified of this, so might still
+ * think we're running. For v2 protocol this doesn't
+ * matter because we'll kill the VM soon, but for v3
+ * this is important because we stay paused until the
+ * confirm3 step, but need to release the lock state
+ */
+ if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) {
+ if (qemuMigrationSetOffline(driver, vm) < 0)
+ goto cleanup;
+ }
+
if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen, 0) < 0)
VIR_WARN("Unable to encode migration cookie");
@@ -1816,6 +1829,19 @@ static int doTunnelMigrate(struct qemud_driver *driver,
ret = qemuMigrationWaitForCompletion(driver, vm);
+ /* When migration completed, QEMU will have paused the
+ * CPUs for us, but unless we're using the JSON monitor
+ * we won't have been notified of this, so might still
+ * think we're running. For v2 protocol this doesn't
+ * matter because we'll kill the VM soon, but for v3
+ * this is important because we stay paused until the
+ * confirm3 step, but need to release the lock state
+ */
+ if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) {
+ if (qemuMigrationSetOffline(driver, vm) < 0)
+ goto cleanup;
+ }
+
/* Close now to ensure the IO thread quits & is joinable in next method */
VIR_FORCE_CLOSE(client_sock);
--
1.7.4.4
13 years, 5 months
[libvirt] [PATCH] Fix error reporting with virDomainBlockStats on inactive guest
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
Pull the check on virDomainIsActive upto top of the QEMU
impl of virDomainBlockStats so that is is reported promptly
* src/qemu/qemu_driver.c: Check if guest is active immediately
---
src/qemu/qemu_driver.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 5632d62..3f8f814 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5531,6 +5531,12 @@ qemudDomainBlockStats (virDomainPtr dom,
goto cleanup;
}
+ if (!virDomainObjIsActive(vm)) {
+ qemuReportError(VIR_ERR_OPERATION_INVALID,
+ "%s", _("domain is not running"));
+ goto cleanup;
+ }
+
for (i = 0 ; i < vm->def->ndisks ; i++) {
if (STREQ(path, vm->def->disks[i]->dst)) {
disk = vm->def->disks[i];
--
1.7.5.2
13 years, 5 months
