Am 01.05.2012 22:25, schrieb Anthony Liguori:
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict the QEMU process and
prevent
it from opening files that it should not have access to. This improves
security
Am 02.05.2012 10:27, schrieb Stefan Hajnoczi:
On Wed, May 2, 2012 at 9:20 AM, Kevin Wolf kw...@redhat.com wrote:
Am 01.05.2012 22:25, schrieb Anthony Liguori:
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict
Am 02.05.2012 10:53, schrieb Daniel P. Berrange:
On Wed, May 02, 2012 at 10:20:17AM +0200, Kevin Wolf wrote:
Am 01.05.2012 22:25, schrieb Anthony Liguori:
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict
Am 04.03.2013 um 14:09 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 01:58:12PM +0100, Ján Tomko wrote:
Before posting another version of my patches [1], attempting to add
support for the new qcow format to libvirt, I would like to know if this
sounds reasonable:
A new
Am 04.03.2013 um 15:27 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 03:04:53PM +0100, Kevin Wolf wrote:
Am 04.03.2013 um 14:09 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 01:58:12PM +0100, Ján Tomko wrote:
Before posting another version of my patches [1
Am 04.03.2013 um 15:46 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 03:38:54PM +0100, Kevin Wolf wrote:
Am 04.03.2013 um 15:27 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 03:04:53PM +0100, Kevin Wolf wrote:
Am 04.03.2013 um 14:09 hat Daniel P. Berrange
Am 04.03.2013 um 16:19 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 04:05:50PM +0100, Kevin Wolf wrote:
Am 04.03.2013 um 15:46 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 03:38:54PM +0100, Kevin Wolf wrote:
Am 04.03.2013 um 15:27 hat Daniel P. Berrange
Am 11.03.2013 um 19:03 hat Ján Tomko geschrieben:
On 03/04/2013 04:40 PM, Kevin Wolf wrote:
Am 04.03.2013 um 16:19 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 04:05:50PM +0100, Kevin Wolf wrote:
I'm not talking about the QEMU cli, but about qcow2 as the format as
defined
Am 04.11.2013 um 08:01 hat Amos Kong geschrieben:
Currently we have three QemuOptsList (qemu_common_drive_opts,
qemu_legacy_drive_opts, and qemu_drive_opts), only qemu_drive_opts
is added to vm_config_groups[].
We query commandline options by checking information in
vm_config_groups[], so
Am 09.11.2013 um 05:15 hat Amos Kong geschrieben:
Currently we have three QemuOptsList (qemu_common_drive_opts,
qemu_legacy_drive_opts, and qemu_drive_opts), only qemu_drive_opts
is added to vm_config_groups[].
This patch changes query-command-line-options to access three local
Am 21.05.2012 22:19, schrieb 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
Am 22.05.2012 14:02, schrieb Eric Blake:
On 05/22/2012 02:18 AM, Kevin Wolf wrote:
This patch series adds the -filefd command-line option and the
getfd_file monitor command. This will enable libvirt to open a
file and push the corresponding filename and file descriptor to
QEMU. When QEMU
Am 22.05.2012 15:25, schrieb Corey Bryant:
On 05/21/2012 05:40 PM, Eric Blake wrote:
On 05/21/2012 02:19 PM, Corey Bryant wrote:
This patch provides support for the -filefd command line option.
This option will allow passing of a filename and its corresponding
file descriptor to QEMU at
Am 22.05.2012 16:26, schrieb Stefan Hajnoczi:
On Tue, May 22, 2012 at 2:38 PM, Kevin Wolf kw...@redhat.com wrote:
Am 22.05.2012 15:25, schrieb Corey Bryant:
On 05/21/2012 05:40 PM, Eric Blake wrote:
On 05/21/2012 02:19 PM, Corey Bryant wrote:
This patch provides support for the -filefd
Am 22.05.2012 16:30, schrieb Corey Bryant:
On 05/22/2012 04:18 AM, Kevin Wolf wrote:
Am 21.05.2012 22:19, schrieb 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
Am 22.05.2012 17:01, schrieb Eric Blake:
On 05/22/2012 08:45 AM, Kevin Wolf wrote:
I understand that open(/dev/fd/42) would be the same as dup(42), but
I'm not sure that I'm entirely clear on how this would work. Could you
give an example?
With your approach you open the file outside
Am 22.05.2012 17:29, schrieb Corey Bryant:
On 05/22/2012 10:45 AM, Kevin Wolf wrote:
Am 22.05.2012 16:30, schrieb Corey Bryant:
On 05/22/2012 04:18 AM, Kevin Wolf wrote:
Am 21.05.2012 22:19, schrieb Corey Bryant:
libvirt's sVirt security driver provides SELinux MAC isolation for
Qemu
Am 08.06.2012 17:42, schrieb 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
Am 08.06.2012 17:42, schrieb Corey Bryant:
This patch converts all block layer open calls to qemu_open. This
enables all block layer open paths to dup(X) a pre-opened file
descriptor if the filename is of the format /dev/fd/X. This is
useful if QEMU is restricted from opening certain files.
Am 15.06.2012 20:16, schrieb Corey Bryant:
On 06/15/2012 11:16 AM, Eric Blake wrote:
On 06/14/2012 09:55 AM, Corey Bryant wrote:
This patch adds support to qemu_open to dup(fd) a pre-opened file
descriptor if the filename is of the format /dev/fd/X.
+++ b/osdep.c
@@ -82,6 +82,19 @@ int
Am 15.06.2012 22:00, schrieb Eric Blake:
On 06/15/2012 01:19 PM, Corey Bryant wrote:
There are some flags that I don't think we'll be able to change. For
example: O_RDONLY, O_WRONLY, O_RDWR. I assume libvirt would open all
files O_RDWR.
I think we need to check all of them and fail
Am 25.06.2012 16:34, schrieb Eric Blake:
Also, I noticed in the fnctl man page that F_SETFL: On Linux this
command can change only the O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, and
O_NONBLOCK flags. So I'll only set/unset these flags.
O_NDELAY is the obsolete spelling of O_NONBLOCK; which
Am 25.06.2012 16:51, schrieb Corey Bryant:
Thanks for catching this. I'll fix this in v5. In terms of platforms
that support dup3 vs dup2, I'm assuming the following preprocessor
checks will do what we need:
#if defined(__linux__) || defined(__CYGWIN__)
dup3(fd, monfd-fd, O_CLOEXEC)
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing from libvirt and wanted to raise one idea for discussion
before we continue.
With this proposed series, we have usage akin to:
1. pass_fd FDSET={M} - returns a
Am 27.06.2012 00:28, schrieb Corey Bryant:
On 06/26/2012 04:50 PM, Luiz Capitulino wrote:
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing from
Am 26.06.2012 20:40, schrieb Corey Bryant:
Here is a quick proof of concept (ie untested) patch to demonstrate
what I mean. It relies on Cory's patch which converts everything
to use qemu_open. It is also still valuable to make the change
to qemu_open() to support /dev/fd/N for passing FDs
Am 27.06.2012 00:54, schrieb Eric Blake:
It seems like libvirt would be in a better position to understand when a
file is no longer in use, and then it can call close_fd. No? Of course
the the only fd that needs to be closed is the originally passed fd. The
dup'd fd's are closed by QEMU.
Am 27.06.2012 11:20, schrieb Daniel P. Berrange:
On Wed, Jun 27, 2012 at 11:16:32AM +0200, Kevin Wolf wrote:
The really bad case that nobody thought of is that, when block-commit
has finished, we need to switch back to read-only. This is an event that
is not triggered by a certain monitor
Am 03.07.2012 00:31, schrieb Eric Blake:
On 07/02/2012 04:02 PM, Corey Bryant wrote:
Here's another option that Kevin and I discussed today on IRC. I've
modified a few minor details since the discussion. And Kevin please
correct me if anything is wrong.
Proposal Four: Pass a set of fds
Am 03.07.2012 17:40, schrieb Corey Bryant:
Thanks again for taking time to discuss this at today's QEMU community call.
Here's the proposal we discussed at the call. Please let me know if I
missed anything or if there are any issues with this design.
Proposal Five: New monitor commands
Am 03.07.2012 19:03, schrieb Eric Blake:
2. drive_add file=/dev/fdset/1 - qemu_open uses the first fd from the
set that has access flags matching the qemu_open action flags.
qemu_open increments refcount for this fd.
3. add-fd /dev/fdset/1 FDSET={M} - qemu adds fd to set named
/dev/fdset/1 -
Am 03.07.2012 20:21, schrieb Corey Bryant:
On 07/03/2012 02:00 PM, Eric Blake wrote:
On 07/03/2012 11:46 AM, Corey Bryant wrote:
Yes, I think adding a +1 to the refcount for the monitor makes sense.
I'm a bit unsure how to increment the refcount when a monitor reconnects
though. Maybe it
Am 05.07.2012 16:22, schrieb Corey Bryant:
For some examples:
1. client calls 'add-fd', qemu is now tracking fd=4 with refcount 1, in
use by monitor, as member of fdset1
2. client crashes, so all tracked fds are visited; fd=4 had not yet been
passed to 'remove-fd', so qemu decrements
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2. client calls 'device-add' with /dev/fdset/1 as the backing filename,
so qemu_open()
Am 05.07.2012 18:37, schrieb Corey Bryant:
There is one case I'm aware of where we need to be careful: Before
opening an image, qemu may probe the format. In this case, the image
gets opened twice, and the first close comes before the second open.
I'm
not entirely sure how hard it would be to
Am 06.07.2012 19:40, schrieb Corey Bryant:
On 07/06/2012 05:11 AM, Kevin Wolf wrote:
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2
Am 09.07.2012 17:23, schrieb Corey Bryant:
I think it would cause fds to sit on the monitor
until refcount gets to zero (monitor disconnects). Here's an example
without the in-use flag:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 1 (incremented because of
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so I'll paste the current
design that I am working from. Please let me know if you still see any
issues.
FD passing:
---
Am 09.07.2012 19:35, schrieb Corey Bryant:
On 07/09/2012 11:46 AM, Kevin Wolf wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so I'll paste the current
design that I am
Am 09.07.2012 20:40, schrieb Anthony Liguori:
On 06/26/2012 04:10 AM, Daniel P. Berrange wrote:
On Fri, Jun 22, 2012 at 02:36:07PM -0400, Corey Bryant wrote:
libvirt's sVirt security driver provides SELinux MAC isolation for
Qemu guest processes and their corresponding image files. In other
Am 23.07.2012 15:07, schrieb Corey Bryant:
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
Am 23.07.2012 15:08, schrieb Corey Bryant:
When qemu_open is passed a filename of the /dev/fdset/nnn
format (where nnn is the fdset ID), an fd with matching access
mode flags will be searched for within the specified monitor
fd set. If the fd is found, a dup of the fd will be returned
from
Am 25.07.2012 05:41, schrieb Corey Bryant:
diff --git a/block/raw-posix.c b/block/raw-posix.c
index a172de3..5d0a801 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -271,7 +271,7 @@ static int raw_open_common(BlockDriverState *bs, const
char *filename,
out_free_buf:
Am 15.07.2011 12:50, schrieb Stefan Hajnoczi:
On Thu, Jul 14, 2011 at 7:54 PM, Adam Litke a...@us.ibm.com wrote:
On 07/14/2011 05:33 AM, Stefan Hajnoczi wrote:
On Thu, Jul 14, 2011 at 11:19 AM, Jiri Denemark jdene...@redhat.com wrote:
On Thu, Jul 14, 2011 at 10:58:31 +0100, Stefan Hajnoczi
Am 19.07.2011 18:46, schrieb Daniel P. Berrange:
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen jes.soren...@redhat.com
wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen
Am 20.07.2011 10:25, schrieb Jes Sorensen:
On 07/19/11 18:14, Anthony Liguori wrote:
As nice as that sentiment is, it will never fly, because it would be a
regression in current behavior. The whole reason that the virt_use_nfs
SELinux bool exists is that some people are willing to make the
Am 20.07.2011 15:12, schrieb Stefan Hajnoczi:
On Wed, Jul 20, 2011 at 2:00 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Mon, Jul 18, 2011 at 9:10 PM, Adam Litke a...@us.ibm.com wrote:
On 07/18/2011 09:35 AM, Stefan Hajnoczi wrote:
On the other hand I suspect that we are missing the
Am 20.07.2011 15:25, schrieb Jes Sorensen:
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the problem. In a sane world we would simply
say 'no NFS, no selinux', but as you say that will never happen.
My
Am 20.07.2011 19:47, schrieb Eric Blake:
We really _do_ need a way to give qemu both an fd and the name of the
file that the fd is tied to. On Linux, qemu could use /proc/self/fd to
reconstruct the name from fd, but that's not portable to other OS.
Is there any reason for qemu to know the
Am 20.07.2011 19:20, schrieb Blue Swirl:
On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf kw...@redhat.com wrote:
Am 20.07.2011 15:25, schrieb Jes Sorensen:
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around
Am 21.07.2011 10:07, schrieb Jes Sorensen:
On 07/20/11 21:51, Blue Swirl wrote:
And the snapshot_blkdev monitor command is a case where qemu needs to create
a new qcow2 image on the fly, while referencing the name of an existing
file. What backing name do you put in the new qcow2 file unless
Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
Thank you for persisting - you've found another hole that needs to be
plugged. It sounds like you are proposing that after a qemu process dies,
that libvirt re-reads the qcow2
Am 22.07.2011 09:36, schrieb Avi Kivity:
On 07/20/2011 04:51 PM, Kevin Wolf wrote:
The problem is that QEMU will find backing file file names inside the
images which it will be unable to open. How do you suggest we get around
that?
This is the part with allowing libvirt to override
Am 26.07.2011 15:02, schrieb Christoph Hellwig:
I have to say I really hate it. We've been working hard on getting rid
of special cases in the qemu block layer, and this sprinkles them all
over. I'd recommend to fix your security model instead.
I think the problem here is more with the
Am 26.07.2011 16:00, schrieb Eric Blake:
On 07/26/2011 06:51 AM, Corey Bryant wrote:
There are some additional features provided by certain image types
where Qemu reopens the image file. All of these scenarios will be
unsupported for the fd: protocol, at least for this patch:
- The
Am 26.07.2011 16:46, schrieb Corey Bryant:
On 07/26/2011 10:05 AM, Kevin Wolf wrote:
Am 26.07.2011 15:02, schrieb Christoph Hellwig:
I have to say I really hate it. We've been working hard on getting rid
of special cases in the qemu block layer, and this sprinkles them all
over. I'd
Am 26.07.2011 14:51, schrieb Corey Bryant:
sVirt provides SELinux MAC isolation for Qemu guest processes and their
corresponding resources (image files). sVirt provides this support
by labeling guests and resources with security labels that are stored
in file system extended attributes. Some
Am 26.07.2011 18:57, schrieb Corey Bryant:
Kevin, thanks for the input.
On 07/26/2011 11:18 AM, Kevin Wolf wrote:
Am 26.07.2011 14:51, schrieb Corey Bryant:
sVirt provides SELinux MAC isolation for Qemu guest processes and their
corresponding resources (image files). sVirt provides
Am 27.07.2011 10:22, schrieb Daniel P. Berrange:
On Wed, Jul 27, 2011 at 10:11:06AM +0200, Kevin Wolf wrote:
Am 26.07.2011 18:57, schrieb Corey Bryant:
diff --git a/block/cow.c b/block/cow.c
index 4cf543c..e17f8e7 100644
--- a/block/cow.c
+++ b/block/cow.c
@@ -82,6 +82,11 @@ static int
Am 27.07.2011 15:09, schrieb Corey Bryant:
Kevin/Daniel, thanks a lot for your input.
In terms of the support that libvirt requires, I just want to make sure
all bases are covered.
In order for this support to be useful to libvirt, the following are
required (sorry if this is
Am 11.08.2011 00:08, schrieb Eric Blake:
[BCC'ing those who have responded to earlier RFC's]
I've posted previous RFCs for improving snapshot support:
ideas on managing a subset of disks:
https://www.redhat.com/archives/libvir-list/2011-May/msg00042.html
ideas on managing snapshots of
[ CCed qemu-devel, just in case someone's interested ]
Am 11.08.2011 15:23, schrieb Eric Blake:
[ Okay, some of it is handled later in this document, but I think it's
still useful to leave this summary in my mail. External VM state is
something that you don't seem to have covered yet - can't
Am 12.08.2011 09:18, schrieb Philipp Hahn:
Hello Kevin, hello Eric,
On Thursday 11 August 2011 12:00:46 Kevin Wolf wrote:
Am 11.08.2011 00:08, schrieb Eric Blake:
Libvirt currently has a bug in that it only saves domain/uuid rather
than the full domain xml along with a checkpoint - if any
Am 11.08.2011 18:28, schrieb Corey Bryant:
On 07/26/2011 08:51 AM, Corey Bryant wrote:
+static int raw_open_fd(BlockDriverState *bs, const char *filename,
int flags)
+{
+BDRVRawState *s = bs-opaque;
+const char *fd_str;
+int fd;
+
+/* extract the file
Am 23.08.2011 17:26, schrieb Daniel P. Berrange:
On Tue, Aug 23, 2011 at 11:13:34AM -0400, Corey Bryant wrote:
On 08/22/2011 02:39 PM, Blue Swirl wrote:
On Mon, Aug 22, 2011 at 5:42 PM, Corey Bryantcor...@linux.vnet.ibm.com
wrote:
On 08/22/2011 01:25 PM, Anthony Liguori wrote:
On
Am 20.09.2011 20:01, schrieb Eric Blake:
On 09/20/2011 11:39 AM, Jiri Denemark wrote:
The commit that prevents disk corruption on domain shutdown
(96fc4784177ecb70357518fa863442455e45ad0e) causes regression with QEMU
0.14.* and 0.15.* because of a regression bug in QEMU that was fixed
only
Am 20.10.2011 23:48, schrieb Josh Durgin:
On 10/20/2011 12:24 PM, Daniel P. Berrange wrote:
On Thu, Oct 20, 2011 at 11:30:42AM -0700, Josh Durgin wrote:
We're working on libvirt support for block device authentication [1]. To
authenticate, rbd needs a username and a secret. Normally, to
avoid
Am 10.11.2011 22:30, schrieb Anthony Liguori:
Live migration with qcow2 or any other image format is just not going to work
right now even with proper clustered storage. I think doing a block level
flush
cache interface and letting block devices decide how to do it is the best
approach.
Am 11.11.2011 15:03, schrieb Anthony Liguori:
On 11/11/2011 04:15 AM, Kevin Wolf wrote:
Am 10.11.2011 22:30, schrieb Anthony Liguori:
Live migration with qcow2 or any other image format is just not going to
work
right now even with proper clustered storage. I think doing a block level
Am 11.11.2011 15:35, schrieb Anthony Liguori:
On 11/11/2011 08:29 AM, Kevin Wolf wrote:
Am 11.11.2011 15:03, schrieb Anthony Liguori:
On 11/11/2011 04:15 AM, Kevin Wolf wrote:
Am 10.11.2011 22:30, schrieb Anthony Liguori:
Live migration with qcow2 or any other image format is just not going
Am 12.11.2011 11:25, schrieb Avi Kivity:
On 11/11/2011 12:15 PM, Kevin Wolf wrote:
Am 10.11.2011 22:30, schrieb Anthony Liguori:
Live migration with qcow2 or any other image format is just not going to
work
right now even with proper clustered storage. I think doing a block level
flush
Am 14.11.2011 12:08, schrieb Daniel P. Berrange:
On Mon, Nov 14, 2011 at 12:24:22PM +0200, Michael S. Tsirkin wrote:
On Mon, Nov 14, 2011 at 10:16:10AM +, Daniel P. Berrange wrote:
On Sat, Nov 12, 2011 at 12:25:34PM +0200, Avi Kivity wrote:
On 11/11/2011 12:15 PM, Kevin Wolf wrote:
Am
Am 15.12.2011 14:18, schrieb Jan Kiszka:
On 2011-12-15 14:02, Stefan Hajnoczi wrote:
What is the status of QEMU's transition from HMP to the QMP interface?
My current understanding is that QEMU provides new HMP commands for
humans, but HMP is being phased out as an API. Management tools
Am 15.12.2011 14:39, schrieb Jan Kiszka:
On 2011-12-15 14:38, Lucas Meneghel Rodrigues wrote:
On 12/15/2011 11:33 AM, Kevin Wolf wrote:
Am 15.12.2011 14:18, schrieb Jan Kiszka:
On 2011-12-15 14:02, Stefan Hajnoczi wrote:
What is the status of QEMU's transition from HMP to the QMP interface
Am 18.01.2012 17:22, schrieb Eric Blake:
On 11/23/2011 02:18 AM, Stefan Hajnoczi wrote:
Notes: Now all the planed features were implemented (#1#2 were
implemented by
Zhi Yong Wu), the previous comments were all fixed up too. And the qemu
part patches
have been accepted upstream and are
Am 07.09.2010 15:41, schrieb Anthony Liguori:
Hi,
We've got copy-on-read and image streaming working in QED and before
going much further, I wanted to bounce some interfaces off of the
libvirt folks to make sure our final interface makes sense.
Here's the basic idea:
Today, you can
Am 07.09.2010 16:49, schrieb Anthony Liguori:
Shouldn't it be a runtime option? You can use the very same image with
copy-on-read or copy-on-write and it will behave the same (execpt for
performance), so it's not an inherent feature of the image file.
The way it's implemented in QED is
Am 07.09.2010 17:30, schrieb Anthony Liguori:
On 09/07/2010 10:20 AM, Kevin Wolf wrote:
Am 07.09.2010 17:11, schrieb Anthony Liguori:
Copy-on-read is, in many cases, a property of the backing file because
it suggests that the backing file is either very slow or potentially
volatile
Am 07.09.2010 17:11, schrieb Anthony Liguori:
On 09/07/2010 10:02 AM, Kevin Wolf wrote:
Am 07.09.2010 16:49, schrieb Anthony Liguori:
Shouldn't it be a runtime option? You can use the very same image with
copy-on-read or copy-on-write and it will behave the same (execpt for
performance
Am 07.09.2010 17:09, schrieb Stefan Hajnoczi:
Right, I'm a little hesitant to get too far into discussing the
management interface because I remember long threads about polling and
async. I never fully read them but I bet some wisdom came out of them
that applies here.
There are two ways
Am 08.04.2011 18:02, schrieb Stefan Hajnoczi:
On Fri, Apr 8, 2011 at 2:31 PM, Daniel P. Berrange berra...@redhat.com
wrote:
I have CCed Anthony and Kevin. Anthony drove the QED image streaming
and Kevin will probably be interested in the idea of allocating raw
images as a background
Am 08.04.2011 18:48, schrieb Daniel P. Berrange:
On Fri, Apr 08, 2011 at 06:35:16PM +0200, Kevin Wolf wrote:
Am 08.04.2011 18:02, schrieb Stefan Hajnoczi:
On Fri, Apr 8, 2011 at 2:31 PM, Daniel P. Berrange berra...@redhat.com
wrote:
I have CCed Anthony and Kevin. Anthony drove the QED
Am 12.04.2011 10:14, schrieb Daniel P. Berrange:
On Mon, Apr 11, 2011 at 05:06:54PM -0500, Anthony Liguori wrote:
On 04/11/2011 04:45 PM, Daniel P. Berrange wrote:
On Fri, Apr 08, 2011 at 02:26:48PM -0500, Anthony Liguori wrote:
On 04/08/2011 11:02 AM, Stefan Hajnoczi wrote:
On Fri, Apr 8,
Am 14.04.2011 11:10, schrieb Philipp Hahn:
Hello,
Am Dienstag 03 August 2010 06:44:26 schrieb Kevin Wolf:
From: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
This patch improves the resilience of the load_vmstate() function, doing
further and better ordered tests.
This patch broke
Am 26.07.2012 05:57, schrieb Corey Bryant:
On 07/25/2012 03:43 PM, Eric Blake wrote:
On 07/23/2012 07:08 AM, Corey Bryant wrote:
+int monitor_fdset_get_fd(Monitor *mon, int64_t fdset_id, int flags)
+{
+mon_fdset_t *mon_fdset;
+mon_fdset_fd_t *mon_fdset_fd;
+int mon_fd_flags;
+
Am 26.07.2012 15:13, schrieb Eric Blake:
On 07/25/2012 09:21 PM, Corey Bryant wrote:
On 07/25/2012 03:25 PM, Eric Blake wrote:
On 07/25/2012 02:22 AM, Kevin Wolf wrote:
Hm, not a nice interface where qemu_close() needs the filename and
(worse) could be given a wrong filename. Maybe it would
Am 03.08.2012 00:21, schrieb Corey Bryant:
@@ -84,6 +158,36 @@ int qemu_open(const char *name, int flags, ...)
int ret;
int mode = 0;
+#ifndef _WIN32
+const char *fdset_id_str;
+
+/* Attempt dup of fd from fd set */
+if (strstart(name, /dev/fdset/, fdset_id_str)) {
Am 02.08.2012 09:20, schrieb Kevin Shanahan:
On Thu, Aug 02, 2012 at 02:49:52PM +0930, Kevin Shanahan wrote:
On Thu, Aug 02, 2012 at 11:46:13AM +0930, Kevin Shanahan wrote:
On Thu, Aug 02, 2012 at 11:02:42AM +0930, Kevin Shanahan wrote:
Set the block driver read_only flag for cdrom devices so
Am 06.08.2012 15:32, schrieb Corey Bryant:
On 08/06/2012 05:15 AM, Kevin Wolf wrote:
Am 03.08.2012 00:21, schrieb Corey Bryant:
@@ -84,6 +158,36 @@ int qemu_open(const char *name, int flags, ...)
int ret;
int mode = 0;
+#ifndef _WIN32
+const char *fdset_id_str
Am 07.08.2012 10:47, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Am 02.08.2012 09:20, schrieb Kevin Shanahan:
On Thu, Aug 02, 2012 at 02:49:52PM +0930, Kevin Shanahan wrote:
On Thu, Aug 02, 2012 at 11:46:13AM +0930, Kevin Shanahan wrote:
On Thu, Aug 02, 2012 at 11:02:42AM
Am 07.08.2012 18:49, schrieb Eric Blake:
On 08/07/2012 09:58 AM, Corey Bryant wrote:
This patch adds support that enables passing of file descriptors
to the QEMU monitor where they will be stored in specified file
descriptor sets.
A file descriptor set can be used by a client like libvirt to
Am 10.08.2012 04:10, schrieb Corey Bryant:
This patch adds support that enables passing of file descriptors
to the QEMU monitor where they will be stored in specified file
descriptor sets.
A file descriptor set can be used by a client like libvirt to
store file descriptors for the same
Am 10.08.2012 04:10, schrieb Corey Bryant:
When qemu_open is passed a filename of the /dev/fdset/nnn
format (where nnn is the fdset ID), an fd with matching access
mode flags will be searched for within the specified monitor
fd set. If the fd is found, a dup of the fd will be returned
from
Am 10.08.2012 04:10, schrieb 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
Am 12.08.2012 04:48, schrieb Kevin Shanahan:
So qmp_change_blockdev uses bdrv_is_read_only() to check whether to
try and open the backing file read only, which uses the -read_only
member of struct BlockDriverState to decide whether to pass the
BDRV_O_RDRW flag to qmp_bdrv_open_encypted() and
Am 13.08.2012 13:57, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Am 12.08.2012 04:48, schrieb Kevin Shanahan:
So qmp_change_blockdev uses bdrv_is_read_only() to check whether to
try and open the backing file read only, which uses the -read_only
member of struct
Am 13.08.2012 20:39, schrieb Corey Bryant:
On 08/13/2012 02:02 PM, Eric Blake wrote:
On 08/13/2012 08:08 AM, Corey Bryant wrote:
libvirt's sVirt security driver provides SELinux MAC isolation for
Qemu guest processes and their corresponding image files. In other
words, sVirt uses SELinux
Am 13.08.2012 16:08, schrieb Corey Bryant:
When qemu_open is passed a filename of the /dev/fdset/nnn
format (where nnn is the fdset ID), an fd with matching access
mode flags will be searched for within the specified monitor
fd set. If the fd is found, a dup of the fd will be returned
from
Am 13.08.2012 09:54, schrieb Kevin Wolf:
Am 12.08.2012 04:48, schrieb Kevin Shanahan:
So qmp_change_blockdev uses bdrv_is_read_only() to check whether to
try and open the backing file read only, which uses the -read_only
member of struct BlockDriverState to decide whether to pass
Am 21.09.2012 01:20, schrieb Kevin Shanahan:
If readonly=on is given at device creation time, the -readonly flag
needs to be set in the block driver state for this device so that
readonly-ness is preserved across media changes (qmp change command).
Similarly, to preserve the snapshot property
1 - 100 of 213 matches
Mail list logo
