[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.