[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Hyper and Xen Project



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

On Thu, Jun 25, 2015 at 2:29 AM Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:
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®.