From mburns at redhat.com  Tue Jan  8 13:17:31 2013
From: mburns at redhat.com (Mike Burns)
Date: Tue, 8 Jan 2013 08:17:31 -0500 (EST)
Subject: [node-devel] Cancelled: oVirt Node weekly meeting
Message-ID: <1437600919.1074989.1357651051757.JavaMail.root@redhat.com>

A single instance of the following meeting has been cancelled:

Subject: oVirt Node weekly meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt on irc.oftc.net 
Time: Tuesday, January 8, 2013, 9:00:00 AM - 9:30:00 AM GMT -05:00 US/Canada Eastern
 
Invitees: aliguori at linux.vnet.ibm.com; anthony at codemonkey.ws; node-devel at ovirt.org; whenry at redhat.com 


*~*~*~*~*~*~*~*~*~*

Weekly call to go over features, bugs, tasks, etc 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130108/40adfebc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2853 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130108/40adfebc/attachment.ics>

From fabiand at redhat.com  Wed Jan  9 20:43:51 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Wed, 09 Jan 2013 21:43:51 +0100
Subject: [node-devel] It's the installer!
Message-ID: <1357764231.9404.2.camel@fdeutsch-laptop.local>

Hey,

after working and progressing good on the TUI I also started working on
reworking the current installer code to be also based on the reworked
TUI stuff.

I've submitted the initial stuff for this reworked installer (all pages
implemented, logic will follow) here:
http://gerrit.ovirt.org/#/c/10837/

The reason for doing this should be obvious and I hope you are as exited
as me to pave the way for a cleaner code experience :)

Greetings
fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130109/1249b3fa/attachment.sig>

From mburns at redhat.com  Thu Jan 10 01:07:58 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 09 Jan 2013 20:07:58 -0500
Subject: [node-devel] ATTN: Project Maintainers: Code Freeze/Branch/Beta
	Build deadlines
Message-ID: <1357780078.2865.26.camel@beelzebub.mburnsfire.net>

(Sorry for cross posting, trying to ensure I hit all the relevant
maintainers)

If you are the primary maintainer of a sub-project in oVirt, this
message is for you.

At the Weekly oVirt Meeting, the final devel freeze and beta dates were
decided.  

Freeze:  2013-01-14
Beta Post: 2013-01-15

Action items:

* You project should create a new branch in gerrit for the release
* You should create a formal build of your project for the beta post
* Get the formal build of your project into the hands of someone who can
post it [1][2]

These should all be done by EOD on 2013-01-14 (with the exception of
ovirt-node-iso) [3]

Packages that this impacts:

      * mom
      * otopi
      * ovirt-engine
      * ovirt-engine-cli
      * ovirt-engine-sdk
      * ovirt-guest-agent
      * ovirt-host-deploy
      * ovirt-image-uploader
      * ovirt-iso-uploader
      * ovirt-log-collector
      * ovirt-node
      * ovirt-node-iso
      * vdsm

Thanks

Mike Burns

[1] This is only necessary if the package is *not* already in fedora
repos (must be in actual fedora repos, not just updates-testing or koji)
[2] Communicate with mburns, mgoldboi, oschreib to deliver the packages
[3] ovirt-node-iso requires some of the other packages to be available
prior to creating the image.  This image will be created either on
2013-01-14 or 2013-01-15 and posted along with the rest of the Beta.



From mburns at redhat.com  Thu Jan 10 01:10:52 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 09 Jan 2013 20:10:52 -0500
Subject: [node-devel] It's the installer!
In-Reply-To: <1357764231.9404.2.camel@fdeutsch-laptop.local>
References: <1357764231.9404.2.camel@fdeutsch-laptop.local>
Message-ID: <1357780252.2865.27.camel@beelzebub.mburnsfire.net>

On Wed, 2013-01-09 at 21:43 +0100, Fabian Deutsch wrote:

Woot!

Thanks, great work.  Maybe we can get this into the node for the 2.6.0
release.

Mike

> Hey,
> 
> after working and progressing good on the TUI I also started working on
> reworking the current installer code to be also based on the reworked
> TUI stuff.
> 
> I've submitted the initial stuff for this reworked installer (all pages
> implemented, logic will follow) here:
> http://gerrit.ovirt.org/#/c/10837/
> 
> The reason for doing this should be obvious and I hope you are as exited
> as me to pave the way for a cleaner code experience :)
> 
> Greetings
> fabian
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel




From mburns at redhat.com  Thu Jan 10 16:04:06 2013
From: mburns at redhat.com (Mike Burns)
Date: Thu, 10 Jan 2013 11:04:06 -0500
Subject: [node-devel] Weekly oVirt Node meeting time change
Message-ID: <1357833846.2865.56.camel@beelzebub.mburnsfire.net>

Hi all,

Are there any objections to moving the weekly node meeting to 10 AM EST
(15:00 UTC, 1 hour later than it is currently)?  

Thanks

Mike



From fabiand at redhat.com  Thu Jan 10 16:09:34 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 10 Jan 2013 17:09:34 +0100
Subject: [node-devel] F18 tracker bug
Message-ID: <1357834174.2374.21.camel@fdeutsch-laptop.local>

Hey,

I've created https://bugzilla.redhat.com/show_bug.cgi?id=894059
to track all bugs which arose from the migration to Fedora 18.

Up to now these are just build related bugs (taken from the jenkins
logs).

