On 07/09/2012 03:29 PM, Eric Blake wrote:
On 07/09/2012 02:00 PM, Anthony Liguori wrote:
with the fd:name approach, the sequence is:
libvirt calls getfd:name1 over normal monitor
qemu responds
libvirt calls getfd:name2 over normal monitor
qemu responds
libvirt calls transaction around blockdev
On 07/09/2012 02:00 PM, Anthony Liguori wrote:
>> with the fd:name approach, the sequence is:
>>
>> libvirt calls getfd:name1 over normal monitor
>> qemu responds
>> libvirt calls getfd:name2 over normal monitor
>> qemu responds
>> libvirt calls transaction around blockdev-snapshot-sync over norma
On 05/17/2012 09:14 AM, Eric Blake wrote:
On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote:
The -open-hook-fd approach allows QEMU to support file descriptor passing
without changing -drive. It also supports snapshot_blkdev and other commands
By the way, How will it support them?
The problem
On Thu, May 17, 2012 at 10:02:01PM +0800, Zhi Yong Wu wrote:
> On Thu, May 17, 2012 at 9:42 PM, Stefan Hajnoczi
> wrote:
> > On Fri, May 04, 2012 at 11:28:47AM +0800, Zhi Yong Wu wrote:
> >> On Tue, May 1, 2012 at 11:31 PM, Stefan Hajnoczi
> >> wrote:
> >> > Libvirt can take advantage of SELinux
On Thu, May 17, 2012 at 08:14:15AM -0600, Eric Blake wrote:
> On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote:
>
> >>>
> >>> The -open-hook-fd approach allows QEMU to support file descriptor passing
> >>> without changing -drive. It also supports snapshot_blkdev and other
> >>> commands
> >> By th
On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote:
>>>
>>> The -open-hook-fd approach allows QEMU to support file descriptor passing
>>> without changing -drive. It also supports snapshot_blkdev and other
>>> commands
>> By the way, How will it support them?
>
> The problem with snapshot_blkdev is
On Thu, May 17, 2012 at 9:42 PM, Stefan Hajnoczi
wrote:
> On Fri, May 04, 2012 at 11:28:47AM +0800, Zhi Yong Wu wrote:
>> On Tue, May 1, 2012 at 11:31 PM, Stefan Hajnoczi
>> wrote:
>> > Libvirt can take advantage of SELinux to restrict the QEMU process and
>> > prevent
>> > it from opening files
On Thu, May 17, 2012 at 9:42 PM, Stefan Hajnoczi
wrote:
> On Fri, May 04, 2012 at 11:28:47AM +0800, Zhi Yong Wu wrote:
>> On Tue, May 1, 2012 at 11:31 PM, Stefan Hajnoczi
>> wrote:
>> > Libvirt can take advantage of SELinux to restrict the QEMU process and
>> > prevent
>> > it from opening files
On Fri, May 04, 2012 at 11:28:47AM +0800, Zhi Yong Wu wrote:
> On Tue, May 1, 2012 at 11:31 PM, 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
On 05/01/2012 06:15 PM, Eric Blake wrote:
On 05/01/2012 03:53 PM, Anthony Liguori wrote:
I think (correct me if I'm wrong) libvirt should be aware of any file
that qemu
asks it to open. So from a security point of view, libvirt can prevent
opening a
file if it isn't affiliated with the guest.
On Tue, May 1, 2012 at 11:31 PM, 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 because it prevents the attacker from escaping the QEMU process if
> they ma
On 05/02/2012 04:45 AM, Kevin Wolf wrote:
Am 02.05.2012 10:53, schrieb Daniel P. Berrange:
I would much prefer to see us be able to pass FDs in directly alongside
the disk config as we do for netdev TAP/etc, and for QEMU / kernel to be
fixed so that you do not need to re-open FDs on the fly.
I
Il 02/05/2012 11:56, Daniel P. Berrange ha scritto:
> I tend to agree - we have been talking about -blockdev for faar to long
> without (AFAICT) making any real progress towards getting it done. I'd
> love to see someone bite the bullet & have a go at implementing it
Having a spec would help somew
Il 01/05/2012 22:56, Eric Blake ha scritto:
> What sort
> of timing restrictions are there? For example, the proposed
> 'drive-reopen' command (probably now delegated to qemu 1.2) would mean
> that qemu would be calling back into libvirt in order to do the reopen.
> If libvirt takes its time in p
On Wed, May 02, 2012 at 11:45:26AM +0200, Kevin Wolf wrote:
> 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 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 t
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 the QEMU process and
> >> prevent
> >>
On 05/01/2012 05:15 PM, Eric Blake wrote:
On 05/01/2012 03:53 PM, Anthony Liguori wrote:
I think (correct me if I'm wrong) libvirt should be aware of any file
that qemu
asks it to open. So from a security point of view, libvirt can prevent
opening a
file if it isn't affiliated with the guest.
On 05/01/2012 03:53 PM, Anthony Liguori wrote:
>> I think (correct me if I'm wrong) libvirt should be aware of any file
>> that qemu
>> asks it to open. So from a security point of view, libvirt can prevent
>> opening a
>> file if it isn't affiliated with the guest.
>
> Right, libvirt can maintai
On 05/01/2012 03:56 PM, Eric Blake wrote:
On 05/01/2012 02:25 PM, Anthony Liguori wrote:
Thanks for sending this out Stefan.
Indeed.
This series adds the -open-hook-fd command-line option. Whenever QEMU
needs to
open an image file it sends a request over the given UNIX domain
socket. The
On 05/01/2012 02:25 PM, Anthony Liguori wrote:
> Thanks for sending this out Stefan.
Indeed.
>> This series adds the -open-hook-fd command-line option. Whenever QEMU
>> needs to
>> open an image file it sends a request over the given UNIX domain
>> socket. The
>> response includes the file des
21 matches
Mail list logo
