[Libvir] Updated patch for hvm guests
Attached is an updated patch providing some support for HVM guests. I have tested listing info on running guests and creating guests. cdrom support for HVM guests still needs some work, as does graphics options. Guests using graphics type 'sdl' still need some work. Using type 'vnc' is functional, but you must then manually use e.g. "vncviewer localhost:<dom_id>" to view. I've also included a patch that backs out some optimizations done xend_internal.c. There is a bug in xend (from testing - I think Anthony fixed it and patch got applied to unstable) that does not close the connection after initial create op causing libvirt to block indefinitely. Backing out the optimizations allowed me to use the hvm patch on _testing branch of xen. I've included it for anyone else that may want to experiment with the hvm patch on _testing xen. Finally, the attached archive contains: 1. a sample xml input file for hvm guest, 2. corresponding s-expr sent to xend, and 3. s-expr returned from xend when getting info on the running guest. I will be on vacation and not have access to network until July 9. I will improve this work after returning. Enjoy, Jim
Hi Jim, hope you enjoyed your vacations :-) On Fri, Jun 30, 2006 at 04:02:54PM -0600, Jim Fehlig wrote:
Attached is an updated patch providing some support for HVM guests. I have tested listing info on running guests and creating guests. cdrom support for HVM guests still needs some work, as does graphics options. Guests using graphics type 'sdl' still need some work. Using type 'vnc' is functional, but you must then manually use e.g. "vncviewer localhost:<dom_id>" to view.
Okay, I have been looking at it in the last couple of days I have changed the XML description slightly in the os part: - instead stating that hvmloader is a kernel, well I used a <loader>/usr/lib/xen/boot/hvmloader</loader> loader tag intead, contrary to the non HVM version the kernel doesn't point to a kernel file, so better rename to what it actually is - second the device_model is really a device emulator, better placed in the <devices> section so it is moved there as <emulator>/usr/lib/xen/bin/qemu-dm</emulator> I have made changes to the XML conversion code to reflect this, I will commit whithin one hour or two. Attached is one example of the XML for HVM.
I've also included a patch that backs out some optimizations done xend_internal.c. There is a bug in xend (from testing - I think Anthony fixed it and patch got applied to unstable) that does not close the connection after initial create op causing libvirt to block indefinitely. Backing out the optimizations allowed me to use the hvm patch on _testing branch of xen. I've included it for anyone else that may want to experiment with the hvm patch on _testing xen.
Okay I applied it, it is clearly identified and we can revert it later, more likely this current code will die slowly when converted to XML-RPC.
Finally, the attached archive contains: 1. a sample xml input file for hvm guest, 2. corresponding s-expr sent to xend, and 3. s-expr returned from xend when getting info on the running guest.
Thanks, that helped a lot :-) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote:
I have made changes to the XML conversion code to reflect this, I will commit whithin one hour or two. Attached is one example of the XML for HVM.
Okay, I commited it, I also extended the page describing the XML format to cover the new HVM domains. I was able to launch a domain and attach to the vnc server so it seems to work for me at least in a minimal canonical configuration. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Jul 10, 2006 at 09:02:32AM -0400, Daniel Veillard wrote:
On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote:
I have made changes to the XML conversion code to reflect this, I will commit whithin one hour or two. Attached is one example of the XML for HVM.
Okay, I commited it, I also extended the page describing the XML format to cover the new HVM domains. I was able to launch a domain and attach to the vnc server so it seems to work for me at least in a minimal canonical configuration.
On the subject of VNC server, the element currently just contains <graphics type='vnc'/> Now the (undocumented) assumption is that the VNC server is listening on a port number 5900+<domain id>. eg, Domain 3 listens on port 5903. This may be fine for dev / testing purposes, but this is not really a acceptable assumption to make long term. Xen could quite easily change to allocate arbitrary ports to each domain on a first-come, first-serve basis. When libVirt is ported to QEMU, there will be no correlation between domain ID and vnc port number. Thus I'd suggest we extend the XML for VNC thus: <graphics type='vnc'> <listen port="5903"/> </graphics> XenD doesn't currently give us the port number in the SEXPR it returns so we'll have to have code to explicitly insert a suitable <listen/> tag manually, but its well worth it, avoiding need to hardcode port number assumptions in application code. On a similar theme, Xen provides a serial console for each guest domain. Curently people access it with 'xm console <blah>', however, the actual console is just a psuedo TTY, so if one knows the /dev/pts/<N> path there is no need to use 'xm console' at all. Thus I think we could have another TODO item, to add '<serial port="/dev/pts/3"/>' element to the <devices> section of the XML. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Mon, Jul 10, 2006 at 06:59:03PM +0100, Daniel P. Berrange wrote:
On Mon, Jul 10, 2006 at 09:02:32AM -0400, Daniel Veillard wrote:
On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote:
I have made changes to the XML conversion code to reflect this, I will commit whithin one hour or two. Attached is one example of the XML for HVM.
Okay, I commited it, I also extended the page describing the XML format to cover the new HVM domains. I was able to launch a domain and attach to the vnc server so it seems to work for me at least in a minimal canonical configuration.
On the subject of VNC server, the element currently just contains
<graphics type='vnc'/>
Now the (undocumented) assumption is that the VNC server is listening on a port number 5900+<domain id>. eg, Domain 3 listens on port 5903. This may be fine for dev / testing purposes, but this is not really a acceptable assumption to make long term. Xen could quite easily change to allocate arbitrary ports to each domain on a first-come, first-serve basis. When libVirt is ported to QEMU, there will be no correlation between domain ID and vnc port number. Thus I'd suggest we extend the XML for VNC thus:
<graphics type='vnc'> <listen port="5903"/> </graphics>
I definitely agree that the current device description is very limited, nearly undocumented (but I put a warning at the end of http://libvirt.org/format.html#Fully1 ) starting it would certainly be extended. So yes definitely we need to expose more (and if you know parameters for sdl I'm all ears, I didn't found any docs about it !) Now from a syntactic point of view, I think it would be just fine to use <graphics type='vnc' port='5903'>, in that case there is only one port and keeping it as an optional attribute will make it easir to parse in/out
XenD doesn't currently give us the port number in the SEXPR it returns so we'll have to have code to explicitly insert a suitable <listen/> tag manually, but its well worth it, avoiding need to hardcode port number assumptions in application code.
Hum, so you would like to automatically default it ? I still think <graphics type='vnc'/> should be an accepted input meaning "whatever is the default", but fine to add it back on any dump. Would that suit you ?
On a similar theme, Xen provides a serial console for each guest domain. Curently people access it with 'xm console <blah>', however, the actual console is just a psuedo TTY, so if one knows the /dev/pts/<N> path there is no need to use 'xm console' at all. Thus I think we could have another TODO item, to add '<serial port="/dev/pts/3"/>' element to the <devices> section of the XML.
Okay, how do you extract the right N ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Jul 10, 2006 at 04:27:55PM -0400, Daniel Veillard wrote:
On Mon, Jul 10, 2006 at 06:59:03PM +0100, Daniel P. Berrange wrote:
On Mon, Jul 10, 2006 at 09:02:32AM -0400, Daniel Veillard wrote:
On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote:
I have made changes to the XML conversion code to reflect this, I will commit whithin one hour or two. Attached is one example of the XML for HVM.
Okay, I commited it, I also extended the page describing the XML format to cover the new HVM domains. I was able to launch a domain and attach to the vnc server so it seems to work for me at least in a minimal canonical configuration.
On the subject of VNC server, the element currently just contains
<graphics type='vnc'/>
Now the (undocumented) assumption is that the VNC server is listening on a port number 5900+<domain id>. eg, Domain 3 listens on port 5903. This may be fine for dev / testing purposes, but this is not really a acceptable assumption to make long term. Xen could quite easily change to allocate arbitrary ports to each domain on a first-come, first-serve basis. When libVirt is ported to QEMU, there will be no correlation between domain ID and vnc port number. Thus I'd suggest we extend the XML for VNC thus:
<graphics type='vnc'> <listen port="5903"/> </graphics>
I definitely agree that the current device description is very limited, nearly undocumented (but I put a warning at the end of http://libvirt.org/format.html#Fully1 ) starting it would certainly be extended. So yes definitely we need to expose more (and if you know parameters for sdl I'm all ears, I didn't found any docs about it !) Now from a syntactic point of view, I think it would be just fine to use <graphics type='vnc' port='5903'>, in that case there is only one port and keeping it as an optional attribute will make it easir to parse in/out
I really don't think we should have it optional, because this will force every application using libvirt, to hardcode the assumption 'VNC port ==5900 + domain id' If this changes in the future then all these apps would break - libvirt should be providing a reliable API for apps, so we should move the assumption inside libvirt in the code which generates the '<graphics ...>' block, isolating the application from any change in this assumption.
XenD doesn't currently give us the port number in the SEXPR it returns so we'll have to have code to explicitly insert a suitable <listen/> tag manually, but its well worth it, avoiding need to hardcode port number assumptions in application code.
Hum, so you would like to automatically default it ? I still think <graphics type='vnc'/> should be an accepted input meaning "whatever is the default", but fine to add it back on any dump. Would that suit you ?
I don't want to have any knowledge about 'defaults' in my app because I know this will break in the future :-(
Curently people access it with 'xm console <blah>', however, the actual console is just a psuedo TTY, so if one knows the /dev/pts/<N> path there is no need to use 'xm console' at all. Thus I think we could have another TODO item, to add '<serial port="/dev/pts/3"/>' element to the <devices> section of the XML.
Okay, how do you extract the right N ?
That's what I'm not too clear on yet - I hoped it was in the information returned byu XenD SEXPR, but it doesn't look like it is. Instead it looks like it is in the XenStore tree somewhere. This isn't an urgent feature request - I just wanted to put it on the TODO list for when someone had time to look at it. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Jul 11, 2006 at 01:47:05PM +0100, Daniel P. Berrange wrote:
On Mon, Jul 10, 2006 at 04:27:55PM -0400, Daniel Veillard wrote:
Hum, so you would like to automatically default it ? I still think <graphics type='vnc'/> should be an accepted input meaning "whatever is the default", but fine to add it back on any dump. Would that suit you ?
I don't want to have any knowledge about 'defaults' in my app because I know this will break in the future :-(
You don't have to rely on defaults. Either you write the XML, then you put the port and you are fine, and if you read the XML then we garantee you get the port associated. So I don't see how my suggestion would break your requirement. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Jul 11, 2006 at 08:54:50AM -0400, Daniel Veillard wrote:
On Tue, Jul 11, 2006 at 01:47:05PM +0100, Daniel P. Berrange wrote:
On Mon, Jul 10, 2006 at 04:27:55PM -0400, Daniel Veillard wrote:
Hum, so you would like to automatically default it ? I still think <graphics type='vnc'/> should be an accepted input meaning "whatever is the default", but fine to add it back on any dump. Would that suit you ?
I don't want to have any knowledge about 'defaults' in my app because I know this will break in the future :-(
You don't have to rely on defaults. Either you write the XML, then you put the port and you are fine, and if you read the XML then we garantee you get the port associated. So I don't see how my suggestion would break your requirement.
Ahh, I see what you mean - yes, having it optional when writing XML is fine, if reading XML is always guarenteed to include port. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Daniel Veillard wrote:
On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote:
I have made changes to the XML conversion code to reflect this, I will commit whithin one hour or two. Attached is one example of the XML for HVM.
Okay, I commited it, I also extended the page describing the XML format to cover the new HVM domains. I was able to launch a domain and attach to the vnc server so it seems to work for me at least in a minimal canonical configuration.
Thanks for finishing this Daniel - sorry to have dumped it with no updated documentation, etc. If I find some spare cycles this week would like to experiment with more exotic HVM configurations and improve support for cdrom, graphics, and anything else that may be deficient for HVM guests. Regards, Jim
On Mon, Jul 10, 2006 at 06:16:21PM -0600, Jim Fehlig wrote:
Daniel Veillard wrote:
On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote:
I have made changes to the XML conversion code to reflect this, I will commit whithin one hour or two. Attached is one example of the XML for HVM.
Okay, I commited it, I also extended the page describing the XML format to cover the new HVM domains. I was able to launch a domain and attach to the vnc server so it seems to work for me at least in a minimal canonical configuration.
Thanks for finishing this Daniel - sorry to have dumped it with no updated documentation, etc.
No problem, thank you to have started this !
If I find some spare cycles this week would like to experiment with more exotic HVM configurations and improve support for cdrom, graphics, and anything else that may be deficient for HVM guests.
Well as Dan Berrange pointed out, we probably need to provide more tunable informations for the graphic options (I looked for information on sdl but really didn't found much), and from the mail exchanged in the xen-devel list I would expect some kind of SCSI emulation support coming in the QEmu emulation too. I will probably push a version 0.1.3 later today with the optmization and the current hvm so it will be easier to get more testing done outside of this list. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Jim Fehlig