Avi Kivity wrote:
> >If management apps need to hard-code which slots are available on
> >different targets and different qemu versions, or restrictions on which
> >devices can use which slots, or knowledge that some devices can be
> >multi-function, or ... anything like that is just lame.
> >
>
Avi Kivity wrote:
> On 06/16/2009 09:32 PM, Jamie Lokier wrote:
> >Avi Kivity wrote:
> >
> >>Another issue is enumeration. Guests will present their devices in the
> >>order they find them on the pci bus (of course enumeration is guest
> >>specific). So if I have 2 virtio controllers the only
On 06/17/2009 12:18 PM, Mark McLoughlin wrote:
On Wed, 2009-06-17 at 12:03 +0300, Avi Kivity wrote:
On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
I particularly don't like the idea of arcane machine-dependent slot
allocation knowledge living in libvirt, because it needs to be in Qemu
On Wed, 2009-06-17 at 12:03 +0300, Avi Kivity wrote:
> On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
> >> I particularly don't like the idea of arcane machine-dependent slot
> >> allocation knowledge living in libvirt, because it needs to be in Qemu
> >> anyway for non-libvirt users. No point in
On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
I particularly don't like the idea of arcane machine-dependent slot
allocation knowledge living in libvirt, because it needs to be in Qemu
anyway for non-libvirt users. No point in having two implementations
of something tricky and likely to have ma
On Tue, 2009-06-16 at 19:44 +0100, Jamie Lokier wrote:
> Mark McLoughlin wrote:
> > > Worst case we hardcode those numbers (gasp, faint).
> >
> > Maybe we can just add the open slots to the -help output. That'd be nice
> > and clean.
I was being sarcastic - libvirt currently must parse qemu -help
On 06/16/2009 09:32 PM, Jamie Lokier wrote:
Avi Kivity wrote:
Another issue is enumeration. Guests will present their devices in the
order they find them on the pci bus (of course enumeration is guest
specific). So if I have 2 virtio controllers the only way I can
distinguish between them
Mark McLoughlin wrote:
> > Worst case we hardcode those numbers (gasp, faint).
>
> Maybe we can just add the open slots to the -help output. That'd be nice
> and clean.
Make them part of the machine configuration.
After all, they are part of the machine configuration, and ACPI, BIOS
etc. need to
Mark McLoughlin wrote:
> > After libvirt has done -drive file=foo... it should dump the machine
> > config and use that from then on.
>
> Right - libvirt then wouldn't be able to avoid the complexity of merging
> any future changes into the dumped machine config.
As long as qemu can accept a mac
Avi Kivity wrote:
> Another issue is enumeration. Guests will present their devices in the
> order they find them on the pci bus (of course enumeration is guest
> specific). So if I have 2 virtio controllers the only way I can
> distinguish between them is using their pci slots.
virtio contro
On 06/16/2009 03:39 PM, Mark McLoughlin wrote:
Worst case we hardcode those numbers (gasp, faint).
Maybe we can just add the open slots to the -help output. That'd be nice
and clean.
Yeah, there's precedent too.
Or:
$ readlink /usr/share/qemu/machine-types/pc.dt
That w
On Tue, 2009-06-16 at 15:28 +0300, Avi Kivity wrote:
> On 06/16/2009 03:14 PM, Mark McLoughlin wrote:
> > On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
> >
> >> Mark McLoughlin wrote:
> >>
> >>> So long as the restrictions would be known to the management app via
> >>> some "w
On 06/16/2009 03:14 PM, Mark McLoughlin wrote:
On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
Mark McLoughlin wrote:
So long as the restrictions would be known to the management app via
some "what slots are available" mechanism in qemu, that sounds fine.
I'm not s
On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > So long as the restrictions would be known to the management app via
> > some "what slots are available" mechanism in qemu, that sounds fine.
> >
>
> I'm not sure a "what slots are available" mechanism is as
On 06/15/2009 09:44 PM, Blue Swirl wrote:
pc-qemu-0.10?
pc-2009.06? Or given the hardware, should that be pc-1997?
pc-qemu-0.10 has the obvious benefit of allowing people to immediately
know what's the oldest version of qemu that supports it.
--
error compiling committee.c: too
On 6/15/09, Avi Kivity wrote:
> On 06/15/2009 09:12 PM, Anthony Liguori wrote:
>
> >
> > 2) Whenever the default machine type changes in a guest-visible way,
> introduce a new machine type
> >
>
> s/whenever/qemu stable release/
>
>
> > - Use explicit versions in name: pc-v1, pc-v2
> >
>
> pc-q
Avi Kivity wrote:
On 06/15/2009 09:12 PM, Anthony Liguori wrote:
2) Whenever the default machine type changes in a guest-visible way,
introduce a new machine type
s/whenever/qemu stable release/
- Use explicit versions in name: pc-v1, pc-v2
pc-qemu-0.10?
This is similar to a hardware v
On 06/15/2009 09:12 PM, Anthony Liguori wrote:
2) Whenever the default machine type changes in a guest-visible way,
introduce a new machine type
s/whenever/qemu stable release/
- Use explicit versions in name: pc-v1, pc-v2
pc-qemu-0.10?
This is similar to a hardware vendor's model numbe
Mark McLoughlin wrote:
So long as the restrictions would be known to the management app via
some "what slots are available" mechanism in qemu, that sounds fine.
I'm not sure a "what slots are available" mechanism is as straight
forward as has been claimed. It doesn't matter though because
On Mon, 2009-06-15 at 18:05 +0300, Avi Kivity wrote:
> On 06/15/2009 05:24 PM, Anthony Liguori wrote:
> > Dor Laor wrote:
> >> Libvirt does not support r2d. I hope it won't start to support it.
> >
> > It supports mips, sparc, and ppc machines now. I don't see why it
> > wouldn't support r2d. Fo
On Mon, 2009-06-15 at 18:12 +0300, Dor Laor wrote:
> > It doesn't want to. As Mark said, libvirt just wants to be able to ensure
> > a stable guest ABI, of which stable PCI addresses is one aspect. This does
> > not imply libvirt wants to allocate the PCI addresses, just that it wants
> > a way to
On 06/15/2009 06:20 PM, Anthony Liguori wrote:
Avi Kivity wrote:
I would prefer explicit names (pci_addr, lun, etc.) but would be okay
with generic names too.
I think having a generic address has a lot of value in terms of code
implementation. Otherwise, the valid options for -drive become
Avi Kivity wrote:
I would prefer explicit names (pci_addr, lun, etc.) but would be okay
with generic names too.
I think having a generic address has a lot of value in terms of code
implementation. Otherwise, the valid options for -drive become
context-sensitive which is going to be annoying
On 06/15/2009 06:12 PM, Dor Laor wrote:
It doesn't want to. As Mark said, libvirt just wants to be able to
ensure
a stable guest ABI, of which stable PCI addresses is one aspect. This
does
not imply libvirt wants to allocate the PCI addresses, just that it
wants
a way to keep them stable. All e
Daniel P. Berrange wrote:
On Mon, Jun 15, 2009 at 10:03:22AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
I'm not at all arguing against pci_addr. I'm arguing about how libvirt
should use it with respect to the "genesis" use-case where libvirt has
no specific reason to ch
On 06/15/2009 06:07 PM, Anthony Liguori wrote:
Avi Kivity wrote:
I'd object to any implicit addressing rules. If we have to say
target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of
index=8345345235 so be it.
The next observation is that while we expand the SCSI addressing, the
cur
Avi Kivity wrote:
However this may end up, isn't it offtopic? Whatever we do we have to
support both pci_addr= and default placement, so we can push this
discussion to livirt-devel and bid them godspeed.
I'm not sure how we got here but yeah, let's table this part of the
discussion.
Regard
Michael S. Tsirkin wrote:
And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be
more straightforward to have capability bits which can be switched on
and off independently rather than trying to fit unrelated features into
a machine type? IMO it only seems more work at first, an
On Mon, Jun 15, 2009 at 10:03:22AM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
> >>I'm not at all arguing against pci_addr. I'm arguing about how libvirt
> >>should use it with respect to the "genesis" use-case where libvirt has
> >>no specific reason to choose one PCI slot over
Avi Kivity wrote:
I'd object to any implicit addressing rules. If we have to say
target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of
index=8345345235 so be it.
The next observation is that while we expand the SCSI addressing, the
current propose flattens the PCI hierarchy (i.e. pc
On 06/15/2009 05:24 PM, Anthony Liguori wrote:
Dor Laor wrote:
Libvirt does not support r2d. I hope it won't start to support it.
It supports mips, sparc, and ppc machines now. I don't see why it
wouldn't support r2d. For ppcemb, I expect this same problem to
occur. This sort of restricti
Michael S. Tsirkin wrote:
I'm not at all arguing against pci_addr. I'm arguing about how libvirt
should use it with respect to the "genesis" use-case where libvirt has
no specific reason to choose one PCI slot over another. In that case,
I'm merely advocating that we want to let QEMU make
On Mon, Jun 15, 2009 at 09:24:32AM -0500, Anthony Liguori wrote:
> Dor Laor wrote:
>> Libvirt does not support r2d. I hope it won't start to support it.
>
> It supports mips, sparc, and ppc machines now. I don't see why it
> wouldn't support r2d. For ppcemb, I expect this same problem to occur.
On Mon, Jun 15, 2009 at 09:20:00AM -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
>> On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
>>
Eventually the default configuration becomes increasingly unusable
and you need a new baseline. You must still be able to fall bac
Dor Laor wrote:
Libvirt does not support r2d. I hope it won't start to support it.
It supports mips, sparc, and ppc machines now. I don't see why it
wouldn't support r2d. For ppcemb, I expect this same problem to occur.
This sort of restriction is going to be common with embedded boards.
Mark McLoughlin wrote:
On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
Eventually the
default configuration becomes increasingly unusable and you need a new
baseline. You must still be able to fall back to the old baseline for
older guests. I don't think games with configuration
Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
How would qemu know which slots to optimize for?
In practice, I don't see that as a real problem. We should (a) add
an ioapic and four more pci links (b) recommend that slots be
assigned in ascending ord
On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
> > I think the point is that you don't need version numbers if you
> > have a
> > proper device tree.
> >
> >
> How do you add a new
On 06/15/2009 04:45 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
It's not at all that simple. SCSI has a hierarchical address
mechanism with 0-7 targets but then potentially multiple LUNs per
target. Today, we always emulate a single LUN per ta
Avi Kivity wrote:
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
How would qemu know which slots to optimize for?
In practice, I don't see that as a real problem. We should (a) add an
ioapic and four more pci links (b) recommend that slots be assigned in
ascending order, and everything works
On 06/15/2009 04:24 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Certainly preferable to -baseline.
This is pretty easy to maintain with config files.
Let's not tie the two together.
I mentioned it because it suggests a good transition. We at least
have to think through how things map t
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the com
Avi Kivity wrote:
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
It's not at all that simple. SCSI has a hierarchical address
mechanism with 0-7 targets but then potentially multiple LUNs per
target. Today, we always emulate a single LUN per target but if we
ever wanted to support more than
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
then turns on the power. Command line options are the parts lying
around when we start.
btw, -drive needs to be separated:
-controller type=lsi1234,pci_addr=foobar,name=blah
-drive file=foo.img,controller=blah,index=0
-drive file=bar.img,
Avi Kivity wrote:
Certainly preferable to -baseline.
This is pretty easy to maintain with config files.
Let's not tie the two together.
I mentioned it because it suggests a good transition. We at least have
to think through how things map to the post-config file world regardless
of whet
Avi Kivity wrote:
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command
line
flags.
qemu -show-available-pci-sl
Avi Kivity wrote:
On 06/15/2009 03:45 PM, Anthony Liguori wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
Yes, the user build the machine using the command line and monitor
(or, in 2017, the mach
Hi,
Yes, the user build the machine using the command line and monitor
(or, in 2017, the machine configuration file),
Considering pbrook just posted a machine config for arm, I think it
would be rather sad if pc wasn't converted to it by 2017...
It shouldn't last until 2017, but the proces
On 06/15/2009 03:48 PM, Anthony Liguori wrote:
device tree lacking said attribute, distinguish between a device tree
from an old version of qemu (i.e. use the old default) and a partial
device tree from the VM manager (i.e. use the new default) ?
-baseline 0.10
That's a version number :-)
(I
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command line
flags.
qemu -show-available-pci-slots
Why does the us
On 06/15/2009 03:45 PM, Anthony Liguori wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
Yes, the user build the machine using the command line and monitor
(or, in 2017, the machine configuration f
On 06/15/2009 03:41 PM, Anthony Liguori wrote:
Yep, most people seem to agree that it makes sense to allow this, but
some believe it should only be via a machine description file, not the
command line.
I don't understand this opposition. It's clear a machine config file
is a long way in our f
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command line
flags.
qemu -show-available-pci-slots
(the qemu equivalent to KVM_CHECK_EXTENSION)
--
error compiling committee.
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command line
flags.
qemu -show-available-pci-slots
Why does the user care?
Let QEMU allocate the PCI slot,
Avi Kivity wrote:
On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
I think the point is that you don't need version numbers if you
have a
proper device tree.
How do you add a new attribute to the device tree and, when a supplied
device tree lacking said attribute, distinguish between
Avi Kivity wrote:
On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote:
On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
However, in order to retain compat for that SCSI device (e.g. ensuring
the PCI address doesn't change as other devices are added an removed),
we're back to the
On Mon, Jun 15, 2009 at 02:56:42PM +0300, Avi Kivity wrote:
> On 06/15/2009 02:48 PM, Michael S. Tsirkin wrote:
>>> A slot needs to be configured in ACPI,
>>>
>>
>> Can we configure all possible 32 slots?
>>
>
> That's what we do. But one is always taken. In the future, perhaps more.
>
Avi Kivity wrote:
On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
Yep, most people seem to agree that it makes sense to allow this, but
some believe i
On 06/15/2009 02:48 PM, Michael S. Tsirkin wrote:
A slot needs to be configured in ACPI,
Can we configure all possible 32 slots?
That's what we do. But one is always taken. In the future, perhaps more.
and not be taken by onboard chips
(piix takes slot 0, for example).
p
On Mon, Jun 15, 2009 at 02:27:14PM +0300, Avi Kivity wrote:
> On 06/15/2009 01:32 PM, Michael S. Tsirkin wrote:
>>> You do need to export available slot numbers from qemu.
>>>
>>
>> Why would a slot be unavailable?
>>
>
> A slot needs to be configured in ACPI,
Can we configure all possib
On Mon, Jun 15, 2009 at 02:14:15PM +0300, Gleb Natapov wrote:
> On Mon, Jun 15, 2009 at 02:07:53PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 15, 2009 at 01:52:13PM +0300, Gleb Natapov wrote:
> > > On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Jun 15, 200
On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
I think the point is that you don't need version numbers if you have a
proper device tree.
How do you add a new attribute to the device tree and, when a supplied
device tree lacking said attribute, distinguish between a device tree
from a
On 06/15/2009 01:32 PM, Michael S. Tsirkin wrote:
You do need to export available slot numbers from qemu.
Why would a slot be unavailable?
A slot needs to be configured in ACPI, and not be taken by onboard chips
(piix takes slot 0, for example).
--
error compiling committee.c: to
On Mon, Jun 15, 2009 at 02:07:53PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 01:52:13PM +0300, Gleb Natapov wrote:
> > On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> > > > On Mon, Jun 15, 200
On Mon, Jun 15, 2009 at 01:52:13PM +0300, Gleb Natapov wrote:
> On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> > > On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > > > > You do need to ex
On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> > On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > > > You do need to export available slot numbers from qemu.
> > >
> > > Why would a slot b
On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > > You do need to export available slot numbers from qemu.
> >
> > Why would a slot be unavailable?
> >
> Because it does not exist?
We can create a slot with an
On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > You do need to export available slot numbers from qemu.
>
> Why would a slot be unavailable?
>
Because it does not exist?
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
On Mon, Jun 15, 2009 at 12:27:08PM +0300, Avi Kivity wrote:
> On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
>>> This last option makes sense to me: in a real world the user has
>>> control over where he places the device on the bus, so why
>>> not with qemu?
>>>
>>
>> Yep, most people seem t
On Mon, Jun 15, 2009 at 12:43:48PM +0300, Avi Kivity wrote:
> On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote:
>> On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
>>
>>> However, in order to retain compat for that SCSI device (e.g. ensuring
>>> the PCI address doesn't change as
On Sun, 2009-06-14 at 10:58 +0300, Avi Kivity wrote:
> Mark McLoughlin wrote:
>
>
>
> >> I think the point is that you don't need version numbers if you have a
> >> proper device tree.
> >>
> >
> > How do you add a new attribute to the device tree and, when a supplied
> > device tree lac
On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote:
On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
However, in order to retain compat for that SCSI device (e.g. ensuring
the PCI address doesn't change as other devices are added an removed),
we're back to the same problem ...
On 06/14/2009 12:47 PM, Michael S. Tsirkin wrote:
Michael S. Tsirkin wrote:
If we want to remove a device from under a running guest, you need
hotplug. So we can't just remove several lines from the config and hope
that it'll work simply because the PCI address is stable.
Why not?
On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
Yep, most people seem to agree that it makes sense to allow this, but
some believe it should only be vi
On Sun, 2009-06-14 at 12:50 +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
> > However, in order to retain compat for that SCSI device (e.g. ensuring
> > the PCI address doesn't change as other devices are added an removed),
> > we're back to the
On Sun, 2009-06-14 at 12:34 +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2009 at 04:53:27PM +0100, Mark McLoughlin wrote:
> > The other obvious piece to add to it would be PCI addresses, so that
> > even if you remove a device, the addresses assigned to existing devices
> > don't change.
>
>
On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
> However, in order to retain compat for that SCSI device (e.g. ensuring
> the PCI address doesn't change as other devices are added an removed),
> we're back to the same problem ... either:
>
> 1) Use '-drive file=foo.img,if=scsi,
On Sun, Jun 14, 2009 at 12:37:13PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>>
>> If we want to remove a device from under a running guest, you need
>> hotplug. So we can't just remove several lines from the config and hope
>> that it'll work simply because the PCI address is stable.
>>
Michael S. Tsirkin wrote:
If we want to remove a device from under a running guest, you need
hotplug. So we can't just remove several lines from the config and hope
that it'll work simply because the PCI address is stable.
Why not?
OTOH, if you reboot the guest, it's ok for addresses to c
On Fri, Jun 12, 2009 at 04:53:27PM +0100, Mark McLoughlin wrote:
> On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
> > Mark McLoughlin wrote:
> > > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> > >
> > > = Solution - Separate configuration from compat hints =
> > >
> > > As
Mark McLoughlin wrote:
I think the point is that you don't need version numbers if you have a
proper device tree.
How do you add a new attribute to the device tree and, when a supplied
device tree lacking said attribute, distinguish between a device tree
from an old version of qemu (i.
Anthony Liguori wrote:
What's the problem with parsing the device config and modifying it?
Is it just complexity?
Two-way modification. Management wants to store the configuration in
their database and tell the hypervisor what the machine looks like. If
qemu also tells management what th
On Fri, 2009-06-12 at 20:44 +0300, Blue Swirl wrote:
> If the device has different behavior or different properties from
> guest perspective compared to the old device, it should get a new
> device type so that you could specify in the device tree either the
> old device or the new one.
Yes, that
On 6/12/09, Mark McLoughlin wrote:
> On Fri, 2009-06-12 at 12:00 -0500, Anthony Liguori wrote:
> > Mark McLoughlin wrote:
> > > So, when libvirt creates a guest for the first time, it makes a copy of
> > > the device tree and continues to use that even if qemu is upgraded.
> > > That's enough
On Fri, 2009-06-12 at 12:00 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > So, when libvirt creates a guest for the first time, it makes a copy of
> > the device tree and continues to use that even if qemu is upgraded.
> > That's enough to ensure compat is retained for all built-in devi
Mark McLoughlin wrote:
So, when libvirt creates a guest for the first time, it makes a copy of
the device tree and continues to use that even if qemu is upgraded.
That's enough to ensure compat is retained for all built-in devices.
However, in order to retain compat for that SCSI device (e.g. en
On Fri, 2009-06-12 at 11:12 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
> >
> >> Mark McLoughlin wrote:
> >>
> >>> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >>>
> >>> = Solution - Separate configurati
On Fri, 2009-06-12 at 11:11 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
> >
> >> Mark McLoughlin wrote:
> >>
> >>> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >>>
> >>>
> Michael S. Tsirkin
Mark McLoughlin wrote:
On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
Mark McLoughlin wrote:
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
= Solution - Separate configuration from compat hints =
As I suggested before:
- Allow the VM manager to dump compat hin
Mark McLoughlin wrote:
On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
Mark McLoughlin wrote:
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
Michael S. Tsirkin wrote:
I think the right long term answer to all this is a way to get QEMU to
dump
On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >
> > = Solution - Separate configuration from compat hints =
> >
> > As I suggested before:
> >
> > - Allow the VM manager to dump compat hints; this
On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >
> >> Michael S. Tsirkin wrote:
> >>
> I think the right long term answer to all this is a way to get QEMU to
> dump it's current machin
Mark McLoughlin wrote:
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
= Solution - Separate configuration from compat hints =
As I suggested before:
- Allow the VM manager to dump compat hints; this would be an opaque
file format, more like the savevm format than a config fil
Mark McLoughlin wrote:
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
Michael S. Tsirkin wrote:
I think the right long term answer to all this is a way to get QEMU to
dump it's current machine configuration in glorious detail as a file
which can be reloaded as a machine configur
On Fri, 2009-06-12 at 16:59 +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2009 at 09:43:29AM +0100, Mark McLoughlin wrote:
> > = Solution - Separate configuration from compat hints =
> >
> > As I suggested before:
> >
> > - Allow the VM manager to dump compat hints; this would be an opaque
On Fri, Jun 12, 2009 at 09:43:29AM +0100, Mark McLoughlin wrote:
> = Solution - Separate configuration from compat hints =
>
> As I suggested before:
>
> - Allow the VM manager to dump compat hints; this would be an opaque
> file format, more like the savevm format than a config file
Why
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> Michael S. Tsirkin wrote:
> > > I think the right long term answer to all this is a way to get QEMU to
> > > dump it's current machine configuration in glorious detail as a file
> > > which can be reloaded as a machine configuration.
> >
> >
97 matches
Mail list logo
