[libvirt] [PATCH 1/1] Support for RDP
Hi All, I have added support for RDP. Just forwarding the patch for review. Regards, Pritesh
On Thu, Apr 16, 2009 at 11:21:23AM +0200, Pritesh Kothari wrote:
Hi All,
I have added support for RDP.
So, summarizing your suggested XML syntax, it more or less looked like this: <graphics type='rdp' port='12345' listen='172.21.4.3' autoport='no' headless='yes' reuseConnection='yes' allowMultiConnections='yes' auth='external' authtimeout='1234'/> Historically with Xen and QEMU there has only been ability to have either SDL graphics, or VNC graphics, but not both. With VirtualBox you can actually have the local desktop window *and* RDP at the same time, or just the local desktop, or just RDP, or neither. There seems to be a SDL graphics mode too, but the docs says that's only really for developers, and it doesn't look to be exposed in the API This really says to me that we should represent the virtualbox graphics configuration with 2 separate <graphics> tags, one for the local desktop display config, and one for the RDP config. <graphics type='desktop'/> <graphics type='rdp' port='1234' autoport='no' listen='172.21.4.3'/> If RDP is not enabled, then don't include the 2nd. If the local desktop display is not enabled, then don't include the 1st. This avoids the the 'headless' attribute being exposed in the XML directly. I chose type='desktop' as representing the 'native' desktop app display of the virt technology in question. I imagine it'll take similar attributes to the type=sdl, while the type=rdp would be similar to type=vnc. For the allowMultiConnection & reuseSingleConnection attributes, I think i'd prefer something a little less verbose as the XML attribute names. How about multiUser='yes|no' (for allowMultiConnection) replaceUser='yes|no' (for reuseSingleConnection) For the local desktop window, is there any way in the API to indicate what X display it should be shown on ? Obviously if launched within a desktop session it'll display on that session. If I ssh into a remote machine though, currently virtualbox libvirt driver will start the display on the $DISPLAY from the forwarded SSH session virsh is running in which isn't really what I wanted. I think we really need to be able to indicate a desired X $DISPLAY (or equiv) in the XML for the local desktop window graphics mode, eg, akin to the current SDL config we could have <graphics type='desktop' display=':0.0'/> Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Hi Daniel,
<graphics type='desktop'/> <graphics type='rdp' port='1234' autoport='no' listen='172.21.4.3'/>
this seems ok, but the only question I have is, currently libvirt supports only one virDomainGraphicsDef, so is it ok for me add support for more then one virDomainGraphicsDef? or else i don't see how i can have multiple <graphics> tags.
If RDP is not enabled, then don't include the 2nd. If the local desktop display is not enabled, then don't include the 1st. This avoids the the 'headless' attribute being exposed in the XML directly. I chose type='desktop' as representing the 'native' desktop app display of the virt technology in question. I imagine it'll take similar attributes to the type=sdl, while the type=rdp would be similar to type=vnc.
I had included headless attribute cause only one virDomainGraphicsDef was there. I think that would not be necessary now if we support for more then one virDomainGraphicsDef's, also adding multiple virDomainGraphicsDef's will help me to implement some features for multiple screens :)
For the allowMultiConnection & reuseSingleConnection attributes, I think i'd prefer something a little less verbose as the XML attribute names. How about
multiUser='yes|no' (for allowMultiConnection) replaceUser='yes|no' (for reuseSingleConnection)
great no problem, i guess i was just bogged down by too much details.
For the local desktop window, is there any way in the API to indicate what X display it should be shown on ? Obviously if launched within a desktop session it'll display on that session. If I ssh into a remote machine though, currently virtualbox libvirt driver will start the display on the $DISPLAY from the forwarded SSH session virsh is running in which isn't really what I wanted. I think we really need to be able to indicate a desired X $DISPLAY (or equiv) in the XML for the local desktop window graphics mode, eg, akin to the current SDL config we could have
<graphics type='desktop' display=':0.0'/>
yes, there is an API for it as well but currently I am using getenv("DISPLAY");implementing this was in my todo but didn't quite make it to top, but will try to make it in next set of patches. feedback about attributes (auth='external' authtimeout='1234') would also be appreciated. Thanks. Regards, Pritesh
On Thu, Apr 23, 2009 at 01:32:24PM +0200, Pritesh Kothari wrote:
Hi Daniel,
<graphics type='desktop'/> <graphics type='rdp' port='1234' autoport='no' listen='172.21.4.3'/>
this seems ok, but the only question I have is, currently libvirt supports only one virDomainGraphicsDef, so is it ok for me add support for more then one virDomainGraphicsDef? or else i don't see how i can have multiple <graphics> tags.
yes this is a limitation of the impelentation, not of the model, it makes more sense to allow multiple graphis entries.
If RDP is not enabled, then don't include the 2nd. If the local desktop display is not enabled, then don't include the 1st. This avoids the the 'headless' attribute being exposed in the XML directly. I chose type='desktop' as representing the 'native' desktop app display of the virt technology in question. I imagine it'll take similar attributes to the type=sdl, while the type=rdp would be similar to type=vnc.
I had included headless attribute cause only one virDomainGraphicsDef was there. I think that would not be necessary now if we support for more then one virDomainGraphicsDef's, also adding multiple virDomainGraphicsDef's will help me to implement some features for multiple screens :)
You mean you have multiple screen support. Hum, it would have been good to align with some of the Xorg naming for handling this. Though what is Screen for them would still be a graphic for us.
For the allowMultiConnection & reuseSingleConnection attributes, I think i'd prefer something a little less verbose as the XML attribute names. How about
multiUser='yes|no' (for allowMultiConnection) replaceUser='yes|no' (for reuseSingleConnection)
great no problem, i guess i was just bogged down by too much details.
also it's more generic and may be useful as other protocol evolves
For the local desktop window, is there any way in the API to indicate what X display it should be shown on ? Obviously if launched within a desktop session it'll display on that session. If I ssh into a remote machine though, currently virtualbox libvirt driver will start the display on the $DISPLAY from the forwarded SSH session virsh is running in which isn't really what I wanted. I think we really need to be able to indicate a desired X $DISPLAY (or equiv) in the XML for the local desktop window graphics mode, eg, akin to the current SDL config we could have
<graphics type='desktop' display=':0.0'/>
yes, there is an API for it as well but currently I am using getenv("DISPLAY");implementing this was in my todo but didn't quite make it to top, but will try to make it in next set of patches.
Hum, getenv() is problematic in the absolute. Informations in the XML config file should be sufficient to restore the state of the virtual machine. I'm always trying to think with the following scenario: - domain runs on hypervisor in node A - domain gets migrated to node B - if one get an XML domain dump at that point, will the informations still be fully valid and sufficient to restart it from node B ? Here being able to stick the rendring to a given display may be required, or harmful depending on the use case, which call for the ability to either pin it with a display using a full name foobar:0.0 or display='local' (or the absence of a display information assumed syntactically equivalent) where you would use the getenv("DISPLAY")
feedback about attributes (auth='external' authtimeout='1234') would also be appreciated. Thanks.
auth='external' sounds unclear, what does this mean ? Having the timeout hardcoded in the domain config file sounds a bit weird to me I would expect the default behaviour to be sufficient, depending on the networking layer used. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Hi Daniel,
yes this is a limitation of the impelentation, not of the model, it makes more sense to allow multiple graphis entries.
Ok, will do this.
feedback about attributes (auth='external' authtimeout='1234') would also be appreciated. Thanks.
auth='external' sounds unclear, what does this mean ? Having the timeout hardcoded in the domain config file sounds a bit weird to me I would expect the default behaviour to be sufficient, depending on the networking layer used.
sorry, i thought i explained it earlier somwhere. auth="" basically says which authentication method to use, the details are as below: 1) The "null" method means that there is no authentication at all; any client can connect to the VRDP server and thus the virtual machine. This is, of course, very insecure and only to be recommended for private networks. 2) The "external" method provides external authentication through a special authentication library. VirtualBox comes with two default libraries for external authentication: On Linux hosts, VRDPAuth.so authenticates users against the host's PAM system. On Windows hosts, VRDPAuth.dll authenticates users against the host's WinLogon system. In other words, the "external" method per default performs authentication with the user accounts that exist on the host system. However, you can replace the default "external" authentication module with any other module. 3) The "guest" authentication method performs authentication with a special component that comes with the Guest Additions; as a result, authentication is not performed with the host users, but with the guest user accounts. regarding authtimeout='5000', i guess it would do with default. Regards, Pritesh
On Thu, Apr 23, 2009 at 01:32:24PM +0200, Pritesh Kothari wrote:
Hi Daniel,
<graphics type='desktop'/> <graphics type='rdp' port='1234' autoport='no' listen='172.21.4.3'/>
this seems ok, but the only question I have is, currently libvirt supports only one virDomainGraphicsDef, so is it ok for me add support for more then one virDomainGraphicsDef? or else i don't see how i can have multiple <graphics> tags.
Yep, that fact that we only parse one graphics card is just a simplification of the XML parser implementation. It is no trouble to make it deal with multiple <graphics> elements in the same way we allow for disk, nets, etc
If RDP is not enabled, then don't include the 2nd. If the local desktop display is not enabled, then don't include the 1st. This avoids the the 'headless' attribute being exposed in the XML directly. I chose type='desktop' as representing the 'native' desktop app display of the virt technology in question. I imagine it'll take similar attributes to the type=sdl, while the type=rdp would be similar to type=vnc.
I had included headless attribute cause only one virDomainGraphicsDef was there. I think that would not be necessary now if we support for more then one virDomainGraphicsDef's, also adding multiple virDomainGraphicsDef's will help me to implement some features for multiple screens :)
This reminds me of one thing I forgot to mention... We don't currently have any explicit representation of a video card device. The <graphics> tag is really representing the host I/O layer, covering video, mouse, keyboard (and potentially audio too). I think we need to add an explicit tag to represent video devices real soon. At very least we need to be able to indicate the type of video card - QEMU supports 4 already vga, cirrus, vmwarevga and xenfb. We probably also need to be able to indicate whether a video card supports multiple monitors / outputs, and the amont of Video RAM, etc. One random idea would be to add <video> <model type='cirrus' ram='500'/> </video>
<graphics type='desktop' display=':0.0'/>
yes, there is an API for it as well but currently I am using getenv("DISPLAY");implementing this was in my todo but didn't quite make it to top, but will try to make it in next set of patches.
Ah, that's nice.
feedback about attributes (auth='external' authtimeout='1234') would also be appreciated. Thanks.
I've not looked at this in huge detail yet. I'm wondering whether we need to expose it or not ? Is it something that's commonly used, or neccessary to configure per VM ? For QEMU and Xen, the VNC auth type is jsut configured per-host in the global Xen or libvirt QEMU config file for the host. So we don't bother to expose it in the XML One idea might we to make the auth stuff a child element of '<graphics>' so we don't start adding huge numbers of attributes to the main elemnt Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Hi Daniel,
We don't currently have any explicit representation of a video card device. The <graphics> tag is really representing the host I/O layer, covering video, mouse, keyboard (and potentially audio too).
I didn't get you here? i mean there is a seperate virDomainSoundDefPtr, virDomainInputDefPtr, etc?
I think we need to add an explicit tag to represent video devices real soon. At very least we need to be able to indicate the type of video card - QEMU supports 4 already vga, cirrus, vmwarevga and xenfb. We probably also need to be able to indicate whether a video card supports multiple monitors / outputs, and the amont of Video RAM, etc.
One random idea would be to add
<video> <model type='cirrus' ram='500'/> </video>
does it means the graphics tag is no more and is replaced with video tag? or video tag is added in addition to graphics tag? in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this: <video> <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/> </video>
I've not looked at this in huge detail yet. I'm wondering whether we need to expose it or not ? Is it something that's commonly used, or neccessary to configure per VM ? For QEMU and Xen, the VNC auth type is jsut configured per-host in the global Xen or libvirt QEMU config file for the host. So we don't bother to expose it in the XML
One idea might we to make the auth stuff a child element of '<graphics>' so we don't start adding huge numbers of attributes to the main elemnt
Yes it per VM feature and generally exposed by any RDP server, so not specific to VirtualBox, but a general case. i think the earlier mail give details of it. regarding the child element it is ok to have it as child element. Regards Pritesh
On Thu, Apr 23, 2009 at 02:41:25PM +0200, Pritesh Kothari wrote:
Hi Daniel,
We don't currently have any explicit representation of a video card device. The <graphics> tag is really representing the host I/O layer, covering video, mouse, keyboard (and potentially audio too).
I didn't get you here? i mean there is a seperate virDomainSoundDefPtr, virDomainInputDefPtr, etc?
I mean in terms of how this is exposed to an end user. VNC provides interaction for video, keyboard & mouse. SDL provides interaction for video, keyboard, mouse & audio RDP is similar. There are still the explict config sections for how video, mouse, sounds, etc are exposed to the guest OS.
I think we need to add an explicit tag to represent video devices real soon. At very least we need to be able to indicate the type of video card - QEMU supports 4 already vga, cirrus, vmwarevga and xenfb. We probably also need to be able to indicate whether a video card supports multiple monitors / outputs, and the amont of Video RAM, etc.
One random idea would be to add
<video> <model type='cirrus' ram='500'/> </video>
does it means the graphics tag is no more and is replaced with video tag? or video tag is added in addition to graphics tag?
We'd have both - the <video> tag explicitly for things related to the video adapter device. The <graphics> tag for the host side I/O layer config, be it VNC, RDP or SDL.
in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this:
<video> <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/> </video>
Sure, vram seems fine. I think i'd call multihead 'monitors' or 'heads'. Isn't 3D support implied by the type of graphics card emulated ? eg cirrus is a 2d only card, so it seems like 3Daccel is redundant. Similarly if the graphics model were a 3d card.
I've not looked at this in huge detail yet. I'm wondering whether we need to expose it or not ? Is it something that's commonly used, or neccessary to configure per VM ? For QEMU and Xen, the VNC auth type is jsut configured per-host in the global Xen or libvirt QEMU config file for the host. So we don't bother to expose it in the XML
One idea might we to make the auth stuff a child element of '<graphics>' so we don't start adding huge numbers of attributes to the main elemnt
Yes it per VM feature and generally exposed by any RDP server, so not specific to VirtualBox, but a general case. i think the earlier mail give details of it.
regarding the child element it is ok to have it as child element.
Regards Pritesh
-- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Apr 23, 2009 at 01:47:17PM +0100, Daniel P. Berrange wrote:
On Thu, Apr 23, 2009 at 02:41:25PM +0200, Pritesh Kothari wrote:
I think we need to add an explicit tag to represent video devices real soon. At very least we need to be able to indicate the type of video card - QEMU supports 4 already vga, cirrus, vmwarevga and xenfb. We probably also need to be able to indicate whether a video card supports multiple monitors / outputs, and the amont of Video RAM, etc.
agreed
in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this:
<video> <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/> </video>
Sure, vram seems fine. I think i'd call multihead 'monitors' or 'heads'.
unfortunately the number of heads might not be sufficient, e.g. with 4 heads you could have 4 in line or 2x2, the geometry and relative positioning will probably be needed in some way. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thu, Apr 23, 2009 at 02:56:46PM +0200, Daniel Veillard wrote:
On Thu, Apr 23, 2009 at 01:47:17PM +0100, Daniel P. Berrange wrote:
On Thu, Apr 23, 2009 at 02:41:25PM +0200, Pritesh Kothari wrote:
I think we need to add an explicit tag to represent video devices real soon. At very least we need to be able to indicate the type of video card - QEMU supports 4 already vga, cirrus, vmwarevga and xenfb. We probably also need to be able to indicate whether a video card supports multiple monitors / outputs, and the amont of Video RAM, etc.
agreed
in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this:
<video> <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/> </video>
Sure, vram seems fine. I think i'd call multihead 'monitors' or 'heads'.
unfortunately the number of heads might not be sufficient, e.g. with 4 heads you could have 4 in line or 2x2, the geometry and relative positioning will probably be needed in some way.
Surely that's something you do inside the guest OS. Inside the guest, if using Xorg, the user interacting will use xrandr to configure them in whatever layout they want. Similarly Windows has tools to decide the layout of head.. The layout will almost certainly change to match that of the desktop used by the end-user of the VM. eg we expose 2 heads to the guest OS. As user of the guest I connect using VNC and discover 2 heads. My real desktop machine has 2 monitors 1 above the other, so I run xrandr inside the guest to say the 2 heads should be above each other to match my real desktop. Even with real hardware, there's no way to inform the OS what the physical layout is, its all done by the user with the OS tools. So it doesn't seem like topology is necccessary in libvirt config to me Regards, Daniel. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Apr 23, 2009 at 02:13:18PM +0100, Daniel P. Berrange wrote:
On Thu, Apr 23, 2009 at 02:56:46PM +0200, Daniel Veillard wrote:
On Thu, Apr 23, 2009 at 01:47:17PM +0100, Daniel P. Berrange wrote:
On Thu, Apr 23, 2009 at 02:41:25PM +0200, Pritesh Kothari wrote:
I think we need to add an explicit tag to represent video devices real soon. At very least we need to be able to indicate the type of video card - QEMU supports 4 already vga, cirrus, vmwarevga and xenfb. We probably also need to be able to indicate whether a video card supports multiple monitors / outputs, and the amont of Video RAM, etc.
agreed
in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this:
<video> <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/> </video>
Sure, vram seems fine. I think i'd call multihead 'monitors' or 'heads'.
unfortunately the number of heads might not be sufficient, e.g. with 4 heads you could have 4 in line or 2x2, the geometry and relative positioning will probably be needed in some way.
Surely that's something you do inside the guest OS. Inside the guest, if using Xorg, the user interacting will use xrandr to configure them in whatever layout they want. Similarly Windows has tools to decide the layout of head..
The layout will almost certainly change to match that of the desktop used by the end-user of the VM.
eg we expose 2 heads to the guest OS. As user of the guest I connect using VNC and discover 2 heads. My real desktop machine has 2 monitors 1 above the other, so I run xrandr inside the guest to say the 2 heads should be above each other to match my real desktop.
Even with real hardware, there's no way to inform the OS what the physical layout is, its all done by the user with the OS tools. So it doesn't seem like topology is necccessary in libvirt config to me
Right, I got confused, that's not the proper level ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thursday 23 April 2009 14:47:17 Daniel P. Berrange wrote:
On Thu, Apr 23, 2009 at 02:41:25PM +0200, Pritesh Kothari wrote:
Hi Daniel,
We don't currently have any explicit representation of a video card device. The <graphics> tag is really representing the host I/O layer, covering video, mouse, keyboard (and potentially audio too).
I didn't get you here? i mean there is a seperate virDomainSoundDefPtr, virDomainInputDefPtr, etc?
I mean in terms of how this is exposed to an end user.
VNC provides interaction for video, keyboard & mouse.
SDL provides interaction for video, keyboard, mouse & audio
RDP is similar.
There are still the explict config sections for how video, mouse, sounds, etc are exposed to the guest OS.
I think we need to add an explicit tag to represent video devices real soon. At very least we need to be able to indicate the type of video card - QEMU supports 4 already vga, cirrus, vmwarevga and xenfb. We probably also need to be able to indicate whether a video card supports multiple monitors / outputs, and the amont of Video RAM, etc.
One random idea would be to add
<video> <model type='cirrus' ram='500'/> </video>
does it means the graphics tag is no more and is replaced with video tag? or video tag is added in addition to graphics tag?
We'd have both - the <video> tag explicitly for things related to the video adapter device. The <graphics> tag for the host side I/O layer config, be it VNC, RDP or SDL.
ok.
in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this:
<video> <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/> </video>
Sure, vram seems fine. I think i'd call multihead 'monitors' or 'heads'.
heads would do, but as DV said what about geometry and relative positioning?
Isn't 3D support implied by the type of graphics card emulated ? eg cirrus is a 2d only card, so it seems like 3Daccel is redundant. Similarly if the graphics model were a 3d card.
true. no need for that. Regards, Pritesh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Isn't 3D support implied by the type of graphics card emulated ? eg cirrus is a 2d only card, so it seems like 3Daccel is redundant. Similarly if the graphics model were a 3d card.
true. no need for that.
Actually I believe there is. I think what was originally meant was whether the domain would be able to do real accelerated 3D using the host hardware, from the guest. VBox provides an option to make 3D calls on the virtualized video card call the real 3D api of the host hardware, thus providing much faster 3D graphics in the guest. So quite different from just saying that the virtualized video card supports 3D. Just my 2 cents :) Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknwwvgACgkQgRp+dNkqn6/ebACfYLl7JWv7dkV9q1Zg6JQ0rxR9 0pcAn18bwSWwUeP8Qh6OsnkPaGNhOeDi =flSB -----END PGP SIGNATURE-----
true. no need for that.
Actually I believe there is. I think what was originally meant was whether the domain would be able to do real accelerated 3D using the host hardware, from the guest.
VBox provides an option to make 3D calls on the virtualized video card call the real 3D api of the host hardware, thus providing much faster 3D graphics in the guest.
So quite different from just saying that the virtualized video card supports 3D.
Just my 2 cents :)
You are right, but i was just hoping to extract that from name of graphics driver, but that doesn't make sense as the user may not want to turn on 3daccel support even if there is one available, so I think 3daccel or some other form for representing guest 3d support should be there, it may not be in video card tag if other hypervisors don't support them. any idea's here? Regards, Pritesh
On Thu, Apr 23, 2009 at 09:35:20PM +0200, Florian Vichot wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Isn't 3D support implied by the type of graphics card emulated ? eg cirrus is a 2d only card, so it seems like 3Daccel is redundant. Similarly if the graphics model were a 3d card.
true. no need for that.
Actually I believe there is. I think what was originally meant was whether the domain would be able to do real accelerated 3D using the host hardware, from the guest.
VBox provides an option to make 3D calls on the virtualized video card call the real 3D api of the host hardware, thus providing much faster 3D graphics in the guest.
Ah, that makes more sense. That sort of thing would be worth having an explicit attribute for. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 04/23/09 12:43, Daniel P. Berrange wrote:
Historically with Xen and QEMU there has only been ability to have either SDL graphics, or VNC graphics, but not both.
Note that this has changed recently, qemu can handle both vnc and sdl now.
<graphics type='desktop'/> <graphics type='rdp' port='1234' autoport='no' listen='172.21.4.3'/>
Likewise for qemu: <graphics type='sdl' ...> <graphics type='vnc' ...> cheers, Gerd
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
Florian Vichot -
Gerd Hoffmann -
Pritesh Kothari