* 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 li
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 th
* 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 in
* 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 mea
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).
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 the
* 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
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. hos
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 cap
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 capabilities provided guest agent
Anthony
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 effort
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 should be posting today or tomorrow.
Also happy to provide more inform
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 more
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 12:22 PM, Andrew Beekhof wrote:
On 10/20/2010 02:16 PM, Dor Laor wrote:
On 10/20/2010 10:21 AM, Alexander Graf wrote:
On 19.10.2010, at 17:14, Chris Wright wrote:
Guest Agent
- have one coming RSN (poke Anthony for details)
Would there be a chance to have a single agent for ev
On 10/20/2010 02:16 PM, Dor Laor wrote:
On 10/20/2010 10:21 AM, Alexander Graf wrote:
On 19.10.2010, at 17:14, Chris Wright wrote:
Guest Agent
- have one coming RSN (poke Anthony for details)
Would there be a chance to have a single agent for everyone, so that
we actually form a Qemu agent i
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
libvirt/qemu/vir
Am 21.10.2010 um 00:46 schrieb Dor Laor :
> 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
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 o
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 communication
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
> >
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 si
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 backpor
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 test
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 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
>
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.
Y
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 f
28 matches
Mail list logo
