Is there a convenient way to setup the IP address for the _stubdom_ (to connect to the vnc server running there) from within the corresponding HVM config file on Xen 4.1? Or should one use dhcpd? Thanks, joanna. ps. Sorry for posting this to xen-devel, instead of xen-users -- next time I will subscribe to the latter, I promise ;) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 02/07/12 20:28, Joanna Rutkowska wrote:> Is there a convenient way to setup the IP address for the _stubdom_ > (to connect to the vnc server running there) from within the > corresponding HVM config file on Xen 4.1? Or should one use dhcpd? >...in which case, wouldn''t there be a race between the time lwip obtains the dhcp packet, and the time when qemu is trying to do bind() for its vncserver? joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote:> Is there a convenient way to setup the IP address for the _stubdom_ (to > connect to the vnc server running there) from within the corresponding > HVM config file on Xen 4.1? Or should one use dhcpd?Currently the model with stubdomains is that the stub domain runs a PVFB device against a backend in dom0 (actually, another qemu) which does the vnc export etc so there is no networking to the stub dom. I can see valid reasons why you would want to have the stubdom itself do the vnc export and therefore have a network of its own but I don''t think the toolstack can express that right now. I think it was done in the early days of stubdoms, but I suspect in some hacky way (or perhaps just DHCP), and I don''t know if that functionality has persisted to the present day. Patches would be welcome. Ian.> > Thanks, > joanna. > > ps. Sorry for posting this to xen-devel, instead of xen-users -- next > time I will subscribe to the latter, I promise ;) >
On Wed, 8 Feb 2012, Ian Campbell wrote:> On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote: > > Is there a convenient way to setup the IP address for the _stubdom_ (to > > connect to the vnc server running there) from within the corresponding > > HVM config file on Xen 4.1? Or should one use dhcpd? > > Currently the model with stubdomains is that the stub domain runs a PVFB > device against a backend in dom0 (actually, another qemu) which does the > vnc export etc so there is no networking to the stub dom. > > I can see valid reasons why you would want to have the stubdom itself do > the vnc export and therefore have a network of its own but I don''t think > the toolstack can express that right now. I think it was done in the > early days of stubdoms, but I suspect in some hacky way (or perhaps just > DHCP), and I don''t know if that functionality has persisted to the > present day.I recall having removed that option a long time ago to simplify stubdom configs.
On 02/08/12 17:35, Ian Campbell wrote:> On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote: >> Is there a convenient way to setup the IP address for the _stubdom_ (to >> connect to the vnc server running there) from within the corresponding >> HVM config file on Xen 4.1? Or should one use dhcpd? > > Currently the model with stubdomains is that the stub domain runs a PVFB > device against a backend in dom0 (actually, another qemu) which does the > vnc export etc so there is no networking to the stub dom. > > I can see valid reasons why you would want to have the stubdom itself do > the vnc export and therefore have a network of its own but I don''t think > the toolstack can express that right now. I think it was done in the > early days of stubdoms, but I suspect in some hacky way (or perhaps just > DHCP), and I don''t know if that functionality has persisted to the > present day. >Actually I just wanted to access VNC in the stubdom for some testing -- in the long term I don''t think this is a desirable option, because: 1) using VNC adds lots of overhead -- e.g. it''s unable to do zero-copy framebuffer virtualization in contrast to e.g. our Qubes GUI daemon, and 2) in order to keep it on a reasonably secure level, one would need to have one more domain (a "vncviewer" domain) which would be connected to the stubdom''s vncserver (note that in Qubes we don''t have networking in Dom0 -- and we don''t want to have it). The pvfb solution will work just fine for me testing purposes for now (but only for testing, as any solution that requires me to run qemu in Dom0 is not satisfactory from the security point of view IMHO). So, many thanks for pointing this out -- I was so convinced that a stubdom runs its own vncserver, that I missed all those qemu processes in my Dom0 ;) Thanks! joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel