Xen devel - Feb 2005 - [PATCH] VM-Tool: C-based Xen management tools

We''ve implemented a set of basic management tools for Xen.  The tools 
are written in C and are currently capable of creating and shutting down 
domains, connecting to a domain''s console, enumerating domains, and 
attaching VBDs and VIFs to a domain.

The tools are still very rough.  This version is pretty much a 
proof-of-concept.  It should not be used in a production environment.  
In fact, you shouldn''t use them with any domains that are important to 
you.  While I''ve never seen any data corruption caused by the tools 
there''s just not been enough testing yet.

These tools are a product of about a weeks work.  There are some missing 
features including save/restore, migration, and usb/pci virtualation.  
The reason is that we wanted to get the communities feedback before we 
went too far.

The tools are not meant to replace Xend but rather provide an 
alternative toolchain for those that need a reduced management foot print.

The plan is to continue cleaning up the code and submit again to the 
list as a patch to xen-unstable.  We''ve talked to Mike Wray and we are 
both eager to make sure that these tools and Xend cooperate as much as 
possible in the long term.

You can get a copy of the tools at the following URL.  xen-unstable is 
required to use them (they rely on xcs).  Feedback is greatly 
appreciated :-)  Nothing is really set in stone.

http://www.cs.utexas.edu/users/aliguori/vm-tools-0.0.1.tar.gz

Thanks,
Anthony Liguori


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Anthony Liguori wrote:
> We''ve implemented a set of basic management tools for Xen.  The
tools
> are written in C and are currently capable of creating and shutting down 
> domains, connecting to a domain''s console, enumerating domains,
and
> attaching VBDs and VIFs to a domain.
Hey, Anthony,  thanks for getting this out!. I''ve started to take
a look at it - won''t be able to test it for a bit since I''m
running
on -testing for a while - I''ll have feedback next week.
> The tools are still very rough.  This version is pretty much a 
> proof-of-concept.  It should not be used in a production environment.  
> In fact, you shouldn''t use them with any domains that are
important to
> you.  While I''ve never seen any data corruption caused by the
tools
> there''s just not been enough testing yet.
Can you tell us on what you tested, and which configurations, so far?
> These tools are a product of about a weeks work.  There are some missing 
> features including save/restore, migration, and usb/pci virtualation.  
> The reason is that we wanted to get the communities feedback before we 
> went too far.
Are you going to be doing the USB and PCI stuff as well?
Will you need any help on that?
> You can get a copy of the tools at the following URL.  xen-unstable is 
> required to use them (they rely on xcs).  Feedback is greatly 
> appreciated :-)  Nothing is really set in stone.
So there will be no effort to backport, correct?

thanks,
Nivedita



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Nivedita Singhvi wrote:
> The tools are still very rough.  This version is pretty much a 
> proof-of-concept.  It should not be used in a production environment.  
> In fact, you shouldn''t use them with any domains that are
important to
> you.  While I''ve never seen any data corruption caused by the
tools
> there''s just not been enough testing yet.
>
> Can you tell us on what you tested, and which configurations, so far?
Sure, I''ve tested on Fedora Core 3 and on Gentoo both running various 
copies of xen-unstable (ranging from a few weeks ago to a day ago).  
There are a number of others (Mike, Woody, Dan) that have tested on 
other platforms.

By tested, I mean was able to create and destroy domains with various 
arrangements of block devices and network devices (0, 1, 2, etc, etc.).  
I''ve tested using a custom busybox based ramdisk and ttylinux as DomU.
Other DomU configuration should also work (although haven''t been
tested).
> Are you going to be doing the USB and PCI stuff as well?
> Will you need any help on that?
Yes, the goal was to minimize the amount of features to the least amount 
required before release.  We''re very interested in hearing feedback on 
what the tools should look like.

USB and PCI support isn''t that hard.  Doing in a way that people feel
is
intuitive is another matter.  Feed-back on what sort of interfaces these 
tools should have is extremely useful.
> So there will be no effort to backport, correct?
That depends on demand.  The tools could be modified to open the 
controls channels directly instead of going through xcs, but I''d rather
encourage an xcs based world where Xend and vm-tools can live together.  
Of course, if someone was willing to backport the old Xend to xcs... :-)

