Alexander Graf wrote:
> > One way to avoid it is to have a rich plugin API so if some needs some
> > to, say, set up traffic control on the interface, they can write a
> > plugin to do that.
>
> Another way would be to have an active open source community that just
> writes the support for traffic
Daniel P. Berrange wrote:
> The different formats are serving different needs really. People use the
> libvirt XML format because they want a representation that works across
> multiple hypervisors.
Then my use-case is being missed.
I tried using the libvirt XML format because I want to use the n
Alexander Graf wrote:
> So what if you had a special section that gives you the necessary
> information to do that mapping? A vendor specific section so to say.
> That would make it a perfect master config format, right?
XML with XML Namespaces is quite good for mixing data intended for
different
Daniel P. Berrange wrote:
> On Tue, Apr 06, 2010 at 03:53:16PM +0200, Alexander Graf wrote:
>
>> Daniel P. Berrange wrote:
>>
If instead there was a common machine description file that everyone
knows, there'd be a single point of knowledge. A RHEL-V admin could work
on plain
On Tue, Apr 06, 2010 at 02:43:47PM +0200, Alexander Graf wrote:
> Does VMware Player support OVF?
> Does VMware Workstation support OVF?
> Does VMware Server support OVF?
Yes, but "OVF" is a rather loose term here. OVF isn't too
well standardized. But ...
> Does it make sense to build an OVF wi
On Tue, Apr 06, 2010 at 03:53:16PM +0200, Alexander Graf wrote:
> Daniel P. Berrange wrote:
> >> If instead there was a common machine description file that everyone
> >> knows, there'd be a single point of knowledge. A RHEL-V admin could work
> >> on plain qemu. A qemu developer would feel right a
Daniel P. Berrange wrote:
> On Tue, Apr 06, 2010 at 02:43:47PM +0200, Alexander Graf wrote:
>
>> Daniel P. Berrange wrote:
>>
>>> With appliances there are two core aspects
>>>
>>> 1. The description of VM hardware requirements
>>> 2. The disk format
>>>
>>> Traditionally VMware appliance
On Tue, Apr 06, 2010 at 02:43:47PM +0200, Alexander Graf wrote:
> Daniel P. Berrange wrote:
> > With appliances there are two core aspects
> >
> > 1. The description of VM hardware requirements
> > 2. The disk format
> >
> > Traditionally VMware appliances have shipped a VMX file for 1. and
> > a
Daniel P. Berrange wrote:
> On Tue, Apr 06, 2010 at 02:49:23PM +0200, Alexander Graf wrote:
>
>> Daniel P. Berrange wrote:
>>
>>> On Tue, Apr 06, 2010 at 01:14:36AM +0300, Avi Kivity wrote:
>>>
>>>
On 04/06/2010 12:11 AM, Alexander Graf wrote:
>>>
On Tue, Apr 06, 2010 at 02:49:23PM +0200, Alexander Graf wrote:
> Daniel P. Berrange wrote:
> > On Tue, Apr 06, 2010 at 01:14:36AM +0300, Avi Kivity wrote:
> >
> >> On 04/06/2010 12:11 AM, Alexander Graf wrote:
> >>
> >>
> >>> I can imagine 1) going away if we would set libvirt + virt-manag
On 04/06/2010 03:43 PM, Alexander Graf wrote:
Does VMware Player support OVF?
Does VMware Workstation support OVF?
Does VMware Server support OVF?
Do older VMware ESX versions support OVF?
Does it make sense to build an OVF with a Xen PV image?
We need to deliver vendor specific configs anyways
Avi Kivity wrote:
> On 04/06/2010 03:28 PM, Alexander Graf wrote:
>>> Note things like network setup are a bottomless pit. Pretty soon you
>>> need to setup vlans and bonding etc. If a user needs one of these and
>>> qemud doesn't provide it, then qemud becomes useless to them. But the
>>> same
Daniel P. Berrange wrote:
> On Tue, Apr 06, 2010 at 01:14:36AM +0300, Avi Kivity wrote:
>
>> On 04/06/2010 12:11 AM, Alexander Graf wrote:
>>
>>
>>> I can imagine 1) going away if we would set libvirt + virt-manager as
>>> _the_ front-end and have everyone focus on it. I suppose it would a
Daniel P. Berrange wrote:
> On Mon, Apr 05, 2010 at 11:11:48PM +0200, Alexander Graf wrote:
>
>> Howdy,
>>
>> I've been thinking a bit further on the whole issue around
>> libvirt and why the situation as is isn't satisfying. I came
>> to the following points that currently hurt building ease o
On 04/06/2010 03:28 PM, Alexander Graf wrote:
Note things like network setup are a bottomless pit. Pretty soon you
need to setup vlans and bonding etc. If a user needs one of these and
qemud doesn't provide it, then qemud becomes useless to them. But the
same problem applies to libvirt.
Avi Kivity wrote:
> On 04/06/2010 01:29 AM, Alexander Graf wrote:
>>
>>> Well, I did suggest (and then withdraw) qemud. The problem is that
>>> to get something working we'd duplicate all the work that's gone
>>> into libvirt - storage pools, svirt, network setup, etc.
>>>
>> That's infrastr
On 04/06/2010 01:29 AM, Alexander Graf wrote:
Well, I did suggest (and then withdraw) qemud. The problem is that to get
something working we'd duplicate all the work that's gone into libvirt -
storage pools, svirt, network setup, etc.
That's infrastructure that should probably go alon
On Tue, Apr 06, 2010 at 01:14:36AM +0300, Avi Kivity wrote:
> On 04/06/2010 12:11 AM, Alexander Graf wrote:
>
> >I can imagine 1) going away if we would set libvirt + virt-manager as
> >_the_ front-end and have everyone focus on it. I suppose it would also
> >help to rebrand it by then, but I'm
On Mon, Apr 05, 2010 at 11:11:48PM +0200, Alexander Graf wrote:
> Howdy,
>
> I've been thinking a bit further on the whole issue around
> libvirt and why the situation as is isn't satisfying. I came
> to the following points that currently hurt building ease of
> use for KVM:
>
> 1) Brand
>
> T
On 06.04.2010, at 00:14, Avi Kivity wrote:
> On 04/06/2010 12:11 AM, Alexander Graf wrote:
>> Howdy,
>>
>> I've been thinking a bit further on the whole issue around libvirt and why
>> the situation as is isn't satisfying. I came to the following points that
>> currently hurt building ease of
On 04/06/2010 12:11 AM, Alexander Graf wrote:
Howdy,
I've been thinking a bit further on the whole issue around libvirt and why the
situation as is isn't satisfying. I came to the following points that currently
hurt building ease of use for KVM:
1) Brand
This is one of the major issues we h
21 matches
Mail list logo
