That's much clearer :) On Thu, Jun 25, 2015 at 3:14 PM Dave Scott <dave.sc...@citrix.com> wrote:
> > > On 25 Jun 2015, at 02:46, Wang Xu <gna...@gmail.com> wrote: > > > > Agree, but I think the document is a bit confused > > > > > It is important that channel names are globally unique. > > > > https://github.com/mirage/xen/blob/master/docs/misc/channel.txt#L94 > > I agree— that wording is definitely confusing. Perhaps the docs should > compare the channel names to TCP/UDP port numbers? We could say that > > - the IANA port registry ~=~ the channel registry in the docs/ directory > - a single IP can only have one binding for a particular port at a time > ~=~ a domain can only have one binding for a particular name at a time > - lots of IPs can bind the same port ~=~ lots of domains can bind the same > name > > What do you think? > > Thanks, > Dave > > > > > On Thu, Jun 25, 2015 at 2:29 AM Dave Scott <dave.sc...@citrix.com> > wrote: > > Hi Xu, > > > > > On 24 Jun 2015, at 14:44, Wang Xu <gna...@gmail.com> wrote: > > > > > > Thank you Dave, I think I can also get work around for that. > > > > > > By the way, the document says the name should be global unique, but I > can start 2 domains have channels with a same name, is there some potential > problems? > > > > The name needs to be unique within a domain. It’s ok to have > > > > 1. domid 10, channel name ‘agent’ > > 2. domid 11, channel name ‘agent’ > > > > — this will be common, as multiple domains will have the same ‘agent’ > software installed. > > > > but it will cause problems if the name is used twice within a domain. > It’s a bad idea to have > > > > 1: domid 10, channel name ‘agent’ > > 2: domid 10, channel name ‘agent’ > > > > — although this will create 2 distinct /dev/hvc devices, it will be > difficult to tell which is which. > > > > If libxl allows the name to be duplicated within a domain, then this is > my fault. We should add validation code to check uniqueness. > > > > Thanks, > > Dave > > > > > > > > Cheers > > > > > > Xu > > > > > > On Wed, Jun 24, 2015 at 9:03 PM Dave Scott <dave.sc...@citrix.com> > wrote: > > > I don’t think the frontend driver in Linux knows about the name key. > In my testing I wrote a udev script which looks up the ‘name’ key directly > in xenstore and created a named device node using that. For reference my > script is here: > > > > > > > https://github.com/mirage/mirage-console/blob/master/udev/xenconsole-setup-tty > > > > > > Cheers, > > > Dave > > > > > > >> and I directly test `/dev/hvc1`, and it could communicate with the > outside socket. Is there some mistake in my channel > > > >> name configuration? > > > >> > > > >> | static void hyper_config_channel(libxl_device_channel* ch, const > char* name, const char* sock, int devid) { > > > >> | libxl_device_channel_init(ch); > > > >> | ch->backend_domid = 0; > > > >> | ch->name = strdup(name); > > > >> | ch->devid = devid; > > > >> | ch->connection = LIBXL_CHANNEL_CONNECTION_SOCKET; > > > >> | ch->u.socket.path = strdup(sock); > > > >> | } > > > >> > > > >> I tried to look at the oVirt code as it is mentioned in the dock, > but I did not find xen console in its guest agent code. > > > > > > > > So the issue is that the name you assign here to the channel, doesn't > > > > come up anywhere in the guest. Is that correct? > > > > > > > > > > > > > > > > > >> Thank you! > > > >> > > > >> > > > >> On Tue, Jun 23, 2015 at 7:30 PM, Stefano Stabellini < > stefano.stabell...@eu.citrix.com> wrote: > > > >> On Tue, 23 Jun 2015, Wang Xu wrote: > > > >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini < > stefano.stabell...@eu.citrix.com> wrote: > > > >>> Integrating hyper with Xen using libxl was the right > decision and it > > > >>> looks like you did a good job. I think that you can go > ahead with the > > > >>> PR! > > > >>> > > > >>> > > > >>> But I did have a few issues building hyper. I am getting: > > > >>> > > > >>> hyperd.go:11:2: cannot find package "hyper/daemon" in any > of: > > > >>> [...] > > > >>> > > > >>> I tried with a clean 0.2-dev branch > > > >>>> ./autogen.sh > > > >>>> ./configure > > > >>>> make > > > >>> > > > >>> It looks ok, are you work on the 0.2-dev branch, I did not write > the branch name in the instruction of > > > >> Readme, sorry for > > > >>> that. > > > >> > > > >> No worries, the most important part at this stage is the code, > and that > > > >> looks OK :-) > > > >> Yes, I was using 0.2-dev and followed those steps. As I > usually don't > > > >> program in go, it is likely that my go working environment is > missing > > > >> something, or my go paths are wrong. This is the full error > message: > > > >> > > > >> CGO_LDFLAGS="-Lhypervisor/xen -lxenlight -lxenctrl -lhyperxl" > godep go build hyperd.go > > > >> hyperd.go:11:2: cannot find package "hyper/daemon" in any of: > > > >> /local/scratch/sstabellini/go/src/hyper/daemon (from > $GOROOT) > > > >> > /local/scratch/sstabellini/hyper/Godeps/_workspace/src/hyper/daemon (from > $GOPATH) > > > >> hyperd.go:10:2: cannot find package "hyper/engine" in any of: > > > >> /local/scratch/sstabellini/go/src/hyper/engine (from > $GOROOT) > > > >> > /local/scratch/sstabellini/hyper/Godeps/_workspace/src/hyper/engine (from > $GOPATH) > > > >> hyperd.go:12:2: cannot find package "hyper/lib/glog" in any of: > > > >> /local/scratch/sstabellini/go/src/hyper/lib/glog (from > $GOROOT) > > > >> > /local/scratch/sstabellini/hyper/Godeps/_workspace/src/hyper/lib/glog (from > $GOPATH) > > > >> hyperd.go:13:2: cannot find package "hyper/utils" in any of: > > > >> /local/scratch/sstabellini/go/src/hyper/utils (from > $GOROOT) > > > >> > /local/scratch/sstabellini/hyper/Godeps/_workspace/src/hyper/utils (from > $GOPATH) > > > >> godep: go exit status 1 > > > >> > > > >> > > > >>> Looking through the code, it seems that you are adding a > > > >>> virtio-serial-pci device, why do you need it? It is not > used very much > > > >>> on Xen; the regular Xen uart is specified by setting > > > >>> b_info->u.hvm.serial to "pty", and it looks like you are > already doing > > > >>> that. If you need more than one console, you can have a > list setting > > > >>> b_info->u.hvm.serial_list. > > > >>> > > > >>> What the difference between u.hvm.serial_list and channels in > domain_config. The channel looks having more > > > >> features. > > > >> > > > >> Actually I think that you are right: channels are better > tested and more > > > >> flexible. > > > >> > > > >> > > > >>> virtio-9p-pci is also not used very much with Xen, but as > we don't have > > > >>> an alternative yet, I think it is good for now. > > > >>> > > > >>> > > > >>> Thanks again, > > > >>> > > > >>> Stefano > > > >>> > > > >>> > > > >>> > > > >>> On Fri, 19 Jun 2015, Sarah Conway wrote: > > > >>> > Hi Xu, > > > >>> > I'd be happy to work with you on some PR to promote this > work. I'll be in touch with some next steps > > > >> next > > > >>> week and look > > > >>> > forward to Stefano's feedback. > > > >>> > > > > >>> > Sarah > > > >>> > > > > >>> > On Fri, Jun 19, 2015 at 12:09 PM, Lars Kurth < > lars.ku...@citrix.com> wrote: > > > >>> > Xu, > > > >>> > Fantastic! If you wanted to do some PR, such as a joint > Xen Project / Linux Foundation and Hyper > > > >> press > > > >>> release or > > > >>> > other PR, we should start working on that after Stefano > had a look > > > >>> > Let me know > > > >>> > Regards > > > >>> > Lars > > > >>> > > > > >>> > From: Wang Xu <gna...@gmail.com> > > > >>> > Date: Friday, 19 June 2015 16:54 > > > >>> > To: "stefano.stabell...@citrix.com" < > stefano.stabell...@citrix.com> > > > >>> > Cc: "x...@hyper.sh" <x...@hyper.sh>, Sarah Conway < > scon...@linuxfoundation.org>, Lars Kurth > > > >>> <lars.ku...@citrix.com>, > > > >>> > "f...@hyper.sh" <f...@hyper.sh>, "carmark.d...@gmail.com" > <carmark.d...@gmail.com> > > > >>> > Subject: Re: Hyper and Xen Project > > > >>> > > > > >>> > Hi Stefano and Lars, Sarah, > > > >>> > I'd like to share some progress of Xen support of Hyper > with you. > > > >>> > > > > >>> > The source code of hyper with xen support has been pushed > to 0.2-dev branch ( > > > >>> > https://github.com/hyperhq/hyper/tree/0.2-dev ). Before > release the binary packages, there are still > > > >> some > > > >>> test and > > > >>> > tuning work to do, but I think it's better to share the > information with you firstly. > > > >>> > > > > >>> > Hyper supports HVM/Xen 4.5 as the first step, in which we > used C and Go to talk with Xen through > > > >> libxl. > > > >>> libxl is > > > >>> > well organized and help us much, though It took us some > time to understand/debug the signal > > > >> processing and > > > >>> nic > > > >>> > hotplug. > > > >>> > > > > >>> > You can check out the code and try to build it from > source as description listed in README if you > > > >> have > > > >>> interests. > > > >>> > And any suggestions on performance and reliability are > appreciated. > > > >>> > > > > >>> > Cheers! > > > >>> > Xu > > > >>> > > > > >>> > On Tue, Jun 9, 2015 at 5:41 PM Stefano Stabellini < > stefano.stabell...@eu.citrix.com> wrote: > > > >>> > You are right, we don't really have an equivalent > to 9p in the Xen > > > >>> > ecosystem at the moment. We had a prototype called > XenFS, like you > > > >>> > wrote, but it had never reached production quality, > so it was removed. > > > >>> > But we now have an OPW student working on a Xen > paravirtualized 9p fs > > > >>> > interface. Once she finishes the initial > prototype, we could prioritize > > > >>> > it within the community and work together to > complete it. > > > >>> > > > > >>> > How are you using virtio 9p fs? What Docker > storage backend are you > > > >>> > using? I am asking because when I looked into > running Docker container > > > >>> > images as Xen VMs, I was able to boot VMs without > any filesystem share, > > > >>> > by using the devices set up by Docker's device > mapper backend directly. > > > >>> > I think that using storage devices directly as > backends, when possible, > > > >>> > is preferable because of performance and security. > > > >>> > > > > >>> > > > > >>> > On Tue, 9 Jun 2015, Wang Xu wrote: > > > >>> > > Hi Stefano, > > > >>> > > > > > >>> > > Yes, we are working on HVM and using 9p and > virt-serial over virtio, and looks 9p do not > > > >> have a > > > >>> > similar > > > >>> > > component in Xen ecosystem. What's the status of > XenFS and how do you think about filesystem > > > >> share > > > >>> in > > > >>> > Xen? > > > >>> > > > > > >>> > > On Mon, Jun 8, 2015 at 6:18 PM Stefano Stabellini > <stefano.stabell...@eu.citrix.com> wrote: > > > >>> > > Hi Xu, > > > >>> > > > > > >>> > > Thank you for the very quick reply! I am > very happy to hear that Xen > > > >>> > > support is coming so soon. > > > >>> > > > > > >>> > > >From the technical point of view, I think > that HVM guests with the > > > >>> > > explicit kernel and initrd options is a > very good choice for the initial > > > >>> > > implementation. > > > >>> > > > > > >>> > > PVH will probably be a better alternative > going forward because startup > > > >>> > > times are far lower, but at this stage is > still not as stable as regular > > > >>> > > HVM guests, so I would wait for another Xen > release or two before using > > > >>> > > them. Old style PV guests might still be a > decent alternative for > > > >>> > > people that really care about startup > times, because they boot really > > > >>> > > quickly. They also have good performance in > a nested virtualization > > > >>> > > environment, such as people deploying > containers on Amazon AWS. However > > > >>> > > on native they offer lower performance than > PVH or HVM guests. > > > >>> > > > > > >>> > > You mentioned virtio: are you using virtio > 9p fs or one of the other > > > >>> > > protocols (block, net, etc)? > > > >>> > > > > > >>> > > Cheers, > > > >>> > > > > > >>> > > Stefano > > > >>> > > > > > >>> > > > > > >>> > > On Fri, 5 Jun 2015, Wang Xu wrote: > > > >>> > > > Hello Stefano, > > > >>> > > > > > > >>> > > > It is very glad to get message from Xen. > > > >>> > > > > > > >>> > > > Xen is a great innovation and one of the > most widely adopted hypervisor, we believe > > > >> we > > > >>> should > > > >>> > > support it as > > > >>> > > > soon as possible. > > > >>> > > > > > > >>> > > > We are currently busy working on Xen > support and will announce the initial support > > > >> in the > > > >>> next > > > >>> > > week. > > > >>> > > > > > > >>> > > > The initial support is working on Xen 4.5 > hvm mode, because it is easy to specify > > > >> kernel and > > > >>> > > initrd during > > > >>> > > > boot and support virtio, which we have > already used in the kvm version. > > > >>> > > > > > > >>> > > > We also considered PVH on Xen 4.4, but > met some trouble with that. > > > >>> > > > > > > >>> > > > We are very interesting in cooperating > with Xen upstream to have a better support in > > > >> the > > > >>> > > future. > > > >>> > > > > > > >>> > > > Thank you for your message! > > > >>> > > > > > > >>> > > > Cheers! > > > >>> > > > > > > >>> > > > Xu Wang > > > >>> > > > Cofounder & CTO of Hyper > > > >>> > > > > > > >>> > > > > > > >>> > > > Stefano Stabellini < > stefano.stabell...@eu.citrix.com>于2015年6月6日周六 00:14写道： > > > >>> > > > Hello Xu, Feng, Lei, > > > >>> > > > > > > >>> > > > My name is Stefano Stabellini and I > lead the Xen Project team within > > > >>> > > > Citrix. I am also one of the Xen > maintainers. > > > >>> > > > > > > >>> > > > Let me introduce you to Lars Kurth, > chair of the Xen Project advisory > > > >>> > > > board, and Sarah Conway, that > represents the Linux Foundation. As you > > > >>> > > > probably know, Xen Project is a > Linux Foundation collaborative project. > > > >>> > > > > > > >>> > > > > > > >>> > > > I wanted to get in touch with you > regarding your new project, Hyper: I > > > >>> > > > am really glad to see that you are > stepping up to bring the security and > > > >>> > > > flexibility of hypervisor solutions > to the world of containers. I think is > > > >>> > > > a key project that will benefit the > containers and cloud industry as a > > > >>> > > > whole. In fact I have been > investigating the best way to run containers > > > >>> > > > on Xen myself during the last few > months. > > > >>> > > > > > > >>> > > > > > > >>> > > > I read that Hyper is hypervisor > agnostic and I am glad that Xen is > > > >>> > > > already on the roadmap. > > > >>> > > > > > > >>> > > > I understand that Hyper is still > young, but do you have any timelines on > > > >>> > > > when you are planning to introduce > Xen support to Hyper? Would you be > > > >>> > > > interested in discussing the best > way to do that? > > > >>> > > > > > > >>> > > > > > > >>> > > > Cheers, > > > >>> > > > > > > >>> > > > Stefano > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > -- > > > >>> > Sarah Conway > > > >>> > PR Manager > > > >>> > The Linux Foundation > > > >>> > scon...@linuxfoundation.org > > > >>> > (978) 578-5300 Cell > > > >>> > Skype: sarah.k.conway > > > >>> > > > > >>> > > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> Wang Xu > > > >> > > > > > > >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