Greetings
fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130110/f54c7699/attachment.sig>

From mburns at redhat.com  Mon Jan 14 14:59:06 2013
From: mburns at redhat.com (Mike Burns)
Date: Mon, 14 Jan 2013 09:59:06 -0500 (EST)
Subject: [node-devel] oVirt Node weekly meeting
Message-ID: <1983964555.4373606.1358175546362.JavaMail.root@redhat.com>

The following meeting has been modified:

Subject: oVirt Node weekly meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt on irc.oftc.net 
Time: Tuesday, January 15, 2013, 10:00:00 AM - 10:30:00 AM GMT -05:00 US/Canada Eastern [MODIFIED]
 
Invitees: aliguori at linux.vnet.ibm.com; anthony at codemonkey.ws; node-devel at ovirt.org; whenry at redhat.com; rbarry at redhat.com 


*~*~*~*~*~*~*~*~*~*

Weekly call to go over features, bugs, tasks, etc 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130114/8ffdaa5a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2962 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130114/8ffdaa5a/attachment.ics>

From wenyi at linux.vnet.ibm.com  Wed Jan 16 05:33:31 2013
From: wenyi at linux.vnet.ibm.com (Wenyi Gao)
Date: Wed, 16 Jan 2013 13:33:31 +0800
Subject: [node-devel] run ovirt-node in non-livecd mode
Message-ID: <50F63BAB.8070107@linux.vnet.ibm.com>

Hey,

Currently, the ovirt-node hypervisor runs in livecd mode, that is the 
root filesystem is read-only.
We have to run "persist" command for persistent files, which is 
inconvenient for some uses who
run ovirt-node only as hypervisor alone. So do we have plan to let 
ovirt-node run non-livecd mode?
Thanks.


Best regards
Wenyi Gao



From mburns at redhat.com  Wed Jan 16 11:47:59 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 16 Jan 2013 06:47:59 -0500
Subject: [node-devel] run ovirt-node in non-livecd mode
In-Reply-To: <50F63BAB.8070107@linux.vnet.ibm.com>
References: <50F63BAB.8070107@linux.vnet.ibm.com>
Message-ID: <1358336879.25029.61.camel@beelzebub.mburnsfire.net>

On Wed, 2013-01-16 at 13:33 +0800, Wenyi Gao wrote:
> Hey,
> 
> Currently, the ovirt-node hypervisor runs in livecd mode, that is the 
> root filesystem is read-only.
> We have to run "persist" command for persistent files, which is 
> inconvenient for some uses who
> run ovirt-node only as hypervisor alone. So do we have plan to let 
> ovirt-node run non-livecd mode?
> Thanks.

Hi Wenyi,

ovirt-node doesn't just run in livecd mode, it *is* a livecd.  If you're
using ovirt-node with ovirt-engine (or derivative builds like RHEV-H
with RHEV-M), then you shouldn't have any need to persist anything
manually.  This is handled by the vdsm and ovirt-node packages
automatically.

There is no plan to let it run in any mode other than livecd.  There are
other options in those cases, like running a full OS rather than an
ovirt-node iso.

Thanks

Mike

> 
> 
> Best regards
> Wenyi Gao
> 
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel




From fabiand at redhat.com  Wed Jan 16 12:08:13 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Wed, 16 Jan 2013 13:08:13 +0100
Subject: [node-devel] Getting Node on Fedora 18 into shape
Message-ID: <1358338093.30871.7.camel@fdeutsch-laptop.local>

Hey,

this morning I sat down and started testing Node with this build:
http://jenkins.ovirt.org/view/ovirt_node/job/ovirt-node-iso/542/

