On Fri, Aug 26, 2011 at 01:18:49PM +0300, Sasha Levin wrote:
> On Fri, 2011-08-26 at 09:04 +0100, Richard W.M. Jones wrote:
> > On Fri, Aug 26, 2011 at 09:22:45AM +0300, Sasha Levin wrote:
> > > On Thu, 2011-08-25 at 16:25 +, Decker, Schorschi wrote:
> > > > 2) implement the feature as an agent
On Fri, 2011-08-26 at 09:04 +0100, Richard W.M. Jones wrote:
> On Fri, Aug 26, 2011 at 09:22:45AM +0300, Sasha Levin wrote:
> > On Thu, 2011-08-25 at 16:25 +, Decker, Schorschi wrote:
> > > 2) implement the feature as an agent in the guest OS where the
> > > hypervisor can only query the guest
On Fri, Aug 26, 2011 at 09:08:02AM +0300, Sasha Levin wrote:
> You're thinking about trying to expose all interfaces during boot and
> seeing which ones the kernel bites?
No, that's a bad idea. A current guest would register that as two
disks. It might even try to write to them independently.
Y
On Thu, Aug 25, 2011 at 04:48:36PM -0500, Anthony Liguori wrote:
> One would be exposing a well supported device (like IDE emulation)
> and having a magic mode that allowed you to basically promote the
> device from IDE emulation to virtio-blk. Likewise, you could do
> something like that to promo
On Fri, Aug 26, 2011 at 09:22:45AM +0300, Sasha Levin wrote:
> On Thu, 2011-08-25 at 16:25 +, Decker, Schorschi wrote:
> > 2) implement the feature as an agent in the guest OS where the
> > hypervisor can only query the guest OS agent, using a standard TCP/IP
> > methodology.
>
> I was planning
On Thu, 2011-08-25 at 16:25 +, Decker, Schorschi wrote:
> I would ask two things be done in the design if it goes forward, 1)
> have an explicit way to disable this feature, where the hypervisor
> cannot interact with the guest OS directly in any way if disablement
> is selected.
I doubt that
On Thu, 2011-08-25 at 16:48 -0500, Anthony Liguori wrote:
> On 08/25/2011 12:21 AM, Sasha Levin wrote:
> > Hi,
> >
> > Currently when we run the guest we treat it as a black box, we're not
> > quite sure what it's going to start and whether it supports the same
> > features we expect it to support
On 08/25/2011 12:21 AM, Sasha Levin wrote:
Hi,
Currently when we run the guest we treat it as a black box, we're not
quite sure what it's going to start and whether it supports the same
features we expect it to support when running it from the host.
This forces us to start the guest with the sa
vi Kivity; kvm
Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection
On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote:
> > From what I gathered libguestfs only provides access to the
On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote:
> > From what I gathered libguestfs only provides access to the guests'
> > image.
>
> Correct.
>
> > Which part is doing the IKCONFIG or System.map probing? Or is it
On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote:
> From what I gathered libguestfs only provides access to the guests'
> image.
Correct.
> Which part is doing the IKCONFIG or System.map probing? Or is it done in
> a different way?
You'll have to see what Matt's doing in the virt-v2v
On Thu, 2011-08-25 at 08:32 +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote:
> > On 08/25/2011 08:21 AM, Sasha Levin wrote:
> > >Hi,
> > >
> > >Currently when we run the guest we treat it as a black box, we're not
> > >quite sure what it's going to star
On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote:
> On 08/25/2011 08:21 AM, Sasha Levin wrote:
> >Hi,
> >
> >Currently when we run the guest we treat it as a black box, we're not
> >quite sure what it's going to start and whether it supports the same
> >features we expect it to support wh
On 08/25/2011 08:21 AM, Sasha Levin wrote:
Hi,
Currently when we run the guest we treat it as a black box, we're not
quite sure what it's going to start and whether it supports the same
features we expect it to support when running it from the host.
This forces us to start the guest with the sa
Hi,
Currently when we run the guest we treat it as a black box, we're not
quite sure what it's going to start and whether it supports the same
features we expect it to support when running it from the host.
This forces us to start the guest with the safest defaults possible, for
example: '-drive
15 matches
Mail list logo
