[libvirt] [PATCH] qemu: raise an error when trying to use readonly ide disks
by Giuseppe Scrivano
The IDE bus doesn't support readonly disks, so inform the user with an
error message instead of let qemu fail with a more obscure "Device
'ide-hd' could not be initialized" error message.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1112939
Signed-off-by: Giuseppe Scrivano <gscrivan(a)redhat.com>
---
src/qemu/qemu_command.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 63f322a..4829176 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3385,8 +3385,15 @@ qemuBuildDriveStr(virConnectPtr conn,
disk->bus != VIR_DOMAIN_DISK_BUS_IDE)
virBufferAddLit(&opt, ",boot=on");
if (disk->readonly &&
- virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_READONLY))
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_READONLY)) {
+ if (disk->bus == VIR_DOMAIN_DISK_BUS_IDE &&
+ disk->device == VIR_DOMAIN_DISK_DEVICE_DISK) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("readonly ide disks are not supported"));
+ goto error;
+ }
virBufferAddLit(&opt, ",readonly=on");
+ }
if (disk->transient) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("transient disks not supported yet"));
--
1.9.3
10 years, 4 months
[libvirt] [PATCHv4 00/29] (for 1.2.7) qemu: Refactor handling of disk image metadata
by Peter Krempa
This is meant for the 1.2.7 release as we are currently in freeze for 1.2.6.
This version incorporates feedback from Eric's review and adds a ton of new stuff.
Peter Krempa (29):
storage: Implement virStorageFileCreate for local and gluster files
qemu: Don't propagate whole disk definition into qemuDomainGetImageIds
qemu: Add helper to initialize storage file backend with correct
uid/gid
storage: file: Tolerate NULL src when uninitializing the backend
conf: Don't output seclabels for backingStore elements
storage: Move readonly and shared flags to disk source from disk def
util: storagefile: Add deep copy for struct virStorageSource
util: storage: Add helper to determine whether storage is local
util: storage: Add function to transfer config parts to new chain
element
util: storage: Copy parent's disk metadata to backing chain elements
util: cgroup: Add helper to convert device mode to string
qemu: cgroup: Add functions to set cgroup image stuff on individual
imgs
qemu: cgroup: Setup only the top level disk image for read-write
access
locking: Add APIs to lock individual image files
security: Introduce APIs to label single images
security: selinux: Implement per-image seclabel restore
security: selinux: Implement per-image seclabel set
security: DAC: Implement per-image seclabel restore
security: DAC: Implement per-image seclabel set
security: AppArmor: Implement per-image seclabel restore
security: AppArmor: Implement per-image seclabel set
util: storage: Make virStorageFileChainLookup more network storage
aware
util: storage: Return complete parent info from
virStorageFileChainLookup
qemu: blockcopy: Use the mirror disk source to label the files
qemu: block: Properly track disk source while pivotting to new image
qemu: snapshot: Improve approach to deal with snapshot metadata
qemu: Refactor qemuDomainPrepareDiskChainElement
qemu: snapshot: Refactor image labelling of new snapshot files
qemu: snapshot: Use storage driver to pre-create snapshot file
src/conf/domain_conf.c | 77 +++++---
src/conf/domain_conf.h | 2 -
src/libvirt_private.syms | 8 +
src/libxl/libxl_conf.c | 2 +-
src/locking/domain_lock.c | 65 ++++---
src/locking/domain_lock.h | 8 +
src/lxc/lxc_cgroup.c | 2 +-
src/lxc/lxc_controller.c | 2 +-
src/lxc/lxc_driver.c | 2 +-
src/qemu/qemu_cgroup.c | 109 ++++++-----
src/qemu/qemu_cgroup.h | 3 +
src/qemu/qemu_command.c | 14 +-
src/qemu/qemu_conf.c | 4 +-
src/qemu/qemu_domain.c | 29 ++-
src/qemu/qemu_domain.h | 4 +
src/qemu/qemu_driver.c | 349 +++++++++++-----------------------
src/qemu/qemu_migration.c | 16 +-
src/security/security_apparmor.c | 55 ++++--
src/security/security_dac.c | 111 +++++------
src/security/security_driver.h | 10 +
src/security/security_manager.c | 56 ++++++
src/security/security_manager.h | 7 +
src/security/security_nop.c | 19 ++
src/security/security_selinux.c | 150 +++++++++------
src/security/security_stack.c | 38 ++++
src/security/virt-aa-helper.c | 2 +-
src/storage/storage_backend_fs.c | 17 ++
src/storage/storage_backend_gluster.c | 28 +++
src/storage/storage_driver.c | 2 +-
src/util/vircgroup.c | 62 ++++--
src/util/vircgroup.h | 2 +
src/util/virstoragefile.c | 300 ++++++++++++++++++++++++++---
src/util/virstoragefile.h | 15 +-
src/vbox/vbox_tmpl.c | 30 +--
src/xenxs/xen_sxpr.c | 10 +-
src/xenxs/xen_xm.c | 10 +-
tests/virstoragetest.c | 86 ++++-----
37 files changed, 1097 insertions(+), 609 deletions(-)
--
1.9.3
10 years, 4 months
[libvirt] [PATCH] libxl: add PV console if not explicitly specified
by Jim Fehlig
Xen PV domains always have a PV console, so add one to the domain
config via post-parse callback if not explicitly specified in
the XML. The legacy Xen driver behaves similarly, causing a
regression when switching to the new Xen toolstack. I.e.
virsh console pv-domain
will no longer work after upgrading a xm/xend stack to xl/libxl.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
src/libxl/libxl_domain.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index da3f241..0c86601 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -503,9 +503,38 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
return 0;
}
+static int
+libxlDomainDefPostParse(virDomainDefPtr def,
+ virCapsPtr caps ATTRIBUTE_UNUSED,
+ void *opaque ATTRIBUTE_UNUSED)
+{
+ if (STREQ(def->os.type, "hvm"))
+ return 0;
+
+ if (def->nconsoles == 0) {
+ virDomainChrDefPtr chrdef;
+
+ if (!(chrdef = virDomainChrDefNew()))
+ return -1;
+
+ chrdef->source.type = VIR_DOMAIN_CHR_TYPE_PTY;
+ chrdef->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE;
+ chrdef->target.port = 0;
+ chrdef->targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_XEN;
+
+ if (VIR_ALLOC_N(def->consoles, 1) < 0)
+ return -1;
+
+ def->nconsoles = 1;
+ def->consoles[0] = chrdef;
+ }
+ return 0;
+}
+
virDomainDefParserConfig libxlDomainDefParserConfig = {
.macPrefix = { 0x00, 0x16, 0x3e },
.devicesPostParseCallback = libxlDomainDeviceDefPostParse,
+ .domainPostParseCallback = libxlDomainDefPostParse,
};
--
1.8.4.5
10 years, 4 months
[libvirt] [PATCH] vbox: fix linker error
by Jim Fehlig
Noticed the following error when building the vbox driver
in the openSUSE build service
CCLD vboxsnapshotxmltest
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
../src/.libs/libvirt_driver_vbox_impl.a
(libvirt_driver_vbox_impl_la-vbox_snapshot_conf.o):
undefined reference to symbol 'xmlXPathRegisterNs@(a)LIBXML2_2.4.30'
/usr/lib64/libxml2.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Fixed by adding LIBXML_LIBS to libvirt_driver_vbox_impl_la_LIBADD
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
Oddly, I don't see this when doing local builds, but haven't really
found out what is different between my build environments.
src/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 2b9ac61..10c35d7 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1143,7 +1143,7 @@ libvirt_driver_vbox_impl_la_CFLAGS = \
-I$(top_srcdir)/src/conf \
$(AM_CFLAGS)
libvirt_driver_vbox_impl_la_LDFLAGS = $(AM_LDFLAGS)
-libvirt_driver_vbox_impl_la_LIBADD = $(DLOPEN_LIBS) $(MSCOM_LIBS)
+libvirt_driver_vbox_impl_la_LIBADD = $(DLOPEN_LIBS) $(MSCOM_LIBS) $(LIBXML_LIBS)
libvirt_driver_vbox_impl_la_SOURCES = $(VBOX_DRIVER_SOURCES)
endif WITH_VBOX
--
1.8.4.5
10 years, 4 months
[libvirt] [libvirt-glib] [PATCH v3 0/3] Add API to fetch snapshots
by Timm Bäder
This patchset replaces the old one and includes
gvir_domain_fetch_snapshtos_async as well as a version of
gvir_domain_fetch_snapshots that works with it.
Timm Bäder (3):
libvirt-gobject-domain: Add _fetch_snapshots
libvirt-gobject-domain: Add _get_snapshots
GVirDomain: Add async version of _fetch_snapshots
libvirt-gobject/libvirt-gobject-domain.c | 164 +++++++++++++++++++++++++++++++
libvirt-gobject/libvirt-gobject-domain.h | 51 ++++++++++
libvirt-gobject/libvirt-gobject.sym | 5 +
3 files changed, 220 insertions(+)
--
2.0.1
10 years, 4 months
Re: [libvirt] [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt
by Dario Faggioli
On lun, 2014-06-30 at 08:11 +0100, Ian Campbell wrote:
> On Sun, 2014-06-29 at 18:35 +0100, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job build-i386-libvirt
> > test libvirt-build
> >
> > Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetc...
> > Tree: libvirt git://xenbits.xen.org/libvirt.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen git://xenbits.xen.org/xen.git
> >
> > *** Found and reproduced problem changeset ***
> >
> > Bug is in tree: xen git://xenbits.xen.org/xen.git
> > Bug introduced: 871b43a309d80ac99458c13c2c3da8d15c482d30
> > Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199
> >
> >
> > commit 871b43a309d80ac99458c13c2c3da8d15c482d30
> > Author: Dario Faggioli <dario.faggioli(a)citrix.com>
> > Date: Fri Jun 20 18:19:12 2014 +0200
> >
> > libxl: get and set soft affinity
>
> Dario,
>
> libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
> LIBXL_HAVE stuff to retain compatibility.
>
> Will you be able to send a patch against libvirt today to make it use
> the new interface (conditional on LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY)?
>
So, brief recap for the ones not knowing the details of this, libxl
interface for vcpu pinning is changing (basically,
libxl_set_vcpuaffinity() wants one more param).
Libxl provides some ifdefs for these situations, and in this case, the
gate to be used is, as Ian is saying:
#ifdef LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY
One possible approach is to enclose all the calls into such
#ifdef-#endif but, although there are only two of them right now, I
don't like it (what if we need more calls in the future?).
I could come up with the alternatives attached to this message. In
patch1, I use the new interface in the code and #define it to the old
one if !LIBXL_HAV_VCPUINFO_SOFT_AFFINITY. In patch2 I do the opposite
(keep old interface in the code and redefine to new, with additional
param equal to NULL).
I like patch1 better, but I think it can cause "unused variable" like
warnings if, at some point in future, we will actually use the new soft
affinity parameter, when compiling on a version of libxl that does not
define HAVE_VCPUINFO_SOFT_AFFINITY, can't it? If yes, is it an issue? If
yes, a big enough one to make us prefer patch2?
Just let me know your thoughts, and I'll submit the one you prefer
appropriately.
Regards,
Dario
PS. patches not tested, I'm updating my xen+libvirt testbox. Will be
able to test soon (for sure within today)
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
10 years, 4 months
[libvirt] [PATCH v7 RFC 0/2] libxl USB prototype and design discussion
by George Dunlap
Hey all!
So here I finally have a rebased the HVM USB hotplug series from last
year. I went through and addressed all of IanC's technical comments
that I could; so it should be in much better shape than it was.
However, one of the unfinished threads of the conversation at that
time was about the interface. In particular since Simon Bo is now
working on the PVUSB side of things, I thought it would be good to
review the situation so we can get an interface we're happy with.
In order to really answer the questions, I went through and looked at
the underlying capabilities of QEMU and PVUSB, at the existing libxl
and xend interfaces for those two, and also at the libvirt interface.
I summarize what I've found here; but if you want a TLDR version, just
skip to the bottom, where it says "Draft Design Proposal". But before
asking any questions or making any criticisms, please go back and read
the appropriate summary section.
References are at the very bottom of the e-mail.
This can be found at the following address:
git://xenbits.xen.org/people/gdunlap/xen.git out/hvm-usb-hotplug-v7-RFC
== Capabilities of QEMU ==
Qemu has the additional ability to not only pass through host devices,
but other kinds of devices -- tablets, mice, keyboards, drives, hubs,
and so on. As far as I know, PVUSB can only do host device
pass-through at the moment. (Although you could certainly imagine
that changing; if qemu was taught how to become a PVUSB back-end, for
example.)
qemu has two ways of specifying usb devices. The "legacy" method can
be specified on the qemu command-line or via the qemu monitor. It is
limited to USB 1.1. The new "qdevice" method can be used either on
the command-line or via qmp.
qemu-traditional only supports the legacy method. qemu-xen still
supports the legacy method via command-line, but we should try to
start using the qdevice method if we can.
qemu-xen has the ability to create virtual USB 2.0 or 3.0 controllers.
These can be named, and it is possible to specify (to a certain level)
which controller to plug a device into. These can be created either
via the command-line, or hot-plugged via qmp.
qemu also seems to be willing to shift things around behind the scenes
to be able to handle your request; shifting around the USB topology,
for instance. It will also do "helpful" things; for instance, if you
specify that you want to plug a device into a USB 2.0 controller, and
the device is only 1.1 capable, it will ignore what you asked and plug
it into the 1.1 controller.
== Capabilities of PVUSB ==
PVUSB also requires you to first create a virtual controller, before
attaching host devices to it. There is some flexibility in how to
create these, and you can create more than one and specify which
virtual bus to attach the host device. You seem to be able to specify
the USB version number when you specify the controller as well. You
can also specify the number of ports for a device; I'm not sure what
the maximum number of ports per controller is, or why you would ever
really want to have less than the maximum number of ports.
It looks like in the xm interface, when you create a virtual
controller it is assigned an index, starting at 0; and this is the
index that is used when specifying where to plug in a device.
(Simon, can you please correct this if I'm wrong, and add anything
important that I missed?)
== libxl/xl interface ==
At the moment, libxl/xl only support USB at domain creation time.
For HVM guests, we have two incompatible sets of options. usb=1 and
usbdevice=[] use the "old-style" qemu interface on the qemu
command-line. The "old-style" interface can only be used to specify
USB 1.1 devices. We also have "usbversion=[foo]", which uses the
"new-style" device specification commands. These new specification
commands *can* be specified either on the qemu command-line or via
qmp; but at the moment libxl specifies them on the command-line.
The patch series attached specifes using the new-style interface via
qmp. (This seems to work properly with the various controllers no
matter how they were created.) In theory, we should be able to attach
these devices during domain creation, after qemu has been started but
before the guest is running.
Obviously, we would ideally like for the user not to have to worry
about a lot of this complexity, and just say, "Can you pass this
device through to the guest? Thanks."
Another thing to consider in the design space is config file and
start-up behavior.
== Libvirt's interface ==
I've had a brief look at libvirt's USB interface, and learned a bit
about libvirt's general approach to things at the Xen Hackathon last
week. One of the goals of libvirt is to be able to specify the
virtual hardware in enough detail to keep it from changing when you
upgrade the hypervisor, so that certain proprietary operating systems
which are sensitive to this kind of thing continue to work.
Instead of specifying a controller name, you specify a controller
index (which is different than qemu). But instead of specifying a USB
version number, you specify a model for the USB controller (which
happens to be the exact name that qemu uses): "piix3-uhci",
"piix4-uhci", "ehci", "ich9-ehci1", "ich9-uhci1", "ich9-uhci2",
"ich9-uhci3", "vt82c686b-uhci", "pci-ohci" or "nec-xhci".
When specifying a USB device, libvirt has the concept of an "address"
where you will plug it into. Here is what the page says about it:
"USB addresses have the following additional attributes: bus (a hex
value between 0 and 0xfff, inclusive), and port (a dotted notation of
up to four octets, such as 1.2 or 2.1.3.1)."
It's not exactly clear to me what those numbers mean. But after
chatting with Daniel Berrange at the Hackathon, it looks like the
"bus" in the address corresponds to the "index" in the controller
specification. It also appears that this "index" is internal to
libvirt and is not exposed to the guest: so it should in theory be
possible to have index 0 be a Xen PVUSB controller, 1 be an emulated
qemu controller, 3 be an emulated PVUSB controller, and so on.
== Open questions ==
Those are things I think I know; there are a couple of pertinent
factual questions which I'm not sure of:
* Is it possible to specify PVUSB controllers and attach USB devices
to them before the guest is up and running (i.e., before the frontend
is connected)? It looks like xend had a syntax for specifying virtual
controllers and attaching virtual devices, so it seems like it should
be possible.
* Is it possible to connect a USB 1.1 device to a PVUSB controller
which has been specified 2.0, or would there have to be a separate
virtual controller for each?
* Is it possible for the toolstack to tell if dom0 (or whatever the
specified backend domain) has PVUSB support before starting the guest?
* Is it possible for the toolstack to tell if domU has a working and
connected PVUSB front-end?
* Do we want to be able to create virtual hubs for qemu-backed
controllers at some point in the future? Is there any groundwork we
want to lay for that?
== Design questions ==
Then based on that, we have several design questions.
* How much of the "controller" thing should be exposed via libxl? Via xl?
* This series only allows you to specify the "protocol", either PV or
DEVICE_MODEL. Would it be better, for instance, to get rid of that,
and instead allow the user to specify the creation of USB controllers,
allow them to have a type of "HCI (or emulated)" or "PV", and allow
the user to specify which controller to attach a specific device to?
* How much "smarts" should we have in the libxl / xl about creating
emulated/virtual controllers and of what kinds?
* How much / what kind of "smarts" should be in libxl / xl about
choosing a controller to plug a device into?
* What about config file syntax? Should we try to reuse / extend the
current config syntax, or create a new one? Should the new one allow
the specification of controllers? Should it perhaps *require* the
specification of controllers?
== Draft design proposal ==
I've given it some thought, and based on the below is a suggested
design for people to have a go at.
Basic idea: Specify named controllers. It's controllers that are PV
or emulated, and may have a backend domain. When adding devices,
specify which controller to attach it to. Allow most things to have
intelligent defaults.
* libxl functions
usb_controller_add
usb_controller_remove/destroy
usb_controller_list
device struct:
name # If empty, default to hciN/pvN, where N starts at 0
type = {PV, EMULATED, AUTO}
backend_{domname,domid} # PV only
usbversion = {1, 2, 3}
numports # default 16
If type==AUTO, then it will be PV for a PV domain, EMULATED for an HVM domain.
usb_add
usb_remove/destroy
usb_list
device struct:
controller_name # If empty, choose one of the controllers.
type
hostdev
hostbus,hostaddr
Note: I've removed backend from the device struct, as that will be
based on the controller.
* Storing information about virtual USB controllers / devices
qemu does not at the moment have a way to query for plugged-in
devices. I'm not sure if PVUSB does. Store information about both
USB controllers and USB devices created with libxl in xenstore,
somewhat similar to the system in the attached patches.
* Domain creation
I think what we add to the domain creation libxl calls will be obvious
from how we design the config file interface.
For reference, here are some example config snippets from the current
xl / xm config files:
-- snip --
# HVM USB
usb=1
usbdevice=['tablet','host:4.3']
# HVM USB, not compatible with the above
usbversion=3
# xend's PVUSB config file; this creates one virtual controller, then
# plugs hostdev 1.8 into port 1
vusb=['usbver=2, numports=4, port_1=1-8']
-- snip --
Given that, here is a potential config file format:
-- snip --
# Create two controllers, one pv, one emulated
usbcontroller=['type=pv,name=pv0,usbversion=2,numports=4',
'type=emul,name=hci0,usbversion=2']
# Create a controller with the defaults; PV for PV guests, emul for HVM guests
usbcontroller=['']
# Same as above, but defaulting to version 2
usbversion=2
# I think we should be able to automatically detect which format to
# use; so I think we should re-use usbdevice. I could be convinced otherwise.
usbdevice=['type=tablet','type=hostdev,hostaddr=4.3,bus=pv0']
-- snip --
Other ideas:
* To make the interface closer to libvirt's, instead of specifying PV
/ EMULATED and usbversion, just specify a model. Then create
"pvusb-v1", "pvusb-v2", &c for PVUSB hubs with the various versions,
and detect automatically whether to use the PV or the qemu path. (NB
that at the libvirt level, to fit with their syntax, we'd probably end
up creating a "xenpvusbN" model in libvirt that would translate down
to whatever the appropriate thing is in libxl.)
* Rather than having to specify a controller, automatically hot-plug
controllers as-needed.
* Include an optional port number into which we will plug the USB
device.
Thoughts?
-George
== References ==
Last time this was posted:
http://thread.gmane.org/gmane.comp.emulators.xen.devel/156796
PVUSB references:
http://doc.opensuse.org/products/draft/SLES/SLES-xen_sd_draft/cha.xen.con...
Libvirt references:
http://wiki.libvirt.org/page/QEMUSwitchToLibvirt#-usbdevice
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Lin...
http://libvirt.org/formatdomain.html
http://libvirt.org/formatdomain.html#elementsControllers
CC: Ian Jackson <ian.jackson(a)citrix.com>
CC: Roger Pau Monne <roger.pau(a)citrix.com>
CC: sstanisi(a)cbnco.com
CC: Fabio Fantoni <fabio.fantoni(a)m2r.biz>
CC: Ian Campbell <ian.campbell(a)citrix.com>
CC: Anthony Perard <anthony.perard(a)citrix.com>
CC: Simon (Bo) Cao <caobosimon(a)gmail.com>
CC: LibVirt Development List <libvir-list(a)redhat.com>
CC: Jim Fehlig <jfehlig(a)suse.com>
CC: Daniel P. Berrange <berrange(a)redhat.com>
10 years, 4 months
[libvirt] [python PATCH] maint: document development against uninstalled libvirt
by Eric Blake
Thanks to Dan's recent work in libvirt.git, it is much easier to
develop against uninstalled libvirt. Mention how.
* README: More details.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
README | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/README b/README
index ad50828..df1de59 100644
--- a/README
+++ b/README
@@ -21,6 +21,21 @@ or to install as non-root
python setup.py build
python setup.py install --user
+If python-nose is installed, you can test the package with
+
+ python setup.py test
+
+A makefile shim is provided so that you can do
+
+ make && make check
+
+rather than directly invoking setup.py.
+
+As of libvirt 1.2.6, it is possible to develop against an uninstalled
+libvirt.git checkout, by setting some environment variables:
+
+ export PKG_CONFIG_PATH=/path/to/libvirt/git/src/
+ export LD_LIBRARY_PATH=/path/to/libvirt/git/src/.libs/
Patches for this code should be sent to the main libvirt
development mailing list
--
1.9.3
10 years, 4 months
[libvirt] [PATCH] LXC: throw an error if we failed to get Idmap elements
by Chen Hanxiao
Throwing an error is much friendly than just
"error: An error occurred, but the cause is unknown"
Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com>
---
src/conf/domain_conf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index b7aa4f5..fa64dc1 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -10983,6 +10983,8 @@ virDomainIdmapDefParseXML(xmlXPathContextPtr ctxt,
if (virXPathUInt("string(./@start)", ctxt, &idmap[i].start) < 0 ||
virXPathUInt("string(./@target)", ctxt, &idmap[i].target) < 0 ||
virXPathUInt("string(./@count)", ctxt, &idmap[i].count) < 0) {
+ virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("invalid idmap start/target/count settings"));
VIR_FREE(idmap);
goto cleanup;
}
--
1.9.0
10 years, 4 months
[libvirt] [sVirt] Question about virSecuritySELinuxSetSecurityAllLabel()
by H Changyao
Hi,
I am studying sVirt,i have some questions about
virSecuritySELinuxSetSecurityAllLabel() function (below AllLabel()
instead)in src/security/security_selinux.c.
>From some materials, i have understood how sVirt works.
AllLabel() is responsible to label "object",in most materials,
"object" represents image files, howerver, in AllLabel(),i find there
are some other "object"(Hostdev,TPMFile,Chardev,Smartcard,os.kernel,
os.initrd,os.dtb) to be labeled.
I have question about the scope of "object",besides labeling image
files,is those other object necessary to be labeled to guarantee sVirt
to achieve strong isolation.
10 years, 4 months
