[virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Richard W.M. Jones 

I think we need a place to store general metadata about guests.

Here are some uses:

 - Store data about available installer ISOs, guests which are
   archived and not known to libvirt.

 - Replace the guest inspection thread in virt-manager.  virt-manager
   would just collect the data from the store.  The inspection data
   would be generated by another process.

 - Expand on description/ field in the libvirt XML, and satisfy
   various requests we've had for a place to store metadata and extend
   libvirt XML.

 - Store data on behalf of applications, esp. virt-manager.

I'm not envisaging a database or daemon for this.  Just a simple
directory per host containing flat files.  Perhaps we can add some
tools or a library to make creation/querying of these files easy.  It
would be nice if the database was made available over the network
(Avahi?).

You could also use this database to answer questions like:

 - Do I have a Debian wheezy 32 bit guest anywhere on my network?

 - Does any guest have libpng = vulnerable-version installed?

 - Bring up a Fedora 14 instance (the tools would have to locate a
   suitable install ISO and put together the correct virt-install
   command line)

There is some crossover with VDSM and even RHEV-M here.

Thoughts?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Zeeshan Ali (Khattak) 
Hi,

On Mon, Aug 22, 2011 at 12:48 PM, Richard W.M. Jones rjo...@redhat.com wrote:

 I think we need a place to store general metadata about guests.

 Here are some uses:

  - Store data about available installer ISOs, guests which are
   archived and not known to libvirt.

  We will need this for our desktop integration plans but the
understanding is that we depend on Tracker[1] for this. Tracker will
need to be hacked to be able to differentiate between installer and
non-installer ISOs though but thats pretty much doable. I just wonder
if that solution also works for you?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://projects.gnome.org/tracker/

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [libosinfo] Add osinfo_db_guess_os_from_location()

2011-08-22 Thread Daniel P. Berrange 
On Sun, Aug 21, 2011 at 09:57:41PM +0300, Zeeshan Ali (Khattak) wrote:
 From: Zeeshan Ali (Khattak) zeesha...@gnome.org
 
 Add API to guess OS given an installation media location.
 ---
  docs/reference/Libosinfo-sections.txt |1 +
  osinfo/libosinfo.syms |1 +
  osinfo/osinfo_db.c|  155 
 -
  osinfo/osinfo_db.h|2 +
  4 files changed, 158 insertions(+), 1 deletions(-)
 
 diff --git a/docs/reference/Libosinfo-sections.txt 
 b/docs/reference/Libosinfo-sections.txt
 index 0aee98f..80816e6 100644
 --- a/docs/reference/Libosinfo-sections.txt
 +++ b/docs/reference/Libosinfo-sections.txt
 @@ -18,6 +18,7 @@ osinfo_db_add_os
  osinfo_db_add_platform
  osinfo_db_add_device
  osinfo_db_add_deployment
 +osinfo_db_guess_os_from_location
  osinfo_db_unique_values_for_property_in_os
  osinfo_db_unique_values_for_property_in_platform
  osinfo_db_unique_values_for_property_in_device
 diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
 index aadcbc3..b318c9a 100644
 --- a/osinfo/libosinfo.syms
 +++ b/osinfo/libosinfo.syms
 @@ -15,6 +15,7 @@ LIBOSINFO_0.0.1 {
   osinfo_db_add_platform;
   osinfo_db_add_device;
   osinfo_db_add_deployment;
 +osinfo_db_guess_os_from_location;
   osinfo_db_unique_values_for_property_in_os;
   osinfo_db_unique_values_for_property_in_platform;
   osinfo_db_unique_values_for_property_in_device;
 diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
 index 4c37365..9570cbd 100644
 --- a/osinfo/osinfo_db.c
 +++ b/osinfo/osinfo_db.c
 @@ -23,11 +23,43 @@
   */
  
  #include osinfo/osinfo.h
 +#include gio/gio.h
 +#include string.h
 +#include stdlib.h
 +
 +#define MAX_VOLUME 32
 +#define MAX_SYSTEM 32
 +#define MAX_PUBLISHER 128
 +
 +#define PVD_OFFSET 0x8000
 +#define BOOTABLE_TAG EL TORITO SPECIFICATION
 +
 +typedef struct _PrimaryVolumeDescriptor PrimaryVolumeDescriptor;
 +
 +struct _PrimaryVolumeDescriptor {
 +guint8 ignored[8];
 +gchar  system[MAX_SYSTEM];   /* System ID */
 +gchar  volume[MAX_VOLUME];   /* Volume ID */
 +guint8 ignored2[246];
 +gchar  publisher[MAX_PUBLISHER]; /* Publisher ID */
 +guint8 ignored3[1602];
 +};
 +
 +typedef struct _SupplementaryVolumeDescriptor SupplementaryVolumeDescriptor;
 +
 +struct _SupplementaryVolumeDescriptor {
 +guint8 ignored[7];
 +gchar  system[MAX_SYSTEM]; /* System ID */
 +};
  
  G_DEFINE_TYPE (OsinfoDb, osinfo_db, G_TYPE_OBJECT);
  
  #define OSINFO_DB_GET_PRIVATE(obj) (G_TYPE_INSTANCE_GET_PRIVATE ((obj), 
 OSINFO_TYPE_DB, OsinfoDbPrivate))
  
 +#define str_contains(str, substr) ((str)  \
 +   (substr)  \
 +   strstr((str), (substr)) != NULL)
 +
  /**
   * SECTION:osinfo_db
   * @short_description: Database of all entities
 @@ -144,7 +176,6 @@ OsinfoOs *osinfo_db_get_os(OsinfoDb *db, const gchar *id)
  return OSINFO_OS(osinfo_list_find_by_id(OSINFO_LIST(db-priv-oses), 
 id));
  }
  
 -
  /**
   * osinfo_db_get_deployment:
   * @db: the database
 @@ -316,6 +347,128 @@ void osinfo_db_add_deployment(OsinfoDb *db, 
 OsinfoDeployment *deployment)
  osinfo_list_add(OSINFO_LIST(db-priv-deployments), 
 OSINFO_ENTITY(deployment));
  }
  
 +/**
 + * osinfo_db_guess_os_from_location:
 + * @db: the database
 + * @location: the location of an installation media
 + *
 + * Returns: (transfer none): the operating system, or NULL if guessing failed
 + */
 +OsinfoOs *osinfo_db_guess_os_from_location(OsinfoDb *db,
 +   const gchar *location)
 +{
 +OsinfoOs *ret = NULL;
 +PrimaryVolumeDescriptor pvd;
 +SupplementaryVolumeDescriptor svd;
 +GFile *file;
 +GFileInputStream *stream;
 +GError *error = NULL;
 +GList *oss = NULL;
 +GList *os_iter;
 +
 +g_return_val_if_fail(OSINFO_IS_DB(db), NULL);
 +g_return_val_if_fail(location != NULL, NULL);
 +
 +file = g_file_new_for_commandline_arg(location);
 +stream = g_file_read(file, NULL, error);
 +if (error != NULL) {
 +g_warning (failed to read %s: %s,
 +   location,
 +   error-message);
 +g_error_free(error);
 +
 +goto EXIT;
 +}
 +
 +bzero(pvd, sizeof(pvd));
 +if (g_input_stream_skip(G_INPUT_STREAM(stream),
 +PVD_OFFSET,
 +NULL,
 +error)  0) {
 +g_warning (failed to skip %d bytes in %s: %s,
 +   PVD_OFFSET,
 +   location,
 +   error-message);
 +g_error_free(error);
 +
 +goto EXIT;
 +}
 +
 +if (g_input_stream_read(G_INPUT_STREAM(stream),
 +pvd,
 +sizeof (pvd),
 +NULL,
 +error)  0) {
 +g_warning (failed to read primary volume descriptor from %s: %s,

Re: [virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Richard W.M. Jones 
On Mon, Aug 22, 2011 at 01:04:07PM +0300, Zeeshan Ali (Khattak) wrote:
 Hi,
 
 On Mon, Aug 22, 2011 at 12:48 PM, Richard W.M. Jones rjo...@redhat.com 
 wrote:
 
  I think we need a place to store general metadata about guests.
 
  Here are some uses:
 
   - Store data about available installer ISOs, guests which are
    archived and not known to libvirt.
 
   We will need this for our desktop integration plans but the
 understanding is that we depend on Tracker[1] for this. Tracker will
 need to be hacked to be able to differentiate between installer and
 non-installer ISOs though but thats pretty much doable. I just wonder
 if that solution also works for you?
[...]
 [1] http://projects.gnome.org/tracker/

Where was it planned?

Tracker seems to be a desktop search engine.

Can we make the data available to Tracker without requiring it?
(Seems one has to write a tracker miner to do this)

Do we know that Tracker will stay around long-term (unlike Beagle etc)?

Is it available without requiring GNOME and other heavyweight deps
(eg. servers, KDE)?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] Are requests for new virsh commands acceptable?

2011-08-22 Thread dave bl 
Are requests/patches for new virsh commands acceptable? ... I keep
typing in boot instead of start, If I submit a patch to add
('boot') this would anyone have anything against it?

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Are requests for new virsh commands acceptable?

2011-08-22 Thread Richard W.M. Jones 
On Mon, Aug 22, 2011 at 09:06:29PM +1000, dave bl wrote:
 Are requests/patches for new virsh commands acceptable? ... I keep
 typing in boot instead of start, If I submit a patch to add
 ('boot') this would anyone have anything against it?

Certainly I've long wanted better aliases for virsh commands.

This should be discussed on libvir-list.  I suggest sending patches
there instead of here.

There was some discussion about 4-8 months ago about this subject.  It
might be a good idea to search the archives and familiarize yourself
with that first.

We can't remove the existing commands, and we should be careful about
aliases which might clash with future commands.  Something to think
about ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Zeeshan Ali (Khattak) 
On Mon, Aug 22, 2011 at 1:32 PM, Richard W.M. Jones rjo...@redhat.com wrote:
 On Mon, Aug 22, 2011 at 01:04:07PM +0300, Zeeshan Ali (Khattak) wrote:
 Hi,

 On Mon, Aug 22, 2011 at 12:48 PM, Richard W.M. Jones rjo...@redhat.com 
 wrote:
 
  I think we need a place to store general metadata about guests.
 
  Here are some uses:
 
   - Store data about available installer ISOs, guests which are
    archived and not known to libvirt.

   We will need this for our desktop integration plans but the
 understanding is that we depend on Tracker[1] for this. Tracker will
 need to be hacked to be able to differentiate between installer and
 non-installer ISOs though but thats pretty much doable. I just wonder
 if that solution also works for you?
 [...]
 [1] http://projects.gnome.org/tracker/

 Where was it planned?

   In a meeting we (a few members of the SPICE team) had at the
desktop summit together with designers. Its not really a plan plan but
more like a general agreement/understanding for now and we still await
the designers to finalize it all.

 Tracker seems to be a desktop search engine.

 Can we make the data available to Tracker without requiring it?
 (Seems one has to write a tracker miner to do this)

  The metadata you mean? Yes, thats going to be in osinfo. I intend to
write a minor that extracts just volume, system and publisher IDs and
a boolean indicating if the ISO is bootable but all that doesn't need
to use libosinfo (though there will be some minor duplication of
code).

 Do we know that Tracker will stay around long-term (unlike Beagle etc)?

  Beagle never really stayed around but Tracker hasn't just been
around for quite some time now but is also a blessed dependency in
GNOME and some of the core hackers of it are trust-worthy GNOME
hackers.

 Is it available without requiring GNOME and other heavyweight deps
 (eg. servers, KDE)?

  Yes! You still need dbus session though.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Richard W.M. Jones 
On Mon, Aug 22, 2011 at 02:22:00PM +0300, Zeeshan Ali (Khattak) wrote:
 On Mon, Aug 22, 2011 at 1:32 PM, Richard W.M. Jones rjo...@redhat.com 
 wrote    - Store data about available installer ISOs, guests which are
     archived and not known to libvirt.

[...]

   The metadata you mean? Yes, thats going to be in osinfo. I intend to
 write a minor that extracts just volume, system and publisher IDs and
 a boolean indicating if the ISO is bootable but all that doesn't need
 to use libosinfo (though there will be some minor duplication of
 code).

I think we're talking at crossed purposes about the feature I
mentioned above.

I mean that if I have a directory full of ISO files, then it should be
possible to make available some metadata about those files.  I'm
considering an ISO to be a special sort of guest that hasn't been
installed yet.  libvirt (nor libosinfo for that matter) doesn't
currently know anything about directories full of ISOs.  Nor about
guest templates.

In any case, ISOs aren't really the main point of my proposal.

I'm more interested in making the inspection data that we collect
about (actual, non-ISO) guests available to other consumers,
specifically to virt-manager.  Currently libvirt offers a
description/ field to do this, but it's extremely limited in what it
can contain, it's liable to be wiped out by accident, and it doesn't
support multiple users.

It's a fairly frequent request to be able to extend the libvirt XML to
store arbitrary guest data, and one which AFAIK has been rejected
upstream each time.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Zeeshan Ali (Khattak) 
On Mon, Aug 22, 2011 at 2:51 PM, Richard W.M. Jones rjo...@redhat.com wrote:
 On Mon, Aug 22, 2011 at 02:22:00PM +0300, Zeeshan Ali (Khattak) wrote:
 On Mon, Aug 22, 2011 at 1:32 PM, Richard W.M. Jones rjo...@redhat.com 
 wrote    - Store data about available installer ISOs, guests which are
     archived and not known to libvirt.

 [...]

   The metadata you mean? Yes, thats going to be in osinfo. I intend to
 write a minor that extracts just volume, system and publisher IDs and
 a boolean indicating if the ISO is bootable but all that doesn't need
 to use libosinfo (though there will be some minor duplication of
 code).

 I think we're talking at crossed purposes about the feature I
 mentioned above.

 I mean that if I have a directory full of ISO files, then it should be
 possible to make available some metadata about those files.  I'm
 considering an ISO to be a special sort of guest that hasn't been
 installed yet.  libvirt (nor libosinfo for that matter) doesn't
 currently know anything about directories full of ISOs.  Nor about
 guest templates.

  Yeah I think while you were talking of keeping a common metadata
table/db while I was talking about tracking of all ISOs that user have
so any app/lib can just make a simple query to get the list.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Darryl L. Pierce 
On Mon, Aug 22, 2011 at 10:48:09AM +0100, Richard W.M. Jones wrote:
snip 
  - Does any guest have libpng = vulnerable-version installed?

So the guest would also be reporting up to its host what packages it has
installed? Or is there some other mechanism in place that would all this
information to come out of the guest?

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpIYHCOIdtRk.pgp
Description: PGP signature
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Proposal: A place to store metadata about guests

2011-08-22 Thread Richard W.M. Jones 
On Mon, Aug 22, 2011 at 09:03:45AM -0400, Darryl L. Pierce wrote:
 On Mon, Aug 22, 2011 at 10:48:09AM +0100, Richard W.M. Jones wrote:
 snip 
   - Does any guest have libpng = vulnerable-version installed?
 
 So the guest would also be reporting up to its host what packages it has
 installed? Or is there some other mechanism in place that would all this
 information to come out of the guest?

virt-inspector provides this info.  In particular I don't just want
this database to work for running guests.  It's possibly most useful
for shut down or archived guests.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] vm fails to boot, need to modify guest registry

2011-08-22 Thread Richard W.M. Jones 
On Mon, Aug 22, 2011 at 11:03:03AM -0400, Kenny Armstrong wrote:
 Nevermind, just realized the error in the question.  Windows needs
 to boot in order to read anything from the registry, however we
 can't even get that far.

Did W2K3 use BCD or BOOT.INI?  If it was old enough to use BOOT.INI
then you might try editing it:

# guestfish -i -d WinXPRecConsole
fs edit /boot.ini

and I think change all disk(0) - disk(1) (or maybe rdisk(0) - rdisk(1)?)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] Fwd: virt-manager, dependency question

2011-08-22 Thread Jason Helfman 

Can anyone please confirm this for me?
Thanks!
Jason

--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD  4342 5E92 AD66 8C8C FBA5
---BeginMessage---

Hi,

I am working on cleaning up a dependency issue that was brought up with the
FreeBSD port for virt-manager, and wanted to confirm that virt-manager
doesn't require any gnome1 (gnome one, that is) libraries.

I've done all the checking and building from my end to determine that it
doesn't, however I would like a confirmation, if possible.

Thanks,
Jason
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD  4342 5E92 AD66 8C8C FBA5

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

---End Message---
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Fwd: virt-manager, dependency question

2011-08-22 Thread Daniel P. Berrange 
On Mon, Aug 22, 2011 at 09:19:11AM -0700, Jason Helfman wrote:
 Date: Fri, 19 Aug 2011 10:22:35 -0700
 From: Jason Helfman jhelf...@e-e.com
 To: virt-tools-list@redhat.com
 Subject: [virt-tools-list] virt-manager, dependency question
 
 Hi,
 
 I am working on cleaning up a dependency issue that was brought up with the
 FreeBSD port for virt-manager, and wanted to confirm that virt-manager
 doesn't require any gnome1 (gnome one, that is) libraries.
 
 I've done all the checking and building from my end to determine that it
 doesn't, however I would like a confirmation, if possible.

No application from the last 5+ years should require Gnome1. Any that
have not ported to gnome 2 by now must be pretty unmaintained.

virt-manager certainly does not require gnome1, and I'm fairly sure
it does not even require gnome2 either.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Fwd: virt-manager, dependency question

2011-08-22 Thread Richard W.M. Jones 
On Mon, Aug 22, 2011 at 09:19:11AM -0700, Jason Helfman wrote:
 Can anyone please confirm this for me?

Gnome 1 is pretty unlikely.  I don't think any of those
packages are even in Fedora.

Here is the dependency list for virt-manager in a recent Fedora:

/bin/sh  
GConf2  
dbus-python = 0.61
dbus-x11  
desktop-file-utils  
gnome-keyring = 0.4.9
gnome-python2-gconf = 1.99.11-7
gnome-python2-gnomekeyring = 2.15.4
gtk-vnc-python = 0.3.8
libvirt-python = 0.7.0
libxml2-python = 2.6.23
pygtk2 = 1.99.12-6
pygtk2-libglade  
python-virtinst = 0.600.0
scrollkeeper  
spice-gtk-python  
virt-manager-common = 0.9.0-5.fc16
vte = 0.12.2

But remember this is a full fat virt-manager.  You can get away with
fewer features.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] vm fails to boot, need to modify guest registry

2011-08-22 Thread Kenny Armstrong 
I'll give that a shot.  Someone else suggested changing the disk order 
in the xml file, but when I run guestfish on each disk, the order is 
already correct in the xml file.


I'll dig into the boot.ini idea.

-Kenny

On 08/22/2011 11:57 AM, Richard W.M. Jones wrote:

On Mon, Aug 22, 2011 at 11:03:03AM -0400, Kenny Armstrong wrote:

Nevermind, just realized the error in the question.  Windows needs
to boot in order to read anything from the registry, however we
can't even get that far.

Did W2K3 use BCD or BOOT.INI?  If it was old enough to use BOOT.INI
then you might try editing it:

# guestfish -i -d WinXPRecConsole

fs  edit /boot.ini

and I think change all disk(0) -  disk(1) (or maybe rdisk(0) -  rdisk(1)?)

Rich.



___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] ANNOUNCE: oz0.6.0 release

2011-08-22 Thread Chris Lalancette 
All,
 I'm pleased to announce release 0.6.0 of Oz.  Oz is a program for doing
automated installation of guest operating systems with limited input from
the user.
 Release 0.6.0 is a bugfix and feature release for Oz.  Some of the
highlights between Oz 0.5.0 and 0.6.0 are:

- The ability to specify the destination for the ICICLE output from oz-install
and oz-generate-icicle
- pydoc class documentation for all internal Oz classes
- Automatic detection of KVM or QEMU at runtime (this allows oz to be used
within virtual machines, although with a large performance hit)
- Less scary warning messages in the debug output
- Printing of the screenshot path when a build fails
- Ability to run multiple Oz installs of the same OS at the same time
- Support for OEL and ScientificLinux
- Support for RHEL-5.7
- Support for CentOS 6
- Support for OpenSUSE arbitrary file injection and command execution
- Ability to make the TDL (template) parsing enforce a root password
- Rejection of localhost URLs for repositories (since they must be reachable
from the guest operating system, localhost URLs make no sense)

Fedora-14, Fedora-15, and RHEL-6 packages are available for this release.  Note
that to install the RHEL-6 packages, you must be running RHEL-6.1 or later.
Instructions on how to get and use Oz are available at
http://aeolusproject.org/oz.html

If you have any questions or comments about Oz, please feel free to contact
aeolus-de...@lists.fedorahosted.org or me (clala...@redhat.com) directly.

Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.

-- 
Chris Lalancette

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] vm fails to boot, need to modify guest registry

2011-08-22 Thread Kenny Armstrong 
Nope, I tried changing disk(0) to disk(1), then both rdisk and disk to 
1, then just rdisk by itself.  It's the damnedest thing, I've never seen 
this before.


It happened to two servers, one running RHEL 6 as a host, and the other 
Scientific Linux 6 as the host.  Both on the same day.


On 08/22/2011 12:55 PM, Kenny Armstrong wrote:
I'll give that a shot.  Someone else suggested changing the disk order 
in the xml file, but when I run guestfish on each disk, the order is 
already correct in the xml file.


I'll dig into the boot.ini idea.

-Kenny

On 08/22/2011 11:57 AM, Richard W.M. Jones wrote:

On Mon, Aug 22, 2011 at 11:03:03AM -0400, Kenny Armstrong wrote:

Nevermind, just realized the error in the question.  Windows needs
to boot in order to read anything from the registry, however we
can't even get that far.

Did W2K3 use BCD or BOOT.INI?  If it was old enough to use BOOT.INI
then you might try editing it:

# guestfish -i -d WinXPRecConsole

fs  edit /boot.ini
and I think change all disk(0) -  disk(1) (or maybe rdisk(0) -  
rdisk(1)?)


Rich.



___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list


___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [libosinfo 2/4] Add osinfo_db_guess_os_from_location()

2011-08-22 Thread Zeeshan Ali (Khattak) 
From: Zeeshan Ali (Khattak) zeesha...@gnome.org

Add API to guess OS given an installation media location.
---
 docs/reference/Libosinfo-sections.txt |1 +
 osinfo/libosinfo.syms |2 +
 osinfo/osinfo_db.c|  191 -
 osinfo/osinfo_db.h|   30 +
 4 files changed, 223 insertions(+), 1 deletions(-)

diff --git a/docs/reference/Libosinfo-sections.txt 
b/docs/reference/Libosinfo-sections.txt
index 0aee98f..80816e6 100644
--- a/docs/reference/Libosinfo-sections.txt
+++ b/docs/reference/Libosinfo-sections.txt
@@ -18,6 +18,7 @@ osinfo_db_add_os
 osinfo_db_add_platform
 osinfo_db_add_device
 osinfo_db_add_deployment
+osinfo_db_guess_os_from_location
 osinfo_db_unique_values_for_property_in_os
 osinfo_db_unique_values_for_property_in_platform
 osinfo_db_unique_values_for_property_in_device
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index aadcbc3..2b2a03e 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -1,6 +1,7 @@
 LIBOSINFO_0.0.1 {
 global:
osinfo_db_get_type;
+   osinfo_install_media_error_quark;
osinfo_db_new;
osinfo_db_get_platform;
osinfo_db_get_device;
@@ -15,6 +16,7 @@ LIBOSINFO_0.0.1 {
osinfo_db_add_platform;
osinfo_db_add_device;
osinfo_db_add_deployment;
+   osinfo_db_guess_os_from_location;
osinfo_db_unique_values_for_property_in_os;
osinfo_db_unique_values_for_property_in_platform;
osinfo_db_unique_values_for_property_in_device;
diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
index 4c37365..d8e6b7c 100644
--- a/osinfo/osinfo_db.c
+++ b/osinfo/osinfo_db.c
@@ -23,11 +23,54 @@
  */
 
 #include osinfo/osinfo.h
+#include gio/gio.h
+#include string.h
+#include stdlib.h
+
+#define MAX_VOLUME 32
+#define MAX_SYSTEM 32
+#define MAX_PUBLISHER 128
+
+#define PVD_OFFSET 0x8000
+#define BOOTABLE_TAG EL TORITO SPECIFICATION
+
+typedef struct _PrimaryVolumeDescriptor PrimaryVolumeDescriptor;
+
+struct _PrimaryVolumeDescriptor {
+guint8 ignored[8];
+gchar  system[MAX_SYSTEM];   /* System ID */
+gchar  volume[MAX_VOLUME];   /* Volume ID */
+guint8 ignored2[246];
+gchar  publisher[MAX_PUBLISHER]; /* Publisher ID */
+guint8 ignored3[1602];
+};
+
+typedef struct _SupplementaryVolumeDescriptor SupplementaryVolumeDescriptor;
+
+struct _SupplementaryVolumeDescriptor {
+guint8 ignored[7];
+gchar  system[MAX_SYSTEM]; /* System ID */
+};
+
+GQuark
+osinfo_install_media_error_quark (void)
+{
+static GQuark quark = 0;
+
+if (!quark)
+quark = g_quark_from_static_string (osinfo-install-media-error);
+
+return quark;
+}
 
 G_DEFINE_TYPE (OsinfoDb, osinfo_db, G_TYPE_OBJECT);
 
 #define OSINFO_DB_GET_PRIVATE(obj) (G_TYPE_INSTANCE_GET_PRIVATE ((obj), 
OSINFO_TYPE_DB, OsinfoDbPrivate))
 
+#define str_contains(str, substr) ((str)  \
+   (substr)  \
+   strstr((str), (substr)) != NULL)
+
 /**
  * SECTION:osinfo_db
  * @short_description: Database of all entities
@@ -144,7 +187,6 @@ OsinfoOs *osinfo_db_get_os(OsinfoDb *db, const gchar *id)
 return OSINFO_OS(osinfo_list_find_by_id(OSINFO_LIST(db-priv-oses), id));
 }
 
-
 /**
  * osinfo_db_get_deployment:
  * @db: the database
@@ -316,6 +358,153 @@ void osinfo_db_add_deployment(OsinfoDb *db, 
OsinfoDeployment *deployment)
 osinfo_list_add(OSINFO_LIST(db-priv-deployments), 
OSINFO_ENTITY(deployment));
 }
 
+/**
+ * osinfo_db_guess_os_from_location:
+ * @db: the database
+ * @location: the location of an installation media
+ * @cancellable (allow-none): a #GCancellable, or %NULL
+ * @error: The location where to store any error, or %NULL
+ *
+ * The @location could be any URI that GIO can handle or a local path.
+ *
+ * NOTE: Currently this only works for ISO images/devices.
+ *
+ * Returns: (transfer none): the operating system, or NULL if guessing failed
+ */
+OsinfoOs *osinfo_db_guess_os_from_location(OsinfoDb *db,
+   const gchar *location,
+   GCancellable *cancellable,
+   GError **error)
+{
+OsinfoOs *ret = NULL;
+PrimaryVolumeDescriptor pvd;
+SupplementaryVolumeDescriptor svd;
+GFile *file;
+GFileInputStream *stream;
+GList *oss = NULL;
+GList *os_iter;
+
+g_return_val_if_fail(OSINFO_IS_DB(db), NULL);
+g_return_val_if_fail(location != NULL, NULL);
+g_return_val_if_fail(error == NULL || *error == NULL, NULL);
+
+file = g_file_new_for_commandline_arg(location);
+stream = g_file_read(file, NULL, error);
+if (error != NULL  *error != NULL) {
+g_prefix_error(error, Failed to open file);
+
+goto EXIT;
+}
+
+memset(pvd, 0, sizeof(pvd));
+if (g_input_stream_skip(G_INPUT_STREAM(stream),
+PVD_OFFSET,
+

[virt-tools-list] [libosinfo 3/4] Add osinfo_media_new_from_location()

2011-08-22 Thread Zeeshan Ali (Khattak) 
From: Zeeshan Ali (Khattak) zeesha...@gnome.org

Add API to create a OsinfoMedia object, given an installation media
location. This includes moving of installation media errors to
osinfo_media module and rename from OsinfoInstallMediaError to
OsinfoMediaError.

Some application/libraries will want to be able to get basic information
about an installation media without having to load the whole metadata DB.
---
 osinfo/libosinfo.syms |3 +-
 osinfo/osinfo_db.c|  148 +
 osinfo/osinfo_db.h|   24 ---
 osinfo/osinfo_media.c |  176 +
 osinfo/osinfo_media.h |   28 
 5 files changed, 224 insertions(+), 155 deletions(-)

diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index 2b2a03e..e64156a 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -1,7 +1,6 @@
 LIBOSINFO_0.0.1 {
 global:
osinfo_db_get_type;
-   osinfo_install_media_error_quark;
osinfo_db_new;
osinfo_db_get_platform;
osinfo_db_get_device;
@@ -142,7 +141,9 @@ LIBOSINFO_0.0.1 {
osinfo_deploymentlist_new_intersection;
osinfo_deploymentlist_new_union;
osinfo_media_get_type;
+   osinfo_media_error_quark;
osinfo_media_new;
+   osinfo_media_new_from_location;
osinfo_media_get_architecture;
osinfo_media_get_url;
osinfo_media_get_volume_id;
diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
index d8e6b7c..42ca7eb 100644
--- a/osinfo/osinfo_db.c
+++ b/osinfo/osinfo_db.c
@@ -25,43 +25,6 @@
 #include osinfo/osinfo.h
 #include gio/gio.h
 #include string.h
-#include stdlib.h
-
-#define MAX_VOLUME 32
-#define MAX_SYSTEM 32
-#define MAX_PUBLISHER 128
-
-#define PVD_OFFSET 0x8000
-#define BOOTABLE_TAG EL TORITO SPECIFICATION
-
-typedef struct _PrimaryVolumeDescriptor PrimaryVolumeDescriptor;
-
-struct _PrimaryVolumeDescriptor {
-guint8 ignored[8];
-gchar  system[MAX_SYSTEM];   /* System ID */
-gchar  volume[MAX_VOLUME];   /* Volume ID */
-guint8 ignored2[246];
-gchar  publisher[MAX_PUBLISHER]; /* Publisher ID */
-guint8 ignored3[1602];
-};
-
-typedef struct _SupplementaryVolumeDescriptor SupplementaryVolumeDescriptor;
-
-struct _SupplementaryVolumeDescriptor {
-guint8 ignored[7];
-gchar  system[MAX_SYSTEM]; /* System ID */
-};
-
-GQuark
-osinfo_install_media_error_quark (void)
-{
-static GQuark quark = 0;
-
-if (!quark)
-quark = g_quark_from_static_string (osinfo-install-media-error);
-
-return quark;
-}
 
 G_DEFINE_TYPE (OsinfoDb, osinfo_db, G_TYPE_OBJECT);
 
@@ -377,98 +340,24 @@ OsinfoOs *osinfo_db_guess_os_from_location(OsinfoDb *db,
GError **error)
 {
 OsinfoOs *ret = NULL;
-PrimaryVolumeDescriptor pvd;
-SupplementaryVolumeDescriptor svd;
-GFile *file;
-GFileInputStream *stream;
+OsinfoMedia *media;
 GList *oss = NULL;
 GList *os_iter;
+const gchar *media_volume;
+const gchar *media_system;
+const gchar *media_publisher;
 
 g_return_val_if_fail(OSINFO_IS_DB(db), NULL);
 g_return_val_if_fail(location != NULL, NULL);
 g_return_val_if_fail(error == NULL || *error == NULL, NULL);
 
-file = g_file_new_for_commandline_arg(location);
-stream = g_file_read(file, NULL, error);
-if (error != NULL  *error != NULL) {
-g_prefix_error(error, Failed to open file);
-
-goto EXIT;
-}
-
-memset(pvd, 0, sizeof(pvd));
-if (g_input_stream_skip(G_INPUT_STREAM(stream),
-PVD_OFFSET,
-cancellable,
-error)  sizeof(pvd)) {
-if (*error)
-g_prefix_error(error, Failed to skip %d bytes, PVD_OFFSET);
-else
-g_set_error(error,
- OSINFO_INSTALL_MEDIA_ERROR,
- OSINFO_INSTALL_MEDIA_ERROR_NO_DESCRIPTORS,
- No volume descriptors);
-
+media = osinfo_media_new_from_location (location, cancellable, error);
+if (*error != NULL)
 goto EXIT;
-}
-
-if (g_input_stream_read(G_INPUT_STREAM(stream),
-pvd,
-sizeof(pvd),
-cancellable,
-error)  sizeof(pvd)) {
-if (*error)
-g_prefix_error(error, Failed to read primary volume descriptor);
-else
-g_set_error(error,
-OSINFO_INSTALL_MEDIA_ERROR,
-OSINFO_INSTALL_MEDIA_ERROR_NO_PVD,
-Primary volume descriptor unavailable);
-
-goto EXIT;
-}
-
-pvd.volume[MAX_VOLUME - 1] = 0;
-pvd.system[MAX_SYSTEM - 1] = 0;
-pvd.publisher[MAX_PUBLISHER - 1] = 0;
-
-if (pvd.volume[0]  (pvd.system[0] == 0  pvd.publisher[0] == 0)) {
-g_set_error(error,
-

[virt-tools-list] [libosinfo 4/4] Replace OsinfoDb.guess_os_from_location() by guess_os_from_media()

2011-08-22 Thread Zeeshan Ali (Khattak) 
From: Zeeshan Ali (Khattak) zeesha...@gnome.org

---
 docs/reference/Libosinfo-sections.txt |2 +-
 osinfo/libosinfo.syms |2 +-
 osinfo/osinfo_db.c|   25 +
 osinfo/osinfo_db.h|5 +
 4 files changed, 8 insertions(+), 26 deletions(-)

diff --git a/docs/reference/Libosinfo-sections.txt 
b/docs/reference/Libosinfo-sections.txt
index 80816e6..69cd863 100644
--- a/docs/reference/Libosinfo-sections.txt
+++ b/docs/reference/Libosinfo-sections.txt
@@ -18,7 +18,7 @@ osinfo_db_add_os
 osinfo_db_add_platform
 osinfo_db_add_device
 osinfo_db_add_deployment
-osinfo_db_guess_os_from_location
+osinfo_db_guess_os_from_media
 osinfo_db_unique_values_for_property_in_os
 osinfo_db_unique_values_for_property_in_platform
 osinfo_db_unique_values_for_property_in_device
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index e64156a..0e9751d 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -15,7 +15,7 @@ LIBOSINFO_0.0.1 {
osinfo_db_add_platform;
osinfo_db_add_device;
osinfo_db_add_deployment;
-   osinfo_db_guess_os_from_location;
+   osinfo_db_guess_os_from_media;
osinfo_db_unique_values_for_property_in_os;
osinfo_db_unique_values_for_property_in_platform;
osinfo_db_unique_values_for_property_in_device;
diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
index 42ca7eb..a766a3c 100644
--- a/osinfo/osinfo_db.c
+++ b/osinfo/osinfo_db.c
@@ -322,25 +322,17 @@ void osinfo_db_add_deployment(OsinfoDb *db, 
OsinfoDeployment *deployment)
 }
 
 /**
- * osinfo_db_guess_os_from_location:
+ * osinfo_db_guess_os_from_media:
  * @db: the database
- * @location: the location of an installation media
- * @cancellable (allow-none): a #GCancellable, or %NULL
- * @error: The location where to store any error, or %NULL
+ * @media: the installation media
  *
- * The @location could be any URI that GIO can handle or a local path.
- *
- * NOTE: Currently this only works for ISO images/devices.
+ * Guess operating system given a #OsinfoMedia object.
  *
  * Returns: (transfer none): the operating system, or NULL if guessing failed
  */
-OsinfoOs *osinfo_db_guess_os_from_location(OsinfoDb *db,
-   const gchar *location,
-   GCancellable *cancellable,
-   GError **error)
+OsinfoOs *osinfo_db_guess_os_from_media(OsinfoDb *db, OsinfoMedia *media)
 {
 OsinfoOs *ret = NULL;
-OsinfoMedia *media;
 GList *oss = NULL;
 GList *os_iter;
 const gchar *media_volume;
@@ -348,12 +340,7 @@ OsinfoOs *osinfo_db_guess_os_from_location(OsinfoDb *db,
 const gchar *media_publisher;
 
 g_return_val_if_fail(OSINFO_IS_DB(db), NULL);
-g_return_val_if_fail(location != NULL, NULL);
-g_return_val_if_fail(error == NULL || *error == NULL, NULL);
-
-media = osinfo_media_new_from_location (location, cancellable, error);
-if (*error != NULL)
-goto EXIT;
+g_return_val_if_fail(media != NULL, NULL);
 
 media_volume = osinfo_media_get_volume_id(media);
 media_system = osinfo_media_get_system_id(media);
@@ -387,9 +374,7 @@ OsinfoOs *osinfo_db_guess_os_from_location(OsinfoDb *db,
 break;
 }
 
-EXIT:
 g_list_free(oss);
-g_clear_object(media);
 
 return ret;
 }
diff --git a/osinfo/osinfo_db.h b/osinfo/osinfo_db.h
index f3ba37e..0165c30 100644
--- a/osinfo/osinfo_db.h
+++ b/osinfo/osinfo_db.h
@@ -93,10 +93,7 @@ void osinfo_db_add_platform(OsinfoDb *db, OsinfoPlatform 
*platform);
 void osinfo_db_add_device(OsinfoDb *db, OsinfoDevice *device);
 void osinfo_db_add_deployment(OsinfoDb *db, OsinfoDeployment *deployment);
 
-OsinfoOs *osinfo_db_guess_os_from_location(OsinfoDb *db,
-   const gchar *location,
-   GCancellable *cancellable,
-   GError **error);
+OsinfoOs *osinfo_db_guess_os_from_media(OsinfoDb *db, OsinfoMedia *media);
 
 // Get me all unique values for property vendor among operating systems
 GList *osinfo_db_unique_values_for_property_in_os(OsinfoDb *db, const gchar 
*propName);
-- 
1.7.6

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [libosinfo 3/4] Add osinfo_media_new_from_location()

2011-08-22 Thread Zeeshan Ali (Khattak) 
On Tue, Aug 23, 2011 at 12:31 AM, Zeeshan Ali (Khattak)
zeesha...@gnome.org wrote:

 Add API to create a OsinfoMedia object, given an installation media
 location. This includes moving of installation media errors to
 osinfo_media module and rename from OsinfoInstallMediaError to
 OsinfoMediaError.

 Some application/libraries will want to be able to get basic information
 about an installation media without having to load the whole metadata DB.

   Async variant of this function is under development in the form of
two functions: osinfo_media_new_from_location_async() and
osinfo_media_new_from_location_finish().

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list