On Thu, Apr 16, 2009 at 11:21:23AM +0200, Pritesh Kothari wrote: 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 :|

On Thu, Apr 23, 2009 at 01:32:24PM +0200, Pritesh Kothari wrote: yes this is a limitation of the impelentation, not of the model, it makes more sense to allow multiple graphis entries. 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. also it's more generic and may be useful as other protocol evolves 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") 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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

On Thu, Apr 23, 2009 at 01:32:24PM +0200, Pritesh Kothari wrote: 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 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> Ah, that's nice. 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 :|

On Thu, Apr 23, 2009 at 02:41:25PM +0200, Pritesh Kothari wrote: 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. 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. 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. -- |: 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:56:46PM +0200, Daniel Veillard wrote: 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 Thursday 23 April 2009 14:47:17 Daniel P. Berrange wrote: ok. heads would do, but as DV said what about geometry and relative positioning? true. no need for that. Regards, Pritesh

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 04/23/09 12:43, Daniel P. Berrange wrote: Note that this has changed recently, qemu can handle both vnc and sdl now. Likewise for qemu: <graphics type='sdl' ...> <graphics type='vnc' ...> cheers, Gerd