[libvirt] [RFC] Support cpu hotplug in libvirt.
by tangchen
Hi~
It seems that libvirt is not cpu hotplug aware.
Please refer to the following problem.
1. At first, we have 2 cpus.
# cat /cgroup/cpuset/cpuset.cpus
0-1
# cat /cgroup/cpuset/libvirt/qemu/cpuset.cpus
0-1
2. And we have a vm1 with following configuration.
<cputune>
<vcpupin vcpu='0' cpuset='1'/>
<hypervisorpin cpuset='1'/>
</cputune>
3. Offline cpu1.
# echo 0 > /sys/devices/system/cpu/cpu1/online
# cat /sys/devices/system/cpu/cpu1/online
0
# cat /cgroup/cpuset/cpuset.cpus
0
# cat /cgroup/cpuset/libvirt/qemu/cpuset.cpus
0
4. Online cpu1.
# echo 1 > /sys/devices/system/cpu/cpu1/online
# cat /sys/devices/system/cpu/cpu1/online
1
# cat /cgroup/cpuset/cpuset.cpus
0-1
# cat /cgroup/cpuset/libvirt/cpuset.cpus
0
# cat /cgroup/cpuset/libvirt/qemu/cpuset.cpus
0
# cat /cgroup/cpuset/libvirt/lxc/cpuset.cpus
0
Here，cgroup updated cpuset.cpus，but not for libvirt directory，and also qemu and lxc directory.
vm1 cannot be started again.
# virsh start vm1
error: Failed to start domain vm1
error: Unable to set cpuset.cpus: Permission denied
And libvird gave the following errors.
2012-07-17 07:30:22.478+0000: 3118: error : qemuSetupCgroupVcpuPin:498 : Unable to set cpuset.cpus: Permission denied
I am trying to use netlink socket with NETLINK_KOBJECT_UEVENT protocol to
listen to cpu hotplug events. But I met a little problem here.
virNetlinkEventServiceStart() only create a global variable server, and
create a NETLINK_ROUTE netlink socket for it.
So if I want to create another different netlink socket, such as NETLINK_KOBJECT_UEVENT,
what should I do ?
Shall we make the server global variable a global array ?
(It seems there are a lot of work to do.)
Thanks. :)
--
Best Regards,
Tang chen
12 years, 3 months
[libvirt] [PATCH 0/3] Storage: Allow pool building while creating it
by Osier Yang
Patch 1/3 is just about the indention fix.
We tries to start the pool while creating a transicient pool,
if the pool target is not existed yet, we must fail on starting,
and thus we see many users raise up the problem on either list
or bugzilla. Patch 2/3 and 3/3 are to fix the problem by introducing
flags to allow the pool building for APIs virStoragePoolCreate
and virStoragePoolCreateXML, and expose the flags to commands
pool-create/pool-create-as/pool-start.
Osier Yang (3):
Fix the indentions of libvirt.h.in
storage: New flags to allow building the pool while creating it
virsh: New options for the 3 pool commands to allow pool building
include/libvirt/libvirt.h.in | 109 +++++++++++++++++++++++------------------
src/libvirt.c | 4 +-
src/storage/storage_driver.c | 38 ++++++++++++++-
tools/virsh.c | 100 ++++++++++++++++++++++++++++++++++++--
tools/virsh.pod | 27 +++++++++-
5 files changed, 217 insertions(+), 61 deletions(-)
Regards,
Osier
--
1.7.7.3
12 years, 3 months
[libvirt] [PATCH 0/3] Allow to override disk geometry.
by Viktor Mihajlovski
With qemu it is possible to override the geometry (cylinders, heads,
sectors) of disks.
This series adds a new XML tag for geometry and the related
support in the qemu driver.
J.B. Joret (3):
qemu: Support for Disk Geometry Override
qemu: Documentation for Disk Geometry Override
qemu: Testcase for Disk Geometry Override
docs/formatdomain.html.in | 25 +++++++
docs/schemas/domaincommon.rng | 28 ++++++++
src/conf/domain_conf.c | 71 ++++++++++++++++++++
src/conf/domain_conf.h | 17 +++++
src/libvirt_private.syms | 2 +
src/qemu/qemu_command.c | 59 ++++++++++++++++
.../qemuxml2argv-disk-geometry.args | 4 +
.../qemuxml2argv-disk-geometry.xml | 26 +++++++
tests/qemuxml2argvtest.c | 2 +
9 files changed, 234 insertions(+), 0 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-geometry.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-geometry.xml
12 years, 3 months
[libvirt] [PATCH] storage: support all file permissions
by Ján Tomko
sticky, setuid and setgid are no longer ignored.
---
src/conf/storage_conf.c | 6 ++++--
src/storage/storage_backend.c | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index 7944555..c492106 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -1035,7 +1035,8 @@ virStoragePoolDefFormat(virStoragePoolDefPtr def) {
virBufferAddLit(&buf," <permissions>\n");
virBufferAsprintf(&buf," <mode>0%o</mode>\n",
- def->target.perms.mode);
+ def->target.perms.mode &
+ (S_ISUID | S_ISGID | S_ISVTX | S_IRWXUGO));
virBufferAsprintf(&buf," <owner>%u</owner>\n",
(unsigned int) def->target.perms.uid);
virBufferAsprintf(&buf," <group>%u</group>\n",
@@ -1275,7 +1276,8 @@ virStorageVolTargetDefFormat(virStorageVolOptionsPtr options,
virBufferAddLit(buf," <permissions>\n");
virBufferAsprintf(buf," <mode>0%o</mode>\n",
- def->perms.mode);
+ def->perms.mode &
+ (S_ISUID | S_ISGID | S_ISVTX | S_IRWXUGO));
virBufferAsprintf(buf," <owner>%u</owner>\n",
(unsigned int) def->perms.uid);
virBufferAsprintf(buf," <group>%u</group>\n",
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
index e677cda..e9ec7a5 100644
--- a/src/storage/storage_backend.c
+++ b/src/storage/storage_backend.c
@@ -1210,7 +1210,8 @@ virStorageBackendUpdateVolTargetInfoFD(virStorageVolTargetPtr target,
}
}
- target->perms.mode = sb.st_mode & S_IRWXUGO;
+ target->perms.mode = sb.st_mode &
+ (S_ISUID | S_ISGID | S_ISVTX | S_IRWXUGO);
target->perms.uid = sb.st_uid;
target->perms.gid = sb.st_gid;
--
1.7.8.6
12 years, 3 months
[libvirt] [PATCH 0/7] qapi: add commands to remove the need to parse -help output
by Anthony Liguori
This series implements the necessary commands to implements danpb's idea to
remove -help parsing in libvirt. We would introduce all of these commands in
1.2 and then change the -help output starting in 1.3.
Here is Dan's plan from a previous thread:
<danpb>
Basically I'd sum up my new idea as "just use QMP".
* No new command line arguments like -capabilities
* libvirt invokes something like
$QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
* libvirt then runs a number of QMP commands to find out
what it needs to know. I'd expect the following existing
commands would be used
- query-version - already supported
- query-commands - already supported
- query-events - already supported
- query-kvm - already supported
- qom-{list,list-types,get} - already supported
- query-spice/vnc - already supported
And add the following new commands
- query-devices - new, -device ?, and/or -device NAME,? data
in QMP
- query-machines - new, -M ? in QMP
- query-cpu-types - new, -cpu ? in QMP
The above would take care of probably 50% of the current libvirt
capabilities probing, including a portion of the -help stuff. Then
there is all the rest of the crap we detect from the -help. We could
just take the view, that "as of 1.2", we assume everything we previously
detected is just available by default, and thus don't need to probe
it. For stuff that is QOM based, I expect we'll be able to detect new
features in the future using the qom-XXX monitor commands. For stuff
that is non-qdev, and non-qom, libvirt can just do a plain version
number check, unless we decide there is specific info worth exposing
via other new 'query-XXX' monitor commands.
Basically I'd sum up my new idea as "just use QMP".
* No new command line arguments like -capabilities
* libvirt invokes something like
$QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
* libvirt then runs a number of QMP commands to find out
what it needs to know. I'd expect the following existing
commands would be used
- query-version - already supported
- query-commands - already supported
- query-events - already supported
- query-kvm - already supported
- qom-{list,list-types,get} - already supported
- query-spice/vnc - already supported
And add the following new commands
- query-devices - new, -device ?, and/or -device NAME,? data
in QMP
- query-machines - new, -M ? in QMP
- query-cpu-types - new, -cpu ? in QMP
The above would take care of probably 50% of the current libvirt
capabilities probing, including a portion of the -help stuff. Then
there is all the rest of the crap we detect from the -help. We could
just take the view, that "as of 1.2", we assume everything we previously
detected is just available by default, and thus don't need to probe
it. For stuff that is QOM based, I expect we'll be able to detect new
features in the future using the qom-XXX monitor commands. For stuff
that is non-qdev, and non-qom, libvirt can just do a plain version
number check, unless we decide there is specific info worth exposing
via other new 'query-XXX' monitor commands.
</danpb>
The one thing to note is that I didn't add a query-devices command because you
can already do:
qmp query-devices --implements=device --abstract=False
To get the equivalent output of -device ?. Instead, I added a command to list
specific properties of a device which is the equivalent of -device FOO,?
12 years, 3 months
[libvirt] [PATCH] [libvirt-java] Fix Array IndexOutOfBoundsException for unknown error codes
by Claudio Bley
Hi.
I sent a few mails on friday, 6th July, via gmane.org but they haven't
made it to the list yet. As I'm a subscriber now, I'm resending them
directly. Sorry for any duplicates in advance.
I'm using libvirt-java 0.4.7 and libvirt 0.9.8.
When libvirt returns an error code which is not mapped in enum
ErrorNumber, an IndexOutOfBoundsException is thrown.
I realize that the freshly released libvirt-java 0.4.8 supports all
error codes up to libvirt 0.9.12. But that doesn't fix the problem.
Would it be feasible to add a special UNKNOWN enum value?
---
diff --git a/src/main/java/org/libvirt/Error.java b/src/main/java/org/libvirt/Error.java
index 0946030..72bc698 100644
--- a/src/main/java/org/libvirt/Error.java
+++ b/src/main/java/org/libvirt/Error.java
@@ -151,9 +151,12 @@ public class Error implements Serializable {
}
public Error(virError vError) {
- code = ErrorNumber.values()[vError.code];
- domain = ErrorDomain.values()[vError.domain];
- level = ErrorLevel.values()[vError.level];
+ if (ErrorNumber.values().length > vError.code)
+ code = ErrorNumber.values()[vError.code];
+ if (ErrorDomain.values().length > vError.domain)
+ domain = ErrorDomain.values()[vError.domain];
+ if (ErrorLevel.values().length > vError.level)
+ level = ErrorLevel.values()[vError.level];
message = vError.message;
str1 = vError.str1;
str2 = vError.str2;
---
Best regards,
Claudio.
--
AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany
Phone: +49 341 265 310 19
Web:<http://www.av-test.org>
Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076)
Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern
12 years, 3 months
[libvirt] [PATCH v5 0/6] file descriptor passing using fd sets
by Corey Bryant
libvirt's sVirt security driver provides SELinux MAC isolation for
Qemu guest processes and their corresponding image files. In other
words, sVirt uses SELinux to prevent a QEMU process from opening
files that do not belong to it.
sVirt provides this support by labeling guests and resources with
security labels that are stored in file system extended attributes.
Some file systems, such as NFS, do not support the extended
attribute security namespace, and therefore cannot support sVirt
isolation.
A solution to this problem is to provide fd passing support, where
libvirt opens files and passes file descriptors to QEMU. This,
along with SELinux policy to prevent QEMU from opening files, can
provide image file isolation for NFS files stored on the same NFS
mount.
This patch series adds the add-fd, remove-fd, and query-fdsets
QMP monitor commands, which allow file descriptors to be passed
via SCM_RIGHTS, and assigned to specified fd sets. This allows
fd sets to be created per file with fds having, for example,
different access rights. When QEMU needs to reopen a file with
different access rights, it can search for a matching fd in the
fd set. Fd sets also allow for easy tracking of fds per file,
helping to prevent fd leaks.
Support is also added to the block layer to allow QEMU to dup an
fd from an fdset when the filename is of the /dev/fdset/nnn format,
where nnn is the fd set ID.
No new SELinux policy is required to prevent open of NFS files
(files with type nfs_t). The virt_use_nfs boolean type simply
needs to be set to false, and open will be prevented (and dup will
be allowed). For example:
# setsebool virt_use_nfs 0
# getsebool virt_use_nfs
virt_use_nfs --> off
Corey Bryant (6):
qemu-char: Add MSG_CMSG_CLOEXEC flag to recvmsg
qapi: Introduce add-fd, remove-fd, query-fdsets
monitor: Clean up fd sets on monitor disconnect
block: Convert open calls to qemu_open
block: Convert close calls to qemu_close
block: Enable qemu_open/close to work with fd sets
block/raw-posix.c | 42 ++++-----
block/raw-win32.c | 6 +-
block/vdi.c | 5 +-
block/vmdk.c | 25 +++---
block/vpc.c | 4 +-
block/vvfat.c | 16 ++--
cutils.c | 5 ++
monitor.c | 244 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
monitor.h | 4 +
osdep.c | 141 +++++++++++++++++++++++++++++++
qapi-schema.json | 97 +++++++++++++++++++++
qemu-char.c | 10 ++-
qemu-common.h | 2 +
qemu-tool.c | 12 +++
qmp-commands.hx | 121 ++++++++++++++++++++++++++
savevm.c | 4 +-
16 files changed, 684 insertions(+), 54 deletions(-)
--
1.7.10.4
12 years, 3 months
[libvirt] [PATCH] qemu_agent: support guest-info command
by MATSUDA, Daiki
Currently, libvirt qemu agent supports some QEMU Guest Agent's commands
or use them. But they are not adapted to communication test to the
Domain OS.
So, QEMU Guest Agent provide 'guest-info' command to display its version
and their commands. And I wrote the codes for supporting it.
virsh # guest-agent-info RHEL62_32
Version: 1.1.0
Commands:
guest-network-get-interfaces
guest-suspend-hybrid
guest-suspend-ram
guest-suspend-disk
guest-fsfreeze-thaw
guest-fsfreeze-freeze
guest-fsfreeze-status
guest-file-flush
guest-file-seek
guest-file-write
guest-file-read
guest-file-close
guest-file-open
guest-shutdown
guest-info
guest-ping
guest-sync
guest-sync-delimited
I am sorry that attached patch is against libvirt-0.9.13-rc1, because my
network environment can not access via git and header code is not built
with the problem gnulib...
Regards
MATSUDA Daiki
12 years, 3 months