Thanks,
Anthony Liguori


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Nice work!
> > Are you going to be doing the USB and PCI stuff as well?
> > Will you need any help on that?
>
> Yes, the goal was to minimize the amount of features to the least amount
> required before release.  We''re very interested in hearing
feedback on
> what the tools should look like.
> USB and PCI support isn''t that hard.  Doing in a way that people
feel is
> intuitive is another matter.  Feed-back on what sort of interfaces these
> tools should have is extremely useful.
PCI should be fairly trivial at the moment since it just requires a hypercall.  
USB is very similar to Vifs and Vbds from the control protocol PoV.

As far as making the interface intuitive...  I think it''s reasonably
sane to
specify this stuff the way the current tools do, although arguably it would 
be useful to have some sort of abstraction so that users don''t have to
think
about PCI config space / USB port IDs.

Cheers,
Mark
> > So there will be no effort to backport, correct?
>
> That depends on demand.  The tools could be modified to open the
> controls channels directly instead of going through xcs, but I''d
rather
> encourage an xcs based world where Xend and vm-tools can live together.
> Of course, if someone was willing to backport the old Xend to xcs... :-)
>
> Thanks,
> Anthony Liguori
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Mark Williamson wrote:
>Nice work!
>  
>
Thanks :-)
>As far as making the interface intuitive...  I think it''s
reasonably sane to
>specify this stuff the way the current tools do, although arguably it would 
>be useful to have some sort of abstraction so that users don''t have
to think
>about PCI config space / USB port IDs.
>  
>
Yes, PCI wouldn''t be too hard to abstract.  Abstracting USB worries me
a
bit though.  On the one hand, you want to abstract at the device level.  
However, not all USB devices make it easy to be uniquely identified (too 
much optional information).  This is a problem the devfs/udev guys have 
faced.

It''s even hairer with virtualization though.  Say you had two
harddrives
that were USB and not uniquely identifiable.  You want to assign each 
harddrive to a separate VM.  If you unplug them and swap ports, and 
you''re using the old configurations, you really want that each VM to
see
the harddrive they previously saw.  Swapping them could lead to 
confusion and even worse, security problems.

Not sure the best solution here.  One of the reasons I''ve held off on
USB.

Regards,
>Cheers,
>Mark
>
>  
>
>>>So there will be no effort to backport, correct?
>>>      
>>>
>>That depends on demand.  The tools could be modified to open the
>>controls channels directly instead of going through xcs, but
I''d rather
>>encourage an xcs based world where Xend and vm-tools can live together.
>>Of course, if someone was willing to backport the old Xend to xcs... :-)
>>
>>Thanks,
>>Anthony Liguori
>>    
>>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Yes, PCI wouldn''t be too hard to abstract.  Abstracting USB
worries me a
> bit though.  On the one hand, you want to abstract at the device level.
That would be a neat feature.  It''d require changes to the backend
device
driver to be a bit smarter about grabbing devices, as well as frontend 
changes to communicate device identities the backend...
> It''s even hairer with virtualization though.  Say you had two
harddrives
> that were USB and not uniquely identifiable.  You want to assign each
> harddrive to a separate VM.  If you unplug them and swap ports, and
> you''re using the old configurations, you really want that each VM
to see
> the harddrive they previously saw.  Swapping them could lead to
> confusion and even worse, security problems.
The current implementation sidesteps all these by specifying port IDs.  e.g. 
port 1 on my root hub always belongs to VM1 (when running), port 2 on hub 3 
always belongs to VM2 (when running), etc.
> Not sure the best solution here.  One of the reasons I''ve held off
on USB.
For comparison, do you know what abstraction other systems do?  Do they assign 
ports or associate devices with VMs?

The latter is definitely an attractive option...  If we added support for both 
ways of doing things, paranoid people (or people with weird devices!) could 
use the port specifiers, whilst others used device IDs.

What do you think?