There is a problem [0] which prevents a user from using the interface.
It nails down to that a call to libvirt is blocking (don't know why yet)
- this affects the new and old UI. Restarting libvirt helps (after
creating a root user [boot in single,
run /usr/libexec/ovirt-config-password, and reboot]) and restarting
libvirt manually.
I've also noticed a couple of smaller bugs in the new UI which fixed
[1].
After figuring out the above problem I only came round to test the
network page within the UI, which works. The other pages are open to be
tested.

Greetings
- fabian

---
[0] https://bugzilla.redhat.com/show_bug.cgi?id=895949
[1] http://gerrit.ovirt.org/#/c/11086/
http://jenkins.ovirt.org/view/ovirt_node/job/ovirt-node-iso-devel/1479/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130116/eef1094f/attachment.sig>

From wenyi at linux.vnet.ibm.com  Thu Jan 17 01:43:41 2013
From: wenyi at linux.vnet.ibm.com (Wenyi Gao)
Date: Thu, 17 Jan 2013 09:43:41 +0800
Subject: [node-devel] run ovirt-node in non-livecd mode
In-Reply-To: <1358336879.25029.61.camel@beelzebub.mburnsfire.net>
References: <50F63BAB.8070107@linux.vnet.ibm.com>
	<1358336879.25029.61.camel@beelzebub.mburnsfire.net>
Message-ID: <50F7574D.4030603@linux.vnet.ibm.com>

On 2013-01-16 19:47, Mike Burns wrote:
> On Wed, 2013-01-16 at 13:33 +0800, Wenyi Gao wrote:
>> Hey,
>>
>> Currently, the ovirt-node hypervisor runs in livecd mode, that is the
>> root filesystem is read-only.
>> We have to run "persist" command for persistent files, which is
>> inconvenient for some uses who
>> run ovirt-node only as hypervisor alone. So do we have plan to let
>> ovirt-node run non-livecd mode?
>> Thanks.
> Hi Wenyi,
>
> ovirt-node doesn't just run in livecd mode, it *is* a livecd.  If you're
> using ovirt-node with ovirt-engine (or derivative builds like RHEV-H
> with RHEV-M), then you shouldn't have any need to persist anything
> manually.  This is handled by the vdsm and ovirt-node packages
> automatically.
>
> There is no plan to let it run in any mode other than livecd.  There are
> other options in those cases, like running a full OS rather than an
> ovirt-node iso.
>
> Thanks
>
> Mike

Hi Mike,

Thank you very much for answering the question. My case is we are using 
ovirt-node
as hypervisor standalone without ovirt-engin or RHEV-M.


So could you have some ideas to keep the rootfs writeable into disks 
persistently
not into  tmpfs? Like overlay file system?


>>
>> Best regards
>> Wenyi Gao
>>
>> _______________________________________________
>> node-devel mailing list
>> node-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/node-devel
>



From mburns at redhat.com  Thu Jan 17 12:24:09 2013
From: mburns at redhat.com (Mike Burns)
Date: Thu, 17 Jan 2013 07:24:09 -0500
Subject: [node-devel] run ovirt-node in non-livecd mode
In-Reply-To: <50F7574D.4030603@linux.vnet.ibm.com>
References: <50F63BAB.8070107@linux.vnet.ibm.com>
	<1358336879.25029.61.camel@beelzebub.mburnsfire.net>
	<50F7574D.4030603@linux.vnet.ibm.com>
Message-ID: <1358425449.25029.81.camel@beelzebub.mburnsfire.net>

On Thu, 2013-01-17 at 09:43 +0800, Wenyi Gao wrote:
> On 2013-01-16 19:47, Mike Burns wrote:
> > On Wed, 2013-01-16 at 13:33 +0800, Wenyi Gao wrote:
> >> Hey,
> >>
> >> Currently, the ovirt-node hypervisor runs in livecd mode, that is the
> >> root filesystem is read-only.
> >> We have to run "persist" command for persistent files, which is
> >> inconvenient for some uses who
> >> run ovirt-node only as hypervisor alone. So do we have plan to let
> >> ovirt-node run non-livecd mode?
> >> Thanks.
> > Hi Wenyi,
> >
> > ovirt-node doesn't just run in livecd mode, it *is* a livecd.  If you're
> > using ovirt-node with ovirt-engine (or derivative builds like RHEV-H
> > with RHEV-M), then you shouldn't have any need to persist anything
> > manually.  This is handled by the vdsm and ovirt-node packages
> > automatically.
> >
> > There is no plan to let it run in any mode other than livecd.  There are
> > other options in those cases, like running a full OS rather than an
> > ovirt-node iso.
> >
> > Thanks
> >
> > Mike
> 
> Hi Mike,
> 
> Thank you very much for answering the question. My case is we are using 
> ovirt-node
> as hypervisor standalone without ovirt-engin or RHEV-M.
> 
> 
> So could you have some ideas to keep the rootfs writeable into disks 
> persistently
> not into  tmpfs? Like overlay file system?

There isn't really a way unless you are building the image yourself from
scratch, and even then, some things won't work as you would expect them
to.

One possibility:

      * add / to the rwtab or an rwtab.d file -- this makes everything
        writable, though not persistent.  It needs to be done at build
        time, though.
      * when installing, install with a very large Config partition.
        It's 5MB by default, but you will need far more than that.
      * persist the directories that you want persisted.  This will
        automatically persist everything in those directories
        to /config.  You probably don't want/need /var persisted since
        that is generally runtime-only data.  /data /var/log and /config
        are already backed by real storage, so no need to persist those
        either.  

In general, I don't recommend this.  There may be things that just don't
work the way you would expect.  The method for combining the 2
filesystems is done through bind-mounts which happen during the boot
process.  Therefore, some things that get persisted don't get
bind-mounted early enough in the process to be used correctly.  These
need special handling in the ovirt-early service.  

One other thing you could try is altering /etc/fstab in the base image
to symbolically link some directory in /data.  /data is backed by real
storage, so that would theoretically work as well and might be safer.
The change needs to be done in the base image at build time or using
something like a plugin to make this change.

Hope this helps

Mike


> 
> 
> >>
> >> Best regards
> >> Wenyi Gao
> >>
> >> _______________________________________________
> >> node-devel mailing list
> >> node-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/node-devel
> >
> 




From wenyi at linux.vnet.ibm.com  Fri Jan 18 01:03:50 2013
From: wenyi at linux.vnet.ibm.com (Wenyi Gao)
Date: Fri, 18 Jan 2013 09:03:50 +0800
Subject: [node-devel] run ovirt-node in non-livecd mode
In-Reply-To: <1358425449.25029.81.camel@beelzebub.mburnsfire.net>
References: <50F63BAB.8070107@linux.vnet.ibm.com>
	<1358336879.25029.61.camel@beelzebub.mburnsfire.net>
	<50F7574D.4030603@linux.vnet.ibm.com>
	<1358425449.25029.81.camel@beelzebub.mburnsfire.net>
Message-ID: <50F89F76.7020705@linux.vnet.ibm.com>

On 2013-01-17 20:24, Mike Burns wrote:
> On Thu, 2013-01-17 at 09:43 +0800, Wenyi Gao wrote:
>> On 2013-01-16 19:47, Mike Burns wrote:
>>> On Wed, 2013-01-16 at 13:33 +0800, Wenyi Gao wrote:
>>>> Hey,
>>>>
>>>> Currently, the ovirt-node hypervisor runs in livecd mode, that is the
>>>> root filesystem is read-only.
>>>> We have to run "persist" command for persistent files, which is
>>>> inconvenient for some uses who
>>>> run ovirt-node only as hypervisor alone. So do we have plan to let
>>>> ovirt-node run non-livecd mode?
>>>> Thanks.
>>> Hi Wenyi,
>>>
>>> ovirt-node doesn't just run in livecd mode, it *is* a livecd.  If you're
>>> using ovirt-node with ovirt-engine (or derivative builds like RHEV-H
>>> with RHEV-M), then you shouldn't have any need to persist anything
>>> manually.  This is handled by the vdsm and ovirt-node packages
>>> automatically.
>>>
>>> There is no plan to let it run in any mode other than livecd.  There are
>>> other options in those cases, like running a full OS rather than an
>>> ovirt-node iso.
>>>
>>> Thanks
>>>
>>> Mike
>> Hi Mike,
>>
>> Thank you very much for answering the question. My case is we are using
>> ovirt-node
>> as hypervisor standalone without ovirt-engin or RHEV-M.
>>
>>
>> So could you have some ideas to keep the rootfs writeable into disks
>> persistently
>> not into  tmpfs? Like overlay file system?
> There isn't really a way unless you are building the image yourself from
> scratch, and even then, some things won't work as you would expect them
> to.
>
> One possibility:
>
>        * add / to the rwtab or an rwtab.d file -- this makes everything
>          writable, though not persistent.  It needs to be done at build
>          time, though.
>        * when installing, install with a very large Config partition.
>          It's 5MB by default, but you will need far more than that.
>        * persist the directories that you want persisted.  This will
>          automatically persist everything in those directories
>          to /config.  You probably don't want/need /var persisted since
>          that is generally runtime-only data.  /data /var/log and /config
>          are already backed by real storage, so no need to persist those
>          either.
>
> In general, I don't recommend this.  There may be things that just don't
> work the way you would expect.  The method for combining the 2
> filesystems is done through bind-mounts which happen during the boot
> process.  Therefore, some things that get persisted don't get
> bind-mounted early enough in the process to be used correctly.  These
> need special handling in the ovirt-early service.
>
> One other thing you could try is altering /etc/fstab in the base image
> to symbolically link some directory in /data.  /data is backed by real
> storage, so that would theoretically work as well and might be safer.
> The change needs to be done in the base image at build time or using
> something like a plugin to make this change.
>
> Hope this helps
>
> Mike
>

Your suggestions is very helpful, thank you very much.

Wenyi Gao
>>
>>>> Best regards
>>>> Wenyi Gao
>>>>
>>>> _______________________________________________
>>>> node-devel mailing list
>>>> node-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/node-devel
>



From mburns at redhat.com  Mon Jan 21 14:22:48 2013
From: mburns at redhat.com (Mike Burns)
Date: Mon, 21 Jan 2013 09:22:48 -0500 (EST)
Subject: [node-devel] Cancelled: oVirt Node weekly meeting
Message-ID: <1871597006.1825819.1358778168163.JavaMail.root@redhat.com>

A single instance of the following meeting has been cancelled:

Subject: oVirt Node weekly meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt on irc.oftc.net 
Time: Tuesday, January 22, 2013, 8:00:00 AM - 8:30:00 AM GMT -05:00 US/Canada Eastern
 
Invitees: aliguori at linux.vnet.ibm.com; anthony at codemonkey.ws; node-devel at ovirt.org; whenry at redhat.com 


*~*~*~*~*~*~*~*~*~*

due to the oVirt Workshop, this meeting is being cancelled.  Please bring up any issues, etc, on node-devel@

Thanks

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130121/179e616d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2991 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130121/179e616d/attachment.ics>

From mburns at redhat.com  Tue Jan 22 13:58:30 2013
From: mburns at redhat.com (Mike Burns)
Date: Tue, 22 Jan 2013 08:58:30 -0500 (EST)
Subject: [node-devel] Cancelled: oVirt Node weekly meeting
Message-ID: <223275893.2331258.1358863110918.JavaMail.root@redhat.com>

A single instance of the following meeting has been cancelled:

Subject: oVirt Node weekly meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt on irc.oftc.net 
Time: Tuesday, January 22, 2013, 6:00:00 AM - 6:30:00 AM GMT -08:00 US/Canada Pacific
 
Invitees: aliguori at linux.vnet.ibm.com; anthony at codemonkey.ws; node-devel at ovirt.org; whenry at redhat.com 


*~*~*~*~*~*~*~*~*~*

Weekly call to go over features, bugs, tasks, etc 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130122/d24904c9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 3217 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130122/d24904c9/attachment.ics>

From simonjin at linux.vnet.ibm.com  Wed Jan 23 08:57:51 2013
From: simonjin at linux.vnet.ibm.com (simonjin)
Date: Wed, 23 Jan 2013 16:57:51 +0800
Subject: [node-devel] run ovirt-node in non-livecd mode
In-Reply-To: <1358425449.25029.81.camel@beelzebub.mburnsfire.net>
References: <50F63BAB.8070107@linux.vnet.ibm.com>
	<1358336879.25029.61.camel@beelzebub.mburnsfire.net>
	<50F7574D.4030603@linux.vnet.ibm.com>
	<1358425449.25029.81.camel@beelzebub.mburnsfire.net>
Message-ID: <50FFA60F.9030209@linux.vnet.ibm.com>

On 01/17/2013 08:24 PM, Mike Burns wrote:
> On Thu, 2013-01-17 at 09:43 +0800, Wenyi Gao wrote:
>> On 2013-01-16 19:47, Mike Burns wrote:
>>> On Wed, 2013-01-16 at 13:33 +0800, Wenyi Gao wrote:
>>>> Hey,
>>>>
>>>> Currently, the ovirt-node hypervisor runs in livecd mode, that is the
>>>> root filesystem is read-only.
>>>> We have to run "persist" command for persistent files, which is
>>>> inconvenient for some uses who
>>>> run ovirt-node only as hypervisor alone. So do we have plan to let
>>>> ovirt-node run non-livecd mode?
>>>> Thanks.
>>> Hi Wenyi,
>>>
>>> ovirt-node doesn't just run in livecd mode, it *is* a livecd.  If you're
>>> using ovirt-node with ovirt-engine (or derivative builds like RHEV-H
>>> with RHEV-M), then you shouldn't have any need to persist anything
>>> manually.  This is handled by the vdsm and ovirt-node packages
>>> automatically.
>>>
>>> There is no plan to let it run in any mode other than livecd.  There are
>>> other options in those cases, like running a full OS rather than an
>>> ovirt-node iso.
>>>
>>> Thanks
>>>
>>> Mike
>> Hi Mike,
>>
>> Thank you very much for answering the question. My case is we are using
>> ovirt-node
>> as hypervisor standalone without ovirt-engin or RHEV-M.
>>
>>
>> So could you have some ideas to keep the rootfs writeable into disks
>> persistently
>> not into  tmpfs? Like overlay file system?
> There isn't really a way unless you are building the image yourself from
> scratch, and even then, some things won't work as you would expect them
> to.
>
> One possibility:
>
>        * add / to the rwtab or an rwtab.d file -- this makes everything
>          writable, though not persistent.  It needs to be done at build
>          time, though.
>        * when installing, install with a very large Config partition.
>          It's 5MB by default, but you will need far more than that.
>        * persist the directories that you want persisted.  This will
>          automatically persist everything in those directories
>          to /config.  You probably don't want/need /var persisted since
>          that is generally runtime-only data.  /data /var/log and /config
>          are already backed by real storage, so no need to persist those
>          either.
>
> In general, I don't recommend this.  There may be things that just don't
> work the way you would expect.  The method for combining the 2
> filesystems is done through bind-mounts which happen during the boot
> process.  Therefore, some things that get persisted don't get
> bind-mounted early enough in the process to be used correctly.  These
> need special handling in the ovirt-early service.
>
> One other thing you could try is altering /etc/fstab in the base image
> to symbolically link some directory in /data.  /data is backed by real
> storage, so that would theoretically work as well and might be safer.
> The change needs to be done in the base image at build time or using
> something like a plugin to make this change.
>
> Hope this helps
>
What if we install ISO to disk and not using the way  copying the 
squashfs img, we copy the squashfs filesystem and mount root fs as rw,
like the way we install a LiveCD Fedora to disk.
Do you think it's  possible the ovirt-node would support in case some 
custom won't use a stateless ovirt-node and not working with ovirt-engine.

  -Simon
> Mike
>
>
>>
>>>> Best regards
>>>> Wenyi Gao
>>>>
>>>> _______________________________________________
>>>> node-devel mailing list
>>>> node-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/node-devel
>
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel
>




From mburns at redhat.com  Wed Jan 23 14:09:02 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 23 Jan 2013 06:09:02 -0800
Subject: [node-devel] run ovirt-node in non-livecd mode
In-Reply-To: <50FFA60F.9030209@linux.vnet.ibm.com>
References: <50F63BAB.8070107@linux.vnet.ibm.com>
	<1358336879.25029.61.camel@beelzebub.mburnsfire.net>
	<50F7574D.4030603@linux.vnet.ibm.com>
	<1358425449.25029.81.camel@beelzebub.mburnsfire.net>
	<50FFA60F.9030209@linux.vnet.ibm.com>
Message-ID: <1358950142.2192.4.camel@mburns-laptop.usersys.redhat.com>

On Wed, 2013-01-23 at 16:57 +0800, simonjin wrote:
> On 01/17/2013 08:24 PM, Mike Burns wrote:
> > On Thu, 2013-01-17 at 09:43 +0800, Wenyi Gao wrote:
> >> On 2013-01-16 19:47, Mike Burns wrote:
> >>> On Wed, 2013-01-16 at 13:33 +0800, Wenyi Gao wrote:
> >>>> Hey,
> >>>>
> >>>> Currently, the ovirt-node hypervisor runs in livecd mode, that is the
> >>>> root filesystem is read-only.
> >>>> We have to run "persist" command for persistent files, which is
> >>>> inconvenient for some uses who
> >>>> run ovirt-node only as hypervisor alone. So do we have plan to let
> >>>> ovirt-node run non-livecd mode?
> >>>> Thanks.
> >>> Hi Wenyi,
> >>>
> >>> ovirt-node doesn't just run in livecd mode, it *is* a livecd.  If you're
> >>> using ovirt-node with ovirt-engine (or derivative builds like RHEV-H
> >>> with RHEV-M), then you shouldn't have any need to persist anything
> >>> manually.  This is handled by the vdsm and ovirt-node packages
> >>> automatically.
> >>>
> >>> There is no plan to let it run in any mode other than livecd.  There are
> >>> other options in those cases, like running a full OS rather than an
> >>> ovirt-node iso.
> >>>
> >>> Thanks
> >>>
> >>> Mike
> >> Hi Mike,
> >>
> >> Thank you very much for answering the question. My case is we are using
> >> ovirt-node
> >> as hypervisor standalone without ovirt-engin or RHEV-M.
> >>
> >>
> >> So could you have some ideas to keep the rootfs writeable into disks
> >> persistently
> >> not into  tmpfs? Like overlay file system?
> > There isn't really a way unless you are building the image yourself from
> > scratch, and even then, some things won't work as you would expect them
> > to.
> >
> > One possibility:
> >
> >        * add / to the rwtab or an rwtab.d file -- this makes everything
> >          writable, though not persistent.  It needs to be done at build
> >          time, though.
> >        * when installing, install with a very large Config partition.
> >          It's 5MB by default, but you will need far more than that.
> >        * persist the directories that you want persisted.  This will
> >          automatically persist everything in those directories
> >          to /config.  You probably don't want/need /var persisted since
> >          that is generally runtime-only data.  /data /var/log and /config
> >          are already backed by real storage, so no need to persist those
> >          either.
> >
> > In general, I don't recommend this.  There may be things that just don't
> > work the way you would expect.  The method for combining the 2
> > filesystems is done through bind-mounts which happen during the boot
> > process.  Therefore, some things that get persisted don't get
> > bind-mounted early enough in the process to be used correctly.  These
> > need special handling in the ovirt-early service.
> >
> > One other thing you could try is altering /etc/fstab in the base image
> > to symbolically link some directory in /data.  /data is backed by real
> > storage, so that would theoretically work as well and might be safer.
> > The change needs to be done in the base image at build time or using
> > something like a plugin to make this change.
> >
> > Hope this helps
> >
> What if we install ISO to disk and not using the way  copying the 
> squashfs img, we copy the squashfs filesystem and mount root fs as rw,
> like the way we install a LiveCD Fedora to disk.
> Do you think it's  possible the ovirt-node would support in case some 
> custom won't use a stateless ovirt-node and not working with ovirt-engine.

It's something that could work for installation, but upgrades would be
very different, a lot of assumptions we make in our code would need to
change (assuming we need to persist, change everything that looks at
where the the livecd is mounted, etc).  It's not a simple change to make
everything work the same way in that environment.

If it's something you're really interested in, you can submit patches to
make it work that way, though.

Mike
> 
>   -Simon
> > Mike
> >
> >
> >>
> >>>> Best regards
> >>>> Wenyi Gao
> >>>>
> >>>> _______________________________________________
> >>>> node-devel mailing list
> >>>> node-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/node-devel
> >
> > _______________________________________________
> > node-devel mailing list
> > node-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/node-devel
> >
> 
> 
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel




From mburns at redhat.com  Wed Jan 23 14:41:34 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 23 Jan 2013 06:41:34 -0800
Subject: [node-devel] [Users] BFA FC driver no stable on Fedora
In-Reply-To: <CA+Vz4VoEPz=YeZXWxtHj1M9KO89jNJBs3q_SCGQqbYD7HeWEdQ@mail.gmail.com>
References: <CA+Vz4VoEPz=YeZXWxtHj1M9KO89jNJBs3q_SCGQqbYD7HeWEdQ@mail.gmail.com>
Message-ID: <1358952094.2192.12.camel@mburns-laptop.usersys.redhat.com>

On Wed, 2013-01-23 at 10:25 +0100, Kevin Maziere Aubry wrote:
> Hi 
> 
> 
> I've spent hours to make my Brocade FC card working on Fedora17 or
> Ovirt Node build.
> In fact the card are randomly seen by the system, which is really
> painfull.
> So I've downloaded, compile and installed the latest driver from
> Brocade, and now when I load the module the card is seen.
> So I've installed : 
> bfa_util_linux_noioctl-3.2.0.0-0.noarch
> bfa_driver_linux-3.2.0.0-0.noarch
> 

Hi Kevin,

A few things:

1.  what version of ovirt-node are you using?
2.  You can use the plugin tooling to install an updated kmod package as
long as it's in rpm format.  This will ensure that it gets into both the
system and the initramfs.  It's an offline process that will produce a
new iso that you can install or upgrade to.  The tool is called
edit-node and is available in the ovirt-node-tools rpm (from the
ovirt.org repos)
3.  Do you know if it's fixed in a recent release of the kernel on
Fedora?  If it is, then we can spin an updated version of the image and
pick up the fix directly from fedora.

Mike

> 
> And the module info are :
> # modinfo bfa
> filename:
>   /lib/modules/3.3.4-5.fc17.x86_64/kernel/drivers/scsi/bfa.ko
> version:        3.2.0.0
> author:         Brocade Communications Systems, Inc.
> description:    Brocade Fibre Channel HBA Driver fcpim ipfc
> license:        GPL
> srcversion:     5C0FBDF3571ABCA9632B9CA
> alias:          pci:v00001657d00000022sv*sd*bc0Csc04i00*
> alias:          pci:v00001657d00000021sv*sd*bc0Csc04i00*
> alias:          pci:v00001657d00000014sv*sd*bc0Csc04i00*
> alias:          pci:v00001657d00000017sv*sd*bc*sc*i*
> alias:          pci:v00001657d00000013sv*sd*bc*sc*i*
> depends:        scsi_transport_fc
> vermagic:       3.3.4-5.fc17.x86_64 SMP mod_unload 
> parm:           os_name:OS name of the hba host machine (charp)
> parm:           os_patch:OS patch level of the hba host machine
> (charp)
> parm:           host_name:Hostname of the hba host machine (charp)
> parm:           num_rports:Max number of rports supported per port
> (physical/logical), default=1024 (int)
> parm:           num_ioims:Max number of ioim requests, default=2000
> (int)
> parm:           num_tios:Max number of fwtio requests, default=0 (int)
> parm:           num_tms:Max number of task im requests, default=128
> (int)
> parm:           num_fcxps:Max number of fcxp requests, default=64
> (int)
> parm:           num_ufbufs:Max number of unsolicited frame buffers,
> default=64 (int)
> parm:           reqq_size:Max number of request queue elements,
> default=256 (int)
> parm:           rspq_size:Max number of response queue elements,
> default=64 (int)
> parm:           num_sgpgs:Number of scatter/gather pages, default=2048
> (int)
> parm:           rport_del_timeout:Rport delete timeout, default=90
> secs, Range[>0] (int)
> parm:           bfa_lun_queue_depth:Lun queue depth, default=32,
> Range[>0] (int)
> parm:           bfa_io_max_sge:Max io scatter/gather elements ,
> default=255 (int)
> parm:           log_level:Driver log level, default=3,
> Range[Critical:1|Error:2|Warning:3|Info:4] (int)
> parm:           ioc_auto_recover:IOC auto recovery, default=1,
> Range[off:0|on:1] (int)
> parm:           linkup_delay:Link up delay, default=30 secs for boot
> port. Otherwise 10 secs in RHEL4 & 0 for [RHEL5, SLES10, ESX40]
> Range[>0] (int)
> parm:           msix_disable_cb:Disable Message Signaled Interrupts
> for Brocade-415/425/815/825 cards, default=0, Range[false:0|true:1]
> (int)
> parm:           msix_disable_ct:Disable Message Signaled Interrupts if
> possible for Brocade-1010/1020/804/1007/1741 cards, default=0,
> Range[false:0|true:1] (int)
> parm:           fdmi_enable:Enables fdmi registration, default=1,
> Range[false:0|true:1] (int)
> parm:           pcie_max_read_reqsz:PCIe max read request size,
> default=0 (use system setting), Range[128|256|512|1024|2048|4096]
> (int)
> parm:           max_xfer_size:default=32MB, Range[64k|128k|256k|512k|
> 1024k|2048k] (int)
> parm:           max_rport_logins:Max number of logins to initiator and
> target rports on a port (physical/logical), default=1024 (int)
> 
> 
> I guess that I could be a possible to update the driver inside the
> Ovirt Node build ?
> 
> 
> 
> 
> Kevin
> -- 
> 
> Kevin Mazi?re
> Responsable Infrastructure
> Alter Way ? Hosting
> 1 rue Royal - 227 Bureaux de la Colline
> 92213 Saint-Cloud Cedex
> T?l : +33 (0)1 41 16 38 41 
> Mob : +33 (0)7 62 55 57 05 
> http://www.alterway.fr 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users




From kevin.maziere at alterway.fr  Fri Jan 25 14:16:50 2013
From: kevin.maziere at alterway.fr (Kevin Maziere Aubry)
Date: Fri, 25 Jan 2013 15:16:50 +0100
Subject: [node-devel] [Users] BFA FC driver no stable on Fedora
In-Reply-To: <1358952094.2192.12.camel@mburns-laptop.usersys.redhat.com>
References: <CA+Vz4VoEPz=YeZXWxtHj1M9KO89jNJBs3q_SCGQqbYD7HeWEdQ@mail.gmail.com>
	<1358952094.2192.12.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <CA+Vz4VqEoPM2713vivxXEFh1Q4XnZzEnUVg_3kWLK4BjoFTgoA@mail.gmail.com>

Hi Mike

thanks for your reply.
I'm using oVirt Node Hypervisor release 2.5.5 (0.1.fc17).
On the latest kernel on fedora17 the problem is still here.

I've other issue on this node image, so I will test on fc18 and vdsm from
repo.

Kevin



2013/1/23 Mike Burns <mburns at redhat.com>

> On Wed, 2013-01-23 at 10:25 +0100, Kevin Maziere Aubry wrote:
> > Hi
> >
> >
> > I've spent hours to make my Brocade FC card working on Fedora17 or
> > Ovirt Node build.
> > In fact the card are randomly seen by the system, which is really
> > painfull.
> > So I've downloaded, compile and installed the latest driver from
> > Brocade, and now when I load the module the card is seen.
> > So I've installed :
> > bfa_util_linux_noioctl-3.2.0.0-0.noarch
> > bfa_driver_linux-3.2.0.0-0.noarch
> >
>
> Hi Kevin,
>
> A few things:
>
> 1.  what version of ovirt-node are you using?
> 2.  You can use the plugin tooling to install an updated kmod package as
> long as it's in rpm format.  This will ensure that it gets into both the
> system and the initramfs.  It's an offline process that will produce a
> new iso that you can install or upgrade to.  The tool is called
> edit-node and is available in the ovirt-node-tools rpm (from the
> ovirt.org repos)
> 3.  Do you know if it's fixed in a recent release of the kernel on
> Fedora?  If it is, then we can spin an updated version of the image and
> pick up the fix directly from fedora.
>
> Mike
>
> >
> > And the module info are :
> > # modinfo bfa
> > filename:
> >   /lib/modules/3.3.4-5.fc17.x86_64/kernel/drivers/scsi/bfa.ko
> > version:        3.2.0.0
> > author:         Brocade Communications Systems, Inc.
> > description:    Brocade Fibre Channel HBA Driver fcpim ipfc
> > license:        GPL
> > srcversion:     5C0FBDF3571ABCA9632B9CA
> > alias:          pci:v00001657d00000022sv*sd*bc0Csc04i00*
> > alias:          pci:v00001657d00000021sv*sd*bc0Csc04i00*
> > alias:          pci:v00001657d00000014sv*sd*bc0Csc04i00*
> > alias:          pci:v00001657d00000017sv*sd*bc*sc*i*
> > alias:          pci:v00001657d00000013sv*sd*bc*sc*i*
> > depends:        scsi_transport_fc
> > vermagic:       3.3.4-5.fc17.x86_64 SMP mod_unload
> > parm:           os_name:OS name of the hba host machine (charp)
> > parm:           os_patch:OS patch level of the hba host machine
> > (charp)
> > parm:           host_name:Hostname of the hba host machine (charp)
> > parm:           num_rports:Max number of rports supported per port
> > (physical/logical), default=1024 (int)
> > parm:           num_ioims:Max number of ioim requests, default=2000
> > (int)
> > parm:           num_tios:Max number of fwtio requests, default=0 (int)
> > parm:           num_tms:Max number of task im requests, default=128
> > (int)
> > parm:           num_fcxps:Max number of fcxp requests, default=64
> > (int)
> > parm:           num_ufbufs:Max number of unsolicited frame buffers,
> > default=64 (int)
> > parm:           reqq_size:Max number of request queue elements,
> > default=256 (int)
> > parm:           rspq_size:Max number of response queue elements,
> > default=64 (int)
> > parm:           num_sgpgs:Number of scatter/gather pages, default=2048
> > (int)
> > parm:           rport_del_timeout:Rport delete timeout, default=90
> > secs, Range[>0] (int)
> > parm:           bfa_lun_queue_depth:Lun queue depth, default=32,
> > Range[>0] (int)
> > parm:           bfa_io_max_sge:Max io scatter/gather elements ,
> > default=255 (int)
> > parm:           log_level:Driver log level, default=3,
> > Range[Critical:1|Error:2|Warning:3|Info:4] (int)
> > parm:           ioc_auto_recover:IOC auto recovery, default=1,
> > Range[off:0|on:1] (int)
> > parm:           linkup_delay:Link up delay, default=30 secs for boot
> > port. Otherwise 10 secs in RHEL4 & 0 for [RHEL5, SLES10, ESX40]
> > Range[>0] (int)
> > parm:           msix_disable_cb:Disable Message Signaled Interrupts
> > for Brocade-415/425/815/825 cards, default=0, Range[false:0|true:1]
> > (int)
> > parm:           msix_disable_ct:Disable Message Signaled Interrupts if
> > possible for Brocade-1010/1020/804/1007/1741 cards, default=0,
> > Range[false:0|true:1] (int)
> > parm:           fdmi_enable:Enables fdmi registration, default=1,
> > Range[false:0|true:1] (int)
> > parm:           pcie_max_read_reqsz:PCIe max read request size,
> > default=0 (use system setting), Range[128|256|512|1024|2048|4096]
> > (int)
> > parm:           max_xfer_size:default=32MB, Range[64k|128k|256k|512k|
> > 1024k|2048k] (int)
> > parm:           max_rport_logins:Max number of logins to initiator and
> > target rports on a port (physical/logical), default=1024 (int)
> >
> >
> > I guess that I could be a possible to update the driver inside the
> > Ovirt Node build ?
> >
> >
> >
> >
> > Kevin
> > --
> >
> > Kevin Mazi?re
> > Responsable Infrastructure
> > Alter Way ? Hosting
> > 1 rue Royal - 227 Bureaux de la Colline
> > 92213 Saint-Cloud Cedex
> > T?l : +33 (0)1 41 16 38 41
> > Mob : +33 (0)7 62 55 57 05
> > http://www.alterway.fr
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
>
>
>


-- 

Kevin Mazi?re
Responsable Infrastructure
Alter Way ? Hosting
 1 rue Royal - 227 Bureaux de la Colline
92213 Saint-Cloud Cedex
T?l : +33 (0)1 41 16 38 41
Mob : +33 (0)7 62 55 57 05
 http://www.alterway.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20130125/b70009cb/attachment.html>