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 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 to
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.
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 OS
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 in the
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 when running
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 start and whether
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, 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 done in
: [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 guests'
image.
Correct.
Which part
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
11 matches
Mail list logo
