* Re: Hyper and Xen Project
[not found] ` <CAC2n1MQ=KZ1zztg9-UWy3UhyK_S-_Cw844bFW=Kc33KdwMrEOQ@mail.gmail.com>
@ 2015-06-24 11:48 ` Stefano Stabellini
2015-06-24 13:03 ` Dave Scott
0 siblings, 1 reply; 8+ messages in thread
From: Stefano Stabellini @ 2015-06-24 11:48 UTC (permalink / raw)
To: Wang Xu
Cc: xen-devel, Wei Liu, Dave Scott, Stefano Stabellini, Ian Jackson,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 17577 bytes --]
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"
>
> 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@eu.citrix.com> wrote:
> On Tue, 23 Jun 2015, Wang Xu wrote:
> > On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
> > > Date: Friday, 19 June 2015 16:54
> > > To: "stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>
> > > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <sconway@linuxfoundation.org>, Lars Kurth
> > <lars.kurth@citrix.com>,
> > > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com" <carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
> > > sconway@linuxfoundation.org
> > > (978) 578-5300 Cell
> > > Skype: sarah.k.conway
> > >
> > >
> >
> >
> >
>
>
>
>
> --
> Wang Xu
>
>
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hyper and Xen Project
2015-06-24 11:48 ` Hyper and Xen Project Stefano Stabellini
@ 2015-06-24 13:03 ` Dave Scott
2015-06-24 13:09 ` Stefano Stabellini
2015-06-24 13:44 ` Wang Xu
0 siblings, 2 replies; 8+ messages in thread
From: Dave Scott @ 2015-06-24 13:03 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Dave Scott, xen-devel, Wei Liu, Ian Campbell, Wang Xu, Ian Jackson
> On 24 Jun 2015, at 12:48, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> 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
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@eu.citrix.com> wrote:
>> On Tue, 23 Jun 2015, Wang Xu wrote:
>>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
>>> > Date: Friday, 19 June 2015 16:54
>>> > To: "stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>
>>> > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <sconway@linuxfoundation.org>, Lars Kurth
>>> <lars.kurth@citrix.com>,
>>> > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com" <carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
>>> > sconway@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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hyper and Xen Project
2015-06-24 13:03 ` Dave Scott
@ 2015-06-24 13:09 ` Stefano Stabellini
2015-06-24 13:44 ` Wang Xu
1 sibling, 0 replies; 8+ messages in thread
From: Stefano Stabellini @ 2015-06-24 13:09 UTC (permalink / raw)
To: Dave Scott
Cc: xen-devel, Wei Liu, Ian Campbell, Wang Xu, Stefano Stabellini,
Ian Jackson
[-- Attachment #1: Type: text/plain, Size: 16073 bytes --]
On Wed, 24 Jun 2015, Dave Scott wrote:
> > On 24 Jun 2015, at 12:48, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> 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@eu.citrix.com> wrote:
> >> On Tue, 23 Jun 2015, Wang Xu wrote:
> >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
> >>> > Date: Friday, 19 June 2015 16:54
> >>> > To: "stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>
> >>> > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <sconway@linuxfoundation.org>, Lars Kurth
> >>> <lars.kurth@citrix.com>,
> >>> > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com" <carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
> >>> > sconway@linuxfoundation.org
> >>> > (978) 578-5300 Cell
> >>> > Skype: sarah.k.conway
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> Wang Xu
> >>
>
>
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hyper and Xen Project
2015-06-24 13:03 ` Dave Scott
2015-06-24 13:09 ` Stefano Stabellini
@ 2015-06-24 13:44 ` Wang Xu
2015-06-24 18:29 ` Dave Scott
1 sibling, 1 reply; 8+ messages in thread
From: Wang Xu @ 2015-06-24 13:44 UTC (permalink / raw)
To: Dave Scott, Stefano Stabellini
Cc: Ian Jackson, xen-devel, Wei Liu, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 15590 bytes --]
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?
Cheers
Xu
On Wed, Jun 24, 2015 at 9:03 PM Dave Scott <Dave.Scott@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.stabellini@eu.citrix.com> wrote:
> >> On Tue, 23 Jun 2015, Wang Xu wrote:
> >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <
> stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
> >>> > Date: Friday, 19 June 2015 16:54
> >>> > To: "stefano.stabellini@citrix.com" <
> stefano.stabellini@citrix.com>
> >>> > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <
> sconway@linuxfoundation.org>, Lars Kurth
> >>> <lars.kurth@citrix.com>,
> >>> > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com" <
> carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
> >>> > sconway@linuxfoundation.org
> >>> > (978) 578-5300 Cell
> >>> > Skype: sarah.k.conway
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> Wang Xu
> >>
>
>
[-- Attachment #1.2: Type: text/html, Size: 22779 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hyper and Xen Project
2015-06-24 13:44 ` Wang Xu
@ 2015-06-24 18:29 ` Dave Scott
2015-06-25 1:46 ` Wang Xu
0 siblings, 1 reply; 8+ messages in thread
From: Dave Scott @ 2015-06-24 18:29 UTC (permalink / raw)
To: Wang Xu; +Cc: Wei Liu, xen-devel, Stefano Stabellini, Ian Campbell, Ian Jackson
Hi Xu,
> On 24 Jun 2015, at 14:44, Wang Xu <gnawux@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.Scott@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.stabellini@eu.citrix.com> wrote:
> >> On Tue, 23 Jun 2015, Wang Xu wrote:
> >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
> >>> > Date: Friday, 19 June 2015 16:54
> >>> > To: "stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>
> >>> > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <sconway@linuxfoundation.org>, Lars Kurth
> >>> <lars.kurth@citrix.com>,
> >>> > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com" <carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
> >>> > sconway@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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hyper and Xen Project
2015-06-24 18:29 ` Dave Scott
@ 2015-06-25 1:46 ` Wang Xu
2015-06-25 7:14 ` Dave Scott
0 siblings, 1 reply; 8+ messages in thread
From: Wang Xu @ 2015-06-25 1:46 UTC (permalink / raw)
To: Dave Scott
Cc: Wei Liu, xen-devel, Stefano Stabellini, Ian Campbell, Ian Jackson
[-- Attachment #1.1: Type: text/plain, Size: 17302 bytes --]
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@citrix.com> wrote:
> Hi Xu,
>
> > On 24 Jun 2015, at 14:44, Wang Xu <gnawux@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.Scott@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.stabellini@eu.citrix.com> wrote:
> > >> On Tue, 23 Jun 2015, Wang Xu wrote:
> > >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <
> stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
> > >>> > Date: Friday, 19 June 2015 16:54
> > >>> > To: "stefano.stabellini@citrix.com" <
> stefano.stabellini@citrix.com>
> > >>> > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <
> sconway@linuxfoundation.org>, Lars Kurth
> > >>> <lars.kurth@citrix.com>,
> > >>> > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com" <
> carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
> > >>> > sconway@linuxfoundation.org
> > >>> > (978) 578-5300 Cell
> > >>> > Skype: sarah.k.conway
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Wang Xu
> > >>
> >
>
>
[-- Attachment #1.2: Type: text/html, Size: 25996 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hyper and Xen Project
2015-06-25 1:46 ` Wang Xu
@ 2015-06-25 7:14 ` Dave Scott
2015-06-25 10:20 ` Wang Xu
0 siblings, 1 reply; 8+ messages in thread
From: Dave Scott @ 2015-06-25 7:14 UTC (permalink / raw)
To: Wang Xu; +Cc: Wei Liu, xen-devel, Stefano Stabellini, Ian Campbell, Ian Jackson
> On 25 Jun 2015, at 02:46, Wang Xu <gnawux@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.Scott@citrix.com> wrote:
> Hi Xu,
>
> > On 24 Jun 2015, at 14:44, Wang Xu <gnawux@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.Scott@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.stabellini@eu.citrix.com> wrote:
> > >> On Tue, 23 Jun 2015, Wang Xu wrote:
> > >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
> > >>> > Date: Friday, 19 June 2015 16:54
> > >>> > To: "stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>
> > >>> > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <sconway@linuxfoundation.org>, Lars Kurth
> > >>> <lars.kurth@citrix.com>,
> > >>> > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com" <carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
> > >>> > sconway@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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hyper and Xen Project
2015-06-25 7:14 ` Dave Scott
@ 2015-06-25 10:20 ` Wang Xu
0 siblings, 0 replies; 8+ messages in thread
From: Wang Xu @ 2015-06-25 10:20 UTC (permalink / raw)
To: Dave Scott
Cc: Wei Liu, xen-devel, Stefano Stabellini, Ian Campbell, Ian Jackson
[-- Attachment #1.1: Type: text/plain, Size: 18689 bytes --]
That's much clearer :)
On Thu, Jun 25, 2015 at 3:14 PM Dave Scott <Dave.Scott@citrix.com> wrote:
>
> > On 25 Jun 2015, at 02:46, Wang Xu <gnawux@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.Scott@citrix.com>
> wrote:
> > Hi Xu,
> >
> > > On 24 Jun 2015, at 14:44, Wang Xu <gnawux@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.Scott@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.stabellini@eu.citrix.com> wrote:
> > > >> On Tue, 23 Jun 2015, Wang Xu wrote:
> > > >>> On Sat, Jun 20, 2015 at 1:10 AM Stefano Stabellini <
> stefano.stabellini@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.kurth@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 <gnawux@gmail.com>
> > > >>> > Date: Friday, 19 June 2015 16:54
> > > >>> > To: "stefano.stabellini@citrix.com" <
> stefano.stabellini@citrix.com>
> > > >>> > Cc: "xu@hyper.sh" <xu@hyper.sh>, Sarah Conway <
> sconway@linuxfoundation.org>, Lars Kurth
> > > >>> <lars.kurth@citrix.com>,
> > > >>> > "feng@hyper.sh" <feng@hyper.sh>, "carmark.dlut@gmail.com"
> <carmark.dlut@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.stabellini@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.stabellini@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.stabellini@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
> > > >>> > sconway@linuxfoundation.org
> > > >>> > (978) 578-5300 Cell
> > > >>> > Skype: sarah.k.conway
> > > >>> >
> > > >>> >
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Wang Xu
> > > >>
> > >
> >
>
>
[-- Attachment #1.2: Type: text/html, Size: 28211 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-06-25 10:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <alpine.DEB.2.02.1506051552030.19838@kaball.uk.xensource.com>
[not found] ` <CAC2n1MSrRhEzdNN8Gue8D9iY1r532BObR_ro1U+EmaAmJiKyNA@mail.gmail.com>
[not found] ` <alpine.DEB.2.02.1506081101370.19838@kaball.uk.xensource.com>
[not found] ` <CAC2n1MTcTKkachVUGcab17-=rVD3dVdoD--vz5MiS6Bj+x+VCg@mail.gmail.com>
[not found] ` <alpine.DEB.2.02.1506091018520.19838@kaball.uk.xensource.com>
[not found] ` <CAC2n1MRM_XFQbOpKPdHpw9HOk--zho8=13o98XrOV3sN3iPy6w@mail.gmail.com>
[not found] ` <D1A9FCFC.1D36C%lars.kurth@citrix.com>
[not found] ` <CAFm1QiAL==0JHt_8SAXEmEmNqDbC74Uc3eGWN5zcLtLtJ_8VFw@mail.gmail.com>
[not found] ` <alpine.DEB.2.02.1506191736340.21829@kaball.uk.xensource.com>
[not found] ` <CAC2n1MT9V7iS6YJSy4ixh7YrHRHY04Yz4w6tbug5+T2s2pexoA@mail.gmail.com>
[not found] ` <alpine.DEB.2.02.1506231202480.4824@kaball.uk.xensource.com>
[not found] ` <CAC2n1MQ=KZ1zztg9-UWy3UhyK_S-_Cw844bFW=Kc33KdwMrEOQ@mail.gmail.com>
2015-06-24 11:48 ` Hyper and Xen Project Stefano Stabellini
2015-06-24 13:03 ` Dave Scott
2015-06-24 13:09 ` Stefano Stabellini
2015-06-24 13:44 ` Wang Xu
2015-06-24 18:29 ` Dave Scott
2015-06-25 1:46 ` Wang Xu
2015-06-25 7:14 ` Dave Scott
2015-06-25 10:20 ` Wang Xu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.