|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Hyper and Xen Project
Hi Xu, > On 24 Jun 2015, at 14:44, Wang Xu <gnawux@xxxxxxxxx> 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.Scott@xxxxxxxxxx> 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.stabellini@xxxxxxxxxxxxx> wrote: > >> On Tue, 23 Jun 2015, Wang Xu wrote: > >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini > >>> <stefano.stabellini@xxxxxxxxxxxxx> 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.kurth@xxxxxxxxxx> 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 <gnawux@xxxxxxxxx> > >>> > Date: Friday, 19 June 2015 16:54 > >>> > To: "stefano.stabellini@xxxxxxxxxx" > >>> <stefano.stabellini@xxxxxxxxxx> > >>> > Cc: "xu@xxxxxxxx" <xu@xxxxxxxx>, Sarah Conway > >>> <sconway@xxxxxxxxxxxxxxxxxxx>, Lars Kurth > >>> <lars.kurth@xxxxxxxxxx>, > >>> > "feng@xxxxxxxx" <feng@xxxxxxxx>, "carmark.dlut@xxxxxxxxx" > >>> <carmark.dlut@xxxxxxxxx> > >>> > 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.stabellini@xxxxxxxxxxxxx> 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.stabellini@xxxxxxxxxxxxx> 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.stabellini@xxxxxxxxxxxxx>ä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 > >>> > sconway@xxxxxxxxxxxxxxxxxxx > >>> > (978) 578-5300 Cell > >>> > Skype: sarah.k.conway > >>> > > >>> > > >>> > >>> > >>> > >> > >> > >> > >> > >> -- > >> Wang Xu > >> > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |