On 10/22/2010 12:29 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
The first step is just identifying what interfaces we need in a
guest agent. So far, I think we can get away with a very small
number of interfaces (mainly read/write files, execute command).
* Anthony Liguori (anth...@codemonkey.ws) wrote:
The first step is just identifying what interfaces we need in a
guest agent. So far, I think we can get away with a very small
number of interfaces (mainly read/write files, execute command).
Could you elaborate here? I can't imagine you mean:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 10/22/2010 12:29 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
The first step is just identifying what interfaces we need in a
guest agent. So far, I think we can get away with a very small
number of interfaces
On 10/22/2010 01:20 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 10/22/2010 12:29 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
The first step is just identifying what interfaces we need in a
guest agent. So far, I
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 10/22/2010 01:20 PM, Chris Wright wrote:
I'm not sure about that. That same new shiny Fedora 21 QEMU has no idea
what the right OS specific command to run in guest is. Granted, it's
not likely that reboot or shutdown -r now are likely to
On 10/21/2010 03:14 AM, Alexander Graf wrote:
I agree that some agent code for basic stuff like live snapshot
sync with the filesystem is small enough and worth to host within
qemu. Maybe we do need more than one project?
No, please. That's exactly what I don't want to see. The
On 10/21/2010 02:45 AM, Paolo Bonzini wrote:
On 10/21/2010 03:14 AM, Alexander Graf wrote:
I agree that some agent code for basic stuff like live snapshot
sync with the filesystem is small enough and worth to host within
qemu. Maybe we do need more than one project?
No, please. That's exactly
On 10/21/2010 03:02 PM, Anthony Liguori wrote:
On 10/21/2010 02:45 AM, Paolo Bonzini wrote:
On 10/21/2010 03:14 AM, Alexander Graf wrote:
I agree that some agent code for basic stuff like live snapshot
sync with the filesystem is small enough and worth to host within
qemu. Maybe we do need
On Thu, Oct 21, 2010 at 08:09:44AM -0500, Anthony Liguori wrote:
Hi Andrew,
On 10/21/2010 05:22 AM, Andrew Beekhof wrote:
Hello from the Matahari tech-lead...
Is there any documentation on the capabilities provided guest agent
Anthony is creating? Perhaps we can combine efforts.
Mike
On 10/21/2010 03:32 PM, Anthony Liguori wrote:
On 10/21/2010 08:18 AM, Daniel P. Berrange wrote:
On Thu, Oct 21, 2010 at 08:09:44AM -0500, Anthony Liguori wrote:
Hi Andrew,
On 10/21/2010 05:22 AM, Andrew Beekhof wrote:
Hello from the Matahari tech-lead...
Is there any documentation on the
Hi Andrew,
On 10/21/2010 10:43 AM, Andrew Beekhof wrote:
In that case we've done a bad job of the wiki.
Windows and other distributions are a key part of the Matahari vision.
Matahari is two things
- an architecture, and
- an implementation of the most common API sets
Each set of APIs (ie.
* Anthony Liguori (anth...@codemonkey.ws) wrote:
So there's no doubt in my mind that if you need a way to inventory
physical and virtual systems, something like Matahari becomes a very
appealing option to do that.
But that's not the problem space I'm trying to tackle.
An example of the
On 10/21/2010 06:25 PM, Anthony Liguori wrote:
Hi Andrew,
On 10/21/2010 10:43 AM, Andrew Beekhof wrote:
In that case we've done a bad job of the wiki.
Windows and other distributions are a key part of the Matahari vision.
Matahari is two things
- an architecture, and
- an implementation of
On 20.10.2010, at 10:25, Paolo Bonzini wrote:
On 10/20/2010 10:21 AM, Alexander Graf wrote:
Would it be realistic to declare deprecating the qemu-kvm fork for
0.14 as goal?
I recall some performance problems with the qemu.git iothread, I'm not sure
all of those have been fixed.
Yes,
On 19.10.2010, at 17:14, Chris Wright wrote:
0.13.X -stable
- Anthony will send note to qemu-devel on this
- move 0.13.X -stable to a separate tree
- driven independently of main qemu tree
- challenge is always in the porting and testing of backported fixes
- looking for volunteers
0.14
On 10/20/2010 10:21 AM, Alexander Graf wrote:
Would it be realistic to declare deprecating the qemu-kvm fork for
0.14 as goal?
I recall some performance problems with the qemu.git iothread, I'm not
sure all of those have been fixed.
Paolo
On 10/20/2010 10:21 AM, Alexander Graf wrote:
On 19.10.2010, at 17:14, Chris Wright wrote:
0.13.X -stable
- Anthony will send note to qemu-devel on this
- move 0.13.X -stable to a separate tree
- driven independently of main qemu tree
- challenge is always in the porting and testing
On 10/20/2010 10:21 AM, Alexander Graf wrote:
On 19.10.2010, at 17:14, Chris Wright wrote:
0.13.X -stable
- Anthony will send note to qemu-devel on this
- move 0.13.X -stable to a separate tree
- driven independently of main qemu tree
- challenge is always in the porting and testing of
On 10/20/2010 03:21 AM, Alexander Graf wrote:
Live snapshots
- merge snapshot?
- already supported, question about mgmt of snapshot chain
- integrate with fsfreeze (and windows alternative)
Guest Agent
- have one coming RSN (poke Anthony for details)
Would there be a chance to have a
On Wed, Oct 20, 2010 at 08:02:07AM -0500, Anthony Liguori wrote:
On 10/20/2010 03:21 AM, Alexander Graf wrote:
Live snapshots
- merge snapshot?
- already supported, question about mgmt of snapshot chain
- integrate with fsfreeze (and windows alternative)
Guest Agent
- have one coming
On 10/20/2010 08:19 AM, Daniel P. Berrange wrote:
The thinking with Matahari is that there is significant overlap between
agent requirements for a physical and virtual host, so it aims to provide
an agent that works everywhere, whether virtualized or not. All that need
change is the
On 10/20/2010 03:21 PM, Anthony Liguori wrote:
On 10/20/2010 08:19 AM, Daniel P. Berrange wrote:
The thinking with Matahari is that there is significant overlap between
agent requirements for a physical and virtual host, so it aims to provide
an agent that works everywhere, whether virtualized
Am 21.10.2010 um 00:46 schrieb Dor Laor dl...@redhat.com:
On 10/20/2010 03:21 PM, Anthony Liguori wrote:
On 10/20/2010 08:19 AM, Daniel P. Berrange wrote:
The thinking with Matahari is that there is significant overlap between
agent requirements for a physical and virtual host, so it aims to
0.13.X -stable
- Anthony will send note to qemu-devel on this
- move 0.13.X -stable to a separate tree
- driven independently of main qemu tree
- challenge is always in the porting and testing of backported fixes
- looking for volunteers
0.14
- would like to do this before end of the year
- 0.13
24 matches
Mail list logo
