|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Hyper and Xen Project
On Wed, 24 Jun 2015, Dave Scott wrote:
> > On 24 Jun 2015, at 12:48, Stefano Stabellini
> > <Stefano.Stabellini@xxxxxxxxxxxxx> wrote:
> >
> > Hi Wang,
> >
> > I don't know the answer, so I CCed xen-devel (the Xen development list)
> > and a few people that I think will be able to help.
> >
> > Cheers,
> >
> > Stefano
> >
> > On Wed, 24 Jun 2015, Wang Xu wrote:
> >> A problem about channel, where do I found the channel name in the guest,
> >> In the document, it says I could found it in
> >> sysfs, but looks there isn't a name property:
> >>
> >> | root@test-container-create-ubuntu:/sys/bus/xen/devices# udevadm info
> >> --attribute-walk --path=/devices/console-1
> >> |
> >> [...]
> >> |
> >> | looking at device '/devices/console-1':
> >> | KERNEL=="console-1"
> >> | SUBSYSTEM=="xen"
> >> | DRIVER=="xenconsole"
> >> | ATTR{devtype}=="console"
> >> | ATTR{nodename}=="device/console/1â
> >>
>
> 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
That's a great workaround. However I think it would be best to make the
Linux hvc_xen driver aware of the name key going forward.
> >> 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 |