Re: [Engine-devel] Stable PCI/DEvice addresses
Moving this back to list - On 12/01/2011 01:49 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote:
Hi guys
I need the xml/json format representing the VM installed devices. Livnat asked me to add it to my Wiki http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
Please feel free to either send it to me or edit the VDSM section adding this info.
I think that it is wrong to document this in this point in time. The data is a blob, generated by libvirt, copied by Vdsm, and not expected to be editted by RHEV-M.
If you REALLY want to know, it is simply libvirt's domain xml, which is well-documented in http://libvirt.org/formatdomain.html.
Dan.
Hi Dan, Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed. Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM. Livnat
On Thu, Dec 01, 2011 at 02:06:52PM +0200, Livnat Peer wrote:
Moving this back to list -
On 12/01/2011 01:49 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote:
Hi guys
I need the xml/json format representing the VM installed devices. Livnat asked me to add it to my Wiki http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
Please feel free to either send it to me or edit the VDSM section adding this info.
I think that it is wrong to document this in this point in time. The data is a blob, generated by libvirt, copied by Vdsm, and not expected to be editted by RHEV-M.
If you REALLY want to know, it is simply libvirt's domain xml, which is well-documented in http://libvirt.org/formatdomain.html.
Dan.
Hi Dan,
Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed.
Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM.
The requirement for 3.1 alowed me to define an opaque parameter, with which Vdsm uses the Engine to store the VM device addresses. We "secretly" opted for storing the libvirt domxml because it already contains addresses for just about anything, and would alow us to do even more evil things in the future (I'm thinking about specifying complete boot order, and other things which libvirt long supports, but Vdsm does not). Another reason was that this was a very simple thing to do. The down side is that this "device-blob" is a bit bloated in size, and if you look deep into it, it has duplicate information on top of Vdsm's "create" verb. We should probably not include the <source> elements in the blob they are very verbose and uninteresting to RHEV-M. If stressed, Vdsm could report only the <devices> element. It could also convert it to json or yaml, compress and encrypt it - but I do not see the point of these transformations. Dan.
On Thursday 01 December 2011 16:11:07 Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 02:06:52PM +0200, Livnat Peer wrote:
Moving this back to list -
On 12/01/2011 01:49 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote:
Hi guys
I need the xml/json format representing the VM installed devices. Livnat asked me to add it to my Wiki http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
Please feel free to either send it to me or edit the VDSM section adding this info.
I think that it is wrong to document this in this point in time. The data is a blob, generated by libvirt, copied by Vdsm, and not expected to be editted by RHEV-M.
If you REALLY want to know, it is simply libvirt's domain xml, which is well-documented in http://libvirt.org/formatdomain.html.
Dan.
Hi Dan,
Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed.
Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM.
The requirement for 3.1 alowed me to define an opaque parameter, with which Vdsm uses the Engine to store the VM device addresses.
We "secretly" opted for storing the libvirt domxml because it already contains addresses for just about anything, and would alow us to do even more evil things in the future (I'm thinking about specifying complete boot order, and other things which libvirt long supports, but Vdsm does not). Another reason was that this was a very simple thing to do. The down side is that this "device-blob" is a bit bloated in size, and if you look deep into it, it has duplicate information on top of Vdsm's "create" verb.
We should probably not include the <source> elements in the blob they are very verbose and uninteresting to RHEV-M.
If stressed, Vdsm could report only the <devices> element. It could also convert it to json or yaml, compress and encrypt it - but I do not see the point of these transformations.
Dan.
The direction this is taking is for Engine core to be able to parse and edit libvirt's domxml, while vdsm is agnostic (or partially agnostic) to the blob. Is this what we really need? want? -- /d Never say "OOPS!" always say "Ah, Interesting!"
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: engine-devel@ovirt.org, "Igor Lvovsky" <ilvovsky@redhat.com> Sent: Thursday, December 1, 2011 10:52:42 AM Subject: Re: [Engine-devel] Stable PCI/DEvice addresses
On Thursday 01 December 2011 16:11:07 Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 02:06:52PM +0200, Livnat Peer wrote:
Moving this back to list -
On 12/01/2011 01:49 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote:
Hi guys
I need the xml/json format representing the VM installed devices. Livnat asked me to add it to my Wiki http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
Please feel free to either send it to me or edit the VDSM section adding this info.
I think that it is wrong to document this in this point in time. The data is a blob, generated by libvirt, copied by Vdsm, and not expected to be editted by RHEV-M.
If you REALLY want to know, it is simply libvirt's domain xml, which is well-documented in http://libvirt.org/formatdomain.html.
Dan.
Hi Dan,
Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed.
Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM.
The requirement for 3.1 alowed me to define an opaque parameter, with which Vdsm uses the Engine to store the VM device addresses.
We "secretly" opted for storing the libvirt domxml because it already contains addresses for just about anything, and would alow us to do even more evil things in the future (I'm thinking about specifying complete boot order, and other things which libvirt long supports, but Vdsm does not). Another reason was that this was a very simple thing to do. The down side is that this "device-blob" is a bit bloated in size, and if you look deep into it, it has duplicate information on top of Vdsm's "create" verb.
We should probably not include the <source> elements in the blob they are very verbose and uninteresting to RHEV-M.
If stressed, Vdsm could report only the <devices> element. It could also convert it to json or yaml, compress and encrypt it - but I do not see the point of these transformations.
Dan.
The direction this is taking is for Engine core to be able to parse and edit libvirt's domxml, while vdsm is agnostic (or partially agnostic) to the blob.
Is this what we really need? want?
When we discuss the blob are we talking about just the address part - eg . <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> or something more?
--
/d
Never say "OOPS!" always say "Ah, Interesting!" _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Thu, Dec 01, 2011 at 02:09:42PM -0500, Andrew Cathrow wrote:
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: engine-devel@ovirt.org, "Igor Lvovsky" <ilvovsky@redhat.com> Sent: Thursday, December 1, 2011 10:52:42 AM Subject: Re: [Engine-devel] Stable PCI/DEvice addresses
On Thursday 01 December 2011 16:11:07 Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 02:06:52PM +0200, Livnat Peer wrote:
Moving this back to list -
On 12/01/2011 01:49 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote:
Hi guys
I need the xml/json format representing the VM installed devices. Livnat asked me to add it to my Wiki http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
Please feel free to either send it to me or edit the VDSM section adding this info.
I think that it is wrong to document this in this point in time. The data is a blob, generated by libvirt, copied by Vdsm, and not expected to be editted by RHEV-M.
If you REALLY want to know, it is simply libvirt's domain xml, which is well-documented in http://libvirt.org/formatdomain.html.
Dan.
Hi Dan,
Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed.
Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM.
The requirement for 3.1 alowed me to define an opaque parameter, with which Vdsm uses the Engine to store the VM device addresses.
We "secretly" opted for storing the libvirt domxml because it already contains addresses for just about anything, and would alow us to do even more evil things in the future (I'm thinking about specifying complete boot order, and other things which libvirt long supports, but Vdsm does not). Another reason was that this was a very simple thing to do. The down side is that this "device-blob" is a bit bloated in size, and if you look deep into it, it has duplicate information on top of Vdsm's "create" verb.
We should probably not include the <source> elements in the blob they are very verbose and uninteresting to RHEV-M.
If stressed, Vdsm could report only the <devices> element. It could also convert it to json or yaml, compress and encrypt it - but I do not see the point of these transformations.
Dan.
The direction this is taking is for Engine core to be able to parse and edit libvirt's domxml, while vdsm is agnostic (or partially agnostic) to the blob.
Is this what we really need? want?
When we discuss the blob are we talking about just the address part - eg . <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
or something more?
This is exactly the question. Until today, the blob was just a blob, opaque to the engine, and there was no discussion. If the engine wants to be able to control and edit the device addresses, we must agree on how to represent the address for each device type, and how to name each device. The simplest solution is to tap on the good work of the libvirt chaps. If we ever want to, it would allow the Engine to do the crazier stuff alluded by Doron - but it does not force us to go down this path, though. In my original design I imagined the blob to be a complete libvirt domxml. However, I understand the benefits of a more specific "blob". For the feature at hand, it is safe to limit this down to the <devices> element, with its <source> elements stripped, and possibly converted to your data representation language du jour. Dan.
On 12/01/2011 10:41 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 02:09:42PM -0500, Andrew Cathrow wrote:
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: engine-devel@ovirt.org, "Igor Lvovsky" <ilvovsky@redhat.com> Sent: Thursday, December 1, 2011 10:52:42 AM Subject: Re: [Engine-devel] Stable PCI/DEvice addresses
On Thursday 01 December 2011 16:11:07 Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 02:06:52PM +0200, Livnat Peer wrote:
Moving this back to list -
On 12/01/2011 01:49 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote: > Hi guys > > I need the xml/json format representing the VM installed > devices. > Livnat asked me to add it to my Wiki > http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses > > Please feel free to either send it to me or edit the VDSM > section adding this info.
I think that it is wrong to document this in this point in time. The data is a blob, generated by libvirt, copied by Vdsm, and not expected to be editted by RHEV-M.
If you REALLY want to know, it is simply libvirt's domain xml, which is well-documented in http://libvirt.org/formatdomain.html.
Dan.
Hi Dan,
Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed.
Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM.
The requirement for 3.1 alowed me to define an opaque parameter, with which Vdsm uses the Engine to store the VM device addresses.
We "secretly" opted for storing the libvirt domxml because it already contains addresses for just about anything, and would alow us to do even more evil things in the future (I'm thinking about specifying complete boot order, and other things which libvirt long supports, but Vdsm does not). Another reason was that this was a very simple thing to do. The down side is that this "device-blob" is a bit bloated in size, and if you look deep into it, it has duplicate information on top of Vdsm's "create" verb.
We should probably not include the <source> elements in the blob they are very verbose and uninteresting to RHEV-M.
If stressed, Vdsm could report only the <devices> element. It could also convert it to json or yaml, compress and encrypt it - but I do not see the point of these transformations.
Dan.
The direction this is taking is for Engine core to be able to parse and edit libvirt's domxml, while vdsm is agnostic (or partially agnostic) to the blob.
Is this what we really need? want?
When we discuss the blob are we talking about just the address part - eg . <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
or something more?
This is exactly the question. Until today, the blob was just a blob, opaque to the engine, and there was no discussion.
If the engine wants to be able to control and edit the device addresses, we must agree on how to represent the address for each device type, and how to name each device. The simplest solution is to tap on the good work of the libvirt chaps. If we ever want to, it would allow the Engine to do the crazier stuff alluded by Doron - but it does not force us to go down this path, though.
In my original design I imagined the blob to be a complete libvirt domxml. However, I understand the benefits of a more specific "blob". For the feature at hand, it is safe to limit this down to the <devices> element, with its <source> elements stripped, and possibly converted to your data representation language du jour.
Dan.
Hi Dan, I understand why pass-through of the domxml is appealing, as it reduces work for the current feature, it is also enabling us easily to support all type of device addresses that are supported by libvirt. What i like less is the format, I rather not use a verbose xml for this but use JSON as we have in several other places in the engine. The next cycle on this feature is to expose the ability to edit addresses by the user, and for that we'll need to manipulate the domxml in the engine - less fun. So although it is more work for us now i rather get the device section in a JSON format. BTW - Is there a chance libvirt will support JSON format in the future for describing the VM? then we can use the format they suggest for this and it can be a JSON pass-through in the future ;) Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Sat, Dec 03, 2011 at 11:47:35AM +0200, Livnat Peer wrote:
On 12/01/2011 10:41 PM, Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 02:09:42PM -0500, Andrew Cathrow wrote:
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: engine-devel@ovirt.org, "Igor Lvovsky" <ilvovsky@redhat.com> Sent: Thursday, December 1, 2011 10:52:42 AM Subject: Re: [Engine-devel] Stable PCI/DEvice addresses
On Thursday 01 December 2011 16:11:07 Dan Kenigsberg wrote:
On Thu, Dec 01, 2011 at 02:06:52PM +0200, Livnat Peer wrote:
Moving this back to list -
On 12/01/2011 01:49 PM, Dan Kenigsberg wrote: > On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote: >> Hi guys >> >> I need the xml/json format representing the VM installed >> devices. >> Livnat asked me to add it to my Wiki >> http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses >> >> Please feel free to either send it to me or edit the VDSM >> section adding this info. > > I think that it is wrong to document this in this point in > time. The > data is a blob, generated by libvirt, copied by Vdsm, and not > expected > to be editted by RHEV-M. > > If you REALLY want to know, it is simply libvirt's domain xml, > which is > well-documented in http://libvirt.org/formatdomain.html. > > Dan. >
Hi Dan,
Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed.
Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM.
The requirement for 3.1 alowed me to define an opaque parameter, with which Vdsm uses the Engine to store the VM device addresses.
We "secretly" opted for storing the libvirt domxml because it already contains addresses for just about anything, and would alow us to do even more evil things in the future (I'm thinking about specifying complete boot order, and other things which libvirt long supports, but Vdsm does not). Another reason was that this was a very simple thing to do. The down side is that this "device-blob" is a bit bloated in size, and if you look deep into it, it has duplicate information on top of Vdsm's "create" verb.
We should probably not include the <source> elements in the blob they are very verbose and uninteresting to RHEV-M.
If stressed, Vdsm could report only the <devices> element. It could also convert it to json or yaml, compress and encrypt it - but I do not see the point of these transformations.
Dan.
The direction this is taking is for Engine core to be able to parse and edit libvirt's domxml, while vdsm is agnostic (or partially agnostic) to the blob.
Is this what we really need? want?
When we discuss the blob are we talking about just the address part - eg . <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
or something more?
This is exactly the question. Until today, the blob was just a blob, opaque to the engine, and there was no discussion.
If the engine wants to be able to control and edit the device addresses, we must agree on how to represent the address for each device type, and how to name each device. The simplest solution is to tap on the good work of the libvirt chaps. If we ever want to, it would allow the Engine to do the crazier stuff alluded by Doron - but it does not force us to go down this path, though.
In my original design I imagined the blob to be a complete libvirt domxml. However, I understand the benefits of a more specific "blob". For the feature at hand, it is safe to limit this down to the <devices> element, with its <source> elements stripped, and possibly converted to your data representation language du jour.
Dan.
Hi Dan,
I understand why pass-through of the domxml is appealing, as it reduces work for the current feature, it is also enabling us easily to support all type of device addresses that are supported by libvirt.
What i like less is the format, I rather not use a verbose xml for this but use JSON as we have in several other places in the engine.
The next cycle on this feature is to expose the ability to edit addresses by the user, and for that we'll need to manipulate the domxml in the engine - less fun.
So although it is more work for us now i rather get the device section in a JSON format.
I'm not sure I understand why xml->json conversion is more fun to do in Vdsm than in Engine; I don't see it as a difficult step either way. The problem is that we have an already-well-defined interface for device naming and addressing (libvirt's). Inventing another one, even if it is only a straight-forward xml-to-json conversion, would inevitably add doubts and places for bugs.
BTW - Is there a chance libvirt will support JSON format in the future for describing the VM? then we can use the format they suggest for this and it can be a JSON pass-through in the future ;)
It has been years since I've touched infinitesimal probabilities, so I shall leave this question to a libvirt Daniel. Dan.
On Sat, Dec 03, 2011 at 11:47:35AM +0200, Livnat Peer wrote:
BTW - Is there a chance libvirt will support JSON format in the future for describing the VM? then we can use the format they suggest for this and it can be a JSON pass-through in the future ;)
If an application wants to use JSON, then just use a standard JSON<->XML convertor. There's no need todo this directly in libvirt. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (5)
-
Andrew Cathrow -
Dan Kenigsberg -
Daniel P. Berrange -
Doron Fediuck -
Livnat Peer