Cheers,
Mark


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Mark Williamson wrote:
>The current implementation sidesteps all these by specifying port IDs.  e.g.
>port 1 on my root hub always belongs to VM1 (when running), port 2 on hub 3 
>always belongs to VM2 (when running), etc.
>  
>
Yeah, I think we''ll always have to support this as a fallback option.
>>Not sure the best solution here.  One of the reasons I''ve held
off on USB.
>>    
>>
>
>For comparison, do you know what abstraction other systems do?  Do they
assign
>ports or associate devices with VMs?
>  
>
Not sure.  The only thing I know that does USB virtualization is VMware 
and I''ve not played with that feature (I think it''s a
relatively new
feature).

udev/namedev have to deal with this to ensure that devices have a unique 
(and consistent) /dev entry.  It currently uses a tiered approach to 
determine exactly what the device is.  It''s not perfect but it works 
reasonably well.  The best link I could find explaining it with a quick 
google is:

http://www.gentoo.org/doc/en/udev-guide.xml

A GUI would be really handy for PCI/USB because it would provide an easy 
way to pick devices by name (instead of specifying an series of 
identifiers/bus/etc in the config).
>The latter is definitely an attractive option...  If we added support for
both
>ways of doing things, paranoid people (or people with weird devices!) could 
>use the port specifiers, whilst others used device IDs.
>  
>
I agree completely.  I''m currently adding proper documentation to 
vm-tools but after that''s done I''ll add USB virtualization and
try to
implement a mechanism to select by device ID and push out another 
version to the list.

Regards,

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> >For comparison, do you know what abstraction other systems do?  Do they
> > assign ports or associate devices with VMs?
>
> Not sure.  The only thing I know that does USB virtualization is VMware
> and I''ve not played with that feature (I think it''s a
relatively new
> feature).
I think they''ve been able to do some kind of USB passthrough for a
while (not
sure how long) but the support for isochronous is only available in their 
current beta.
> udev/namedev have to deal with this to ensure that devices have a unique
> (and consistent) /dev entry.  It currently uses a tiered approach to
> determine exactly what the device is.  It''s not perfect but it
works
> reasonably well.  The best link I could find explaining it with a quick
> google is:
>
> http://www.gentoo.org/doc/en/udev-guide.xml
I''ll check it out, thanks.

Thinking about it, we could keep the device identification logic in userspace, 
which would be cleaner.  The tools could then just tell the backend to claim 
the device on a given port.  There''d be a few driver tweaks required to
make
it all work together but this may well be a cleaner approach.
> A GUI would be really handy for PCI/USB because it would provide an easy
> way to pick devices by name (instead of specifying an series of
> identifiers/bus/etc in the config).
Yes, I thought so to.  A general admin GUI is on our todo list locally but 
AFAIK nobody is working on it right now.  Every so often I poke the XenSV web 
interface to make sure it''s still working.
> I agree completely.  I''m currently adding proper documentation to
> vm-tools but after that''s done I''ll add USB
virtualization and try to
> implement a mechanism to select by device ID and push out another
> version to the list.
Cool!  

Cheers,
Mark


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Mon, 2005-02-14 at 11:19, Mark Williamson wrote:
> Thinking about it, we could keep the device identification logic in
userspace,
> which would be cleaner.  The tools could then just tell the backend to
claim
> the device on a given port.  There''d be a few driver tweaks
required to make
> it all work together but this may well be a cleaner approach.
Yes, this is how I also envisioned it would work.  I think the approach
has many advantages in general.
> Yes, I thought so to.  A general admin GUI is on our todo list locally but 
> AFAIK nobody is working on it right now.  Every so often I poke the XenSV
web
> interface to make sure it''s still working.
I''m trying to build a library around vm-tools so that doing something
like writing a GUI would be quite trivial.  At some point, I may try to
throw together a GUI but I figured that one of the distros would
probably beat me to it :-)

Regards,

-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net [mailto:xen-devel-
> admin@lists.sourceforge.net] On Behalf Of Mark Williamson
> Sent: 14 February 2005 16:36
> To: Anthony Liguori
> Cc: Mark Williamson; xen-devel@lists.sourceforge.net; Nivedita Singhvi
> Subject: Re: [Xen-devel] [PATCH] VM-Tool: C-based Xen management tools
> 
> > Yes, PCI wouldn''t be too hard to abstract.  Abstracting USB
worries
me a
> > bit though.  On the one hand, you want to abstract at the device
level.
> 
> That would be a neat feature.  It''d require changes to the backend
device
> driver to be a bit smarter about grabbing devices, as well as frontend
> changes to communicate device identities the backend...
> 
> > It''s even hairer with virtualization though.  Say you had two
harddrives
> > that were USB and not uniquely identifiable.  You want to assign
each
> > harddrive to a separate VM.  If you unplug them and swap ports, and
> > you''re using the old configurations, you really want that
each VM to
see
> > the harddrive they previously saw.  Swapping them could lead to
> > confusion and even worse, security problems.
> 
> The current implementation sidesteps all these by specifying port IDs.
> e.g.
> port 1 on my root hub always belongs to VM1 (when running), port 2 on
hub
> 3
> always belongs to VM2 (when running), etc.
A while back we were also discussing this to be the basic mechanism,
i.e. the level the exporting of USB devices work on. Then one could
implement higher level ''policies'' in say dom0. for example one
could
specify that if device of type foo gets plugged in then VM bar gets
granted access to that port. USB hotplugging should be able to do most
of the hard work...

rolf
> > Not sure the best solution here.  One of the reasons I''ve
held off
on
> USB.
> 
> For comparison, do you know what abstraction other systems do?  Do
they
> assign
> ports or associate devices with VMs?
> 
> The latter is definitely an attractive option...  If we added support
for
> both
> ways of doing things, paranoid people (or people with weird devices!)
> could
> use the port specifiers, whilst others used device IDs.
> 
> What do you think?
> 
> Cheers,
> Mark
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Anthony Liguori wrote:
> We''ve implemented a set of basic management tools for Xen.  The
tools
> are written in C and are currently capable of creating and shutting down 
> domains, connecting to a domain''s console, enumerating domains,
and
> attaching VBDs and VIFs to a domain.
hi,
these tools work fine for me as long as I am trying to use the network. 
Has anyone had any luck using these along with the bridging scripts, or 
with alternative scripts that do the same thing?

Jacob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Jacob Gorm Hansen wrote:
> hi,
> these tools work fine for me as long as I am trying to use the 
> network. Has anyone had any luck using these along with the bridging 
> scripts, or with alternative scripts that do the same thing?
I''ve manually gotten networking going invoking the Xend network script 
by hands.  I will automate this process eventually.  There''s just a 
number of other things I''m working on right now.

Regards,
Anthony Liguori
> Jacob
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Anthony Liguori wrote:
> Jacob Gorm Hansen wrote:
> 
>> hi,
>> these tools work fine for me as long as I am trying to use the 
>> network. Has anyone had any luck using these along with the bridging 
>> scripts, or with alternative scripts that do the same thing?
> 
> 
> I''ve manually gotten networking going invoking the Xend network
script
> by hands.  I will automate this process eventually.  There''s just
a
> number of other things I''m working on right now.
> 
So that would be:

- /etc/xen/scripts/network start
- nics=1 in the config-file
- vm create config-file
- /etc/xen/scripts/vif-bridge up vif=vif1.0 domain=Domain-1 mac=... 
bridge=xen-br0

Or am I missing something? The above does not seem to work for me.

thanks,
Jacob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Jacob Gorm Hansen wrote:
> So that would be:
>
> - /etc/xen/scripts/network start
> - nics=1 in the config-file
> - vm create config-file
> - /etc/xen/scripts/vif-bridge up vif=vif1.0 domain=Domain-1 mac=... 
> bridge=xen-br0
>
> Or am I missing something? The above does not seem to work for me.
I think I did something else.  I think the network script takes more 
parameters.  The way I figured out what to do was to annotate all of 
xend scripts and watch to see what it did.

I''ll post a HOWTO (or perhaps take a stab at automating it) on Monday 
using the new 0.0.2 release.  My local system doesn''t have enough
memory
to create anything other than a simple busybox domain.

Regards,
> thanks,
> Jacob
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